浅析-单点登录场景中的CAS协议和OAuth2.0协议对比

关注过CAS和OAuth2.0协议的朋友们,都有大概的了解,简单描述两个协议的主要区别.

大多数人理解是:

CAS单点登录时,保护客户端资源

OAuth2.0是保护服务端资源安全

而对于单点登录场景来说,无论是保护客户端资源,还是保护服务端资源,最终都是完成认证中心的认证,使访问的资源获取到登录的用户信息,从这个角度来看,两个协议并没有什么区别。

那么在怎样去理解两种的区别呢?先来看一下两个协议:

CAS协议,必须亮出下图:

1、访问服务:SSO 客户端发送请求访问应用系统提供的服务资源。

2、定向认证:SSO 客户端会重定向用户请求到 SSO 服务器。

3、用户认证:用户身份认证。

4、发放票据:SSO 服务器会产生一个随机的 Service Ticket 。

5、验证票据:SSO 服务器验证票据 Service Ticket 的合法性,验证通过后,允许客户端访问服务。

6、传输用户信息:SSO 服务器验证票据通过后,传输用户认证结果信息给客户端。

交互过程中1、2、3、4步骤是通过客户端网传输的,存在安全隐患,可以看出其中3和4步携带有敏感数据,3用户认证是最基本的场景由CAS Server保障认证安全,4重定向到CAS Client的过程携带有认证核心票据Service Ticket(有时效性的,可重复使用的),安全性由CAS Client保障,为了保障这两步的信息传输安全,要求CAS Client 和CAS Server端都采用Https方式访问进行传输加密,因为一旦Service Ticket被黑客拦截,则可以模仿认证成功的请求,欺骗CAS Client用户已完成认证,并进一步完成后续的认证交互。

OAuth2.0

以授权码模式(authorization code)的交互进行对比:

1、用户访问业务系统。

2、业务系统判断用户没有登录,把用户重定向到认证中心进行认证。

3、用户在认证中心完成登录认证,IAM为用户的此次请求创建OAuth code,并带OAuth code返回应用回调地址。

4、应用获取OAuth code并和约定的密钥一起通过服务器间请求,获取Access Token。

5、应用通过Access Token调用用户接口获取用户信息。

6、应用得到用户身份,完成用户登录。

交互过程中1、2、3是通过客户端网络传输的,存在安全隐患,但是因为这三步的目的是获取code,而获取的code是一次性有效的,并无法单独使用,须要与第4步中的约定密钥一起使用获取token信息,所以安全性有一定的保障,业务系统须要保管好密钥,并保障密钥不从客户端传输,仅在服务器间传输。

综上所述,无论是CAS协议的认证集成还是OAuth2.0的认证集成,都需要业务系统和认证中心通过https协议保障客户端http请求的安全性,而CAS协议这一点尤为重要,因为保障Service Ticket的安全性完全依赖于https 的SSL协议保障,而OAuth2.0在此基础上,还有额外的两个约束:1、code次数有效性约束;2、换取token时须要提供约定密钥。

 

Related Post

发表评论

电子邮件地址不会被公开。 必填项已用*标注