CAS的单点登录和oauth2的最大区别

CAS和oauth非常相似，某些情况下甚至可以互相替代。

但是在实际使用中，还是有些差别

 

CAS的单点登录 使用场景的侧重点是 保障客户端的用户资源（业务数据）的安全

oauth2 使用场景的侧重点是 保障服务端的用户资源（用户信息）的安全

 

场景：

比如我们自己的多个项目，有一个CAS认证中心和多个子系统，所有用户数据都在我们自己手中，用户是想访问某个子系统，查看其中数据，CAS认证中心点头后，这个系统才允许用户访问。

而oauth，比如我们想使用微信登陆某个第三方网站，这个网站需要索取用户的头像、昵称甚至手机号、身份证号等信息，这都是需要用户授权的，用户授权后，这个网站才能拿到这些信息。

 

CAS客户端要获取的最终信息是，这个用户到底有没有权限访问我（CAS客户端）的资源。

oauth2获取的最终信息是，我（oauth2服务提供方）的用户的资源到底能不能让你（oauth2的客户端）访问

 

CAS的单点登录，资源都在客户端这边，不在CAS的服务器那一方。

用户在给CAS服务端提供了用户名密码后，作为CAS客户端并不知道这件事。

随便给客户端个ST，那么客户端是不能确定这个ST是用户伪造还是真的有效，所以要拿着这个ST去服务端再问一下，这个用户给我的是有效的ST还是无效的ST，是有效的我才能让这个用户访问。

 

oauth2认证，资源都在oauth2服务提供者那一方，客户端是想索取用户的资源。

所以在最安全的模式下，用户授权之后，服务端并不能直接返回token，通过重定向送给客户端，因为这个token有可能被黑客截获，如果黑客截获了这个token，那用户的资源也就暴露在这个黑客之下了。

于是聪明的服务端发送了一个认证code给客户端（通过重定向），客户端在后台，通过https的方式，用这个code，以及另一串客户端和服务端预先商量好的密码，才能获取到token和刷新token，这个过程是非常安全的。

如果黑客截获了code，他没有那串预先商量好的密码，他也是无法获取token的。这样oauth2就能保证请求资源这件事，是用户同意的，客户端也是被认可的，可以放心的把资源发给这个客户端了。

 

所以cas登录和oauth2在流程上的最大区别就是，通过ST或者code去认证的时候，需不需要预先商量好的密码。 

 

以上均是个人感悟，仅供参考