授权与认证系列文章：

1. web应用的session和token有什么联系？

2. Java面试常见问题：JWT是什么？

3. 如何理解OAuth 2.0？

4. 基于JWT和CAS的SSO单点登录方案

前面的文章中曾经介绍过实现单点登录的CAS方案，以及第三方平台授权的OAuth2协议，OAuth2协议也可以用于单点登录方案中，那么在单点登录场景中，CAS方案与OAuth2方案有何区别呢？

CAS方案

所谓单点登录（SSO），也就是用户只需要登录一次就可以访问所有应用。用户客户端（浏览器）通过CAS服务器实现单点登录的流程如下图所示，在CAS Server登录一次以后，用户就可以访问被保护的应用。具体过程可以参见前文，这里就不再赘述了。

将CAS单点登录的逻辑可以简化为下图，通过CAS服务器完成认证及授权可分6个步骤。

1. 访问服务：浏览器发送请求访问应用系统的服务资源。
2. 定向认证：应用会重定向用户请求到 CAS 服务器。
3. 用户认证：浏览器与CAS服务器进行交互，完成用户身份认证。
4. 发放票据：CAS 服务器会产生一个随机的 Service Ticket，并将带有Ticket的请求重定向到应用系统。
5. 验证票据：应用系统向CAS 服务器验证票据 Service Ticket 的合法性。
6. 获取资源：CAS 服务器验证票据通过后，应用系统允许浏览器访问服务资源。

在CAS单点登录过程中，主要是依靠重定向，通过浏览器来传递认证信息，比如前面4个步骤，都是浏览器与应用及CAS系统在进行交互，且第3步和第4步涉及到敏感信息的传输。

为了安全起见，要求应用系统（CAS Client）和CAS服务器都要使用Https协议进行传输加密。因为一旦Service Ticket被黑客拦截，则可以模仿认证成功的请求，欺骗应用系统已完成认证，并进一步进行后续的交互。

OAuth2

OAuth2协议本来是用在第三方系统授权的，当然也可以用于一个组织内部系统的单点登录。OAuth2实现单点登录的流程如下图所示，经过SSO服务器授权以后，浏览器可以访问sso-client1 和 sso-client2 这两个业务系统的资源。

为了便于理解，我们将OAuth2单点登录方案以下图表示。

类似CAS单点登录，OAuth2单点登录同样可以分为6个步骤。

1. 访问服务：用户客户端（浏览器）访问业务系统。
2. 定向认证：业务系统判断用户没有登录，把用户重定向到认证中心进行认证。
3. 用户认证：用户在认证中心完成登录认证。
4. 发放Code：IAM为用户的此次请求创建OAuth code，并带OAuth code返回应用回调地址。
5. 获取token：应用获取OAuth code并和约定的密钥一起通过服务器间请求，获取Access Token。
6. 获取资源：应用解析Access Token后，允许用户登录并获取信息。

经过以上步骤，就实现了业务系统对用户客户端访问的授权。可以发现，OAuth2与CAS实现单点登录的方案是大同小异，流程基本一致。主要区别在于：

(1) 在用户完成认证以后，OAuth2 SSO服务器不会马上提供令牌，而是先给业务系统一个授权码，业务系统用这个授权码去换取令牌。

(2) 授权码Code和令牌Token的传输，都是在SSO服务器和业务系统之间进行，没有通过客户端来传递这些敏感信息。

安全性总结

由于授权码是一次性使用的，而且需要配合约定密钥一起才能获取Token信息，在安全性方面，显然要比直接把验证票据提供给客户端保存更安全一些。

CAS协议中的Service Ticket的安全性完全依赖于Https 的SSL协议保障，OAuth2.0在此基础上，还有两个额外的约束：1、授权码使用次数有一次性约束；2、换取Token时必须提供约定密钥。

除了CAS和OAuth可以实现单点登录以外，常见的单点登录方案还有OpenID和SAML。

OpenID：OpenID最新是OpenID Connect，OpenID Connect基于OAuth协议之上，在OAuth2中有一个特殊的Scope "openid"来标识openid请求，并在OAuth2的返回体中增加一个idtoken的字段来标识用户。使用OpenID Connect的单点登录流程与Oauth2一致。

SAML（Security Assertion Markup Language）：SAML通过XML进行交互，是一个基于HTTP的企业级用户身份认证的标准协议，实现了服务提供商（SP）和身份提供商（IdP）之间的沟通。

我会持续更新关于物联网、云原生以及数字科技方面的文章，用简单的语言描述复杂的技术，也会偶尔发表一下对IT产业的看法，请大家多多关注，欢迎留言和转发，希望与大家互动交流，谢谢。