En 400-6655-581
5
返回列表
> 资源中心 > 技术干货 | 单点登录场景中的CAS协议和OAuth2.0协议对比

技术干货 | 单点登录场景中的CAS协议和OAuth2.0协议对比

2020-03-30浏览次数:1036

相信关注过CAS和OAuth2.0协议的朋友们,都有大概的了解,简单描述两个协议的主要区别,网上的伙伴们通常会说:


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


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


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


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


CAS协议


说到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时须要提供约定密钥。