相信关注过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时须要提供约定密钥。