单点登录实现中，系统之间的协议对接是非常重要的一环，一般涉及的标准协议类型有 CAS、OAuth、OpenID Connect、SAML，本文将对四种主流 SSO协议进行概述性的介绍，并比较其异同，读者亦可按图索骥、厘清关键概念。

一、认证与授权的区别

在介绍具体协议之前，有必要先说明“认证（Authentication）”和“授权（Authorization）”的区别。

• 认证（Authentication）即确认该用户的身份是他所声明的那个人；
• 授权（Authorization）即根据用户身份授予他访问特定资源的权限。

也就是说，当用户登录应用系统时，系统需要先认证用户身份，然后依据用户身份再进行授权。认证与授权需要联合使用，才能让用户真正登入并使用应用系统。

二、CAS

Central Authentication Service简称CAS，是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样，用户仅需登陆一次，访问其他应用则无需再次登陆。

顾名思义，CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。

当前CAS协议包括CAS 1.0、CAS2.0、CAS3.0版本，这三个版本的认证流程基本类似。

CAS的认证流程通过包括几部分参与者:

• Client: 通常为使用浏览器的用户
• CAS Client: 实现CAS协议的Web应用
• CAS Server: 作为统一认证的CAS服务器

认证流程大致为:

1. Client(终端用户)在浏览器里请求访问Web应用example；
2. 浏览器发起一个GET请求访问example应用的主页https://www.example.com；
3. 应用example发现当前用户处于未登陆状态，Redirect用户至CAS服务器进行认证；
4. 用户请求CAS服务器；
5. CAS发现当前用户在CAS服务器中处于未登陆状态, 要求用户必须得先登陆；
6. CAS服务器返回登陆页面至浏览器；
7. 用户在登陆界面中输入用户名和密码（或者其他认证方式）；
8. 用户把用户名和密码通过POST，提交至CAS服务器；
9. CAS对用户身份进行认证，若用户名和密码正确，则生成SSO会话, 且把会话ID通过Cookie的方式返回至用户的浏览器端（此时，用户在CAS服务端处于登陆状态）；
10. CAS服务器同时也会把用户重定向至CAS Client, 且同时发送一个Service Ticket；
11. CAS Client的服务端收到这个Service Ticket以后，请求CAS Server对该ticket进行校验；
12. CAS Server把校验结果返回给CAS Client, 校验结果包括该ticket是否合法，以及该ticket中包含对用户信息；
13. 至此，CAS Client根据Service Ticket得知当前登陆用户的身份，CAS Client处于登陆态。

经过上述流程以后，CAS Server和CAS Client都处于登陆态，当用户如果访问另外一个CAS Client 2的时候，用户不需要再次认证，即会跳过5、6、7、8、9这几步，从而达到SSO的效果。

注: CAS 1.0是个非常简单粗陋的协议，在2.0、3.0版本中，Service Ticket的校验结果均为XML格式， 且引入了一种proxy模式（不在本文做深入讨论）。

CAS协议的详细标准定义，请参考：

https://apereo.github.io/cas/6.2.x/protocol/CAS-Protocol-Specification.html

笔者意见：

1. CAS协议是一个比较简陋单点登陆协议，协议本身比较轻量级也比较容易实现，但是能够解决的场景比较单一；

2. 杂乱：CAS 3.0又引入了基于SAML对Service Ticket进行校验；

3. CAS Client和CAS Server之间的互信是通过接口调用的方式来建立, 没有任何加密/签名机制来保证进一步的安全；

4. 缺乏校验CAS Client自身身份的机制；

5. 市面上实现了CAS协议的应用并不多，笔者也不推荐这种协议。

三、OAuth 2.0

谈到OAuth, 通常是指OAuth 2.0协议，它是一种Authorization协议并不是一种Authentication协议，虽然OAuth 2的流程中只描述了Authorization。但是在实际使用中，Authorization脱离Authentication并没有任何意义。

OAuth 2.0解决的主要场景是: 第三方应用如何被授权访问资源服务器。整个流程参与者包括几个组成部分:

• Resource Owner: 资源拥有者，通常为终端用户
• Resource Server: 资源提供者
• Authorization Server: 授权服务器
• Client: 请求访问服务访问的应用

抽象的授权流程大致为:

OAuth-flow

假定一个在线音乐服务，用户zhangsan想通过某音视频播放软件来播放在线音乐, 但是在播放音乐之前，该音视频软件必须得通过YuFu（即玉符IDaaS）认证授权，得到zhangsan的同意之后才能访问在线音乐。

在这个场景中，zhangsan为Resource Owner, 在线音乐服务为Resource Server, Client为某音视频播放软件，YuFu作为Authorization Server。

1. 音视频软件向zhangsan发起授权请求，请求zhangsan同意访问在线音乐服务；
2. 根据不同的授权模式，zhangsan同意该授权，且返回一个"授权"给音视频服务；
3. 音视频服务携带zhangsan的授权，请求YuFu颁发一个access_token, 用于访问在线音乐；
4. YuFu校验音视频服务自身的合法性之后，颁发access_token；
5. 音视频服务携带access_token, 代表zhangsan请求访问在线音乐；
6. 在线音乐服务校验完access_token以后，提供音乐服务. 播放器开始播放音乐。

上述是一个抽象的授权流程，而在具体实现中，在前三步中会有几个变种，即不同的授权模式，常见的授权模式包括:

• Authorization Code Grant: 授权码模式，最为常用，最安全，强烈推荐；
• Implicit Grant: 适用于SPA应用，已经不再推荐使用，被PKCE模式所替代；
• Resource Owner Password Credentials Grant: 需要把用户的用户名和密码暴露给Client；
• Client Credential Grant: 整个流程没有用户的概念，适用于服务端->服务端调用的场景。

可以发现在整个流程中，音视频播放器并不需要知道zhangsan的密码，只是需要得到zhangsan的授权就可以访问在线音乐，而整个授权是由Authorization Server来负责。

本文并不会展开讨论Authorization Code模式，详细协议文档定义请参考：

https://tools.ietf.org/html/rfc6749

笔者意见：相比CAS协议，OAuth2.0不同的授权模式能够解决更多的场景，更安全、更流行，且通过PKCE模式能够实现移动端的单点登录，这个是其他SSO协议都不具备的（PKCE模式参考资料：https://tools.ietf.org/html/rfc7636）。

四、OpenID Connect

OpenID Connect简称OIDC，是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的Authorization场景，还额外定义了Authentication的场景，可以说OIDC协议是当今最流行的协议。

相比OAuth2，OIDC引入了id_token等和userinfo相关的概念：

• 整个OAuth2协议，只是定义了access_token/refresh_token，但是这俩token只是为了保护Resource Server的，并没有Resource Owner的身份信息；
• OIDC引入了id_token的概念，用这个特殊的token来表示这是Resource Owner的身份证：
  • 标准化id_token的格式：即大家熟知的JWT；
  • 标准化id_token的内容：Standard Claims
    • 参考：https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims
• OIDC引入了关于如何获取详细userinfo的Endpoint；
• OIDC定义了类似于SAML Metadata的Discovery接口，俗称well-known接口：
  • 参考：https://openid.net/specs/openid-connect-discovery-1_0.html

OIDC协议的登陆授权流程和OAuth2.0基本类似, 整个流程的参与者也类似，只不过换了个术语：

• OpenID Provider：简称OP，负责认证和授权
• Relying Party：简称RP，OAuth 2.0中的Client

OIDC-flow

可以说OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。

详细协议标准定义参考：

https://openid.net/specs/openid-connect-core-1_0.html

五、SAML 2.0

SAML协议全称为Security Assertion Markup Language，它是一个基于XML的标准协议。SAML标准定义了身份提供者（Identity Provider）和服务提供者（Service Provider）之间，如何通过SAML规范，采用加密和签名的方式来建立互信，从而交换用户身份信息。

SAML是一个非常古老的Authentication的协议，在早期B/S架构的企业级应用中非常流行。

SAML协议非常庞大，定义了很多optional的细节（即不是必须实现）。但这个也是双刃剑，这一点恰恰也是SAML协议的缺点，作为实现者，必须得同时兼顾这些optional的细节，给开发者带来较大的挑战。

技术上，SAML协议基于XML，以Assertion的方式，通过签名和加密交换用户身份信息. 这一点和OIDC协议中的ID_Token类似（采用签名/加密的id_token来交换用户身份）。

SAML流程的参与者包括Service Provider（SP）和Identity Provider（IDP）两个重要角色，且整个流程包括如下两个使用场景：

• SP Initiated: 服务提供者主动发起
• IDP Initiated: 身份认证服务器主动发起

下面是大致的认证流程：

saml-flow

1. End User从浏览器中请求访问某SP：https://www.example.com ；
2. https://www.example.com发现用户未登陆，则发起SAML的AuthnRequest请求至IDP, 用户浏览器跳转至IDP页面；
3. IDP发现用户处于未登陆状态，重定向用户至IDP的登陆界面，请求用户进行身份验证
4. 用户在登陆页面中进行身份认证, 通常情况下需要校验用户名和密码；
5. IDP校验用户身份，若成功，则把包含着用户身份信息的校验结果，以SAML Reponse的形式，签名/加密发送给SP；
6. SP拿到用户身份信息以后，进行签名验证/解密，拿到明文的用户身份信息，此时SP处于登陆状态，可以对用户提供服务。

可以看到，在整个流程中，IDP是负责颁发用户身份，SP负责信任IDP颁发的用户身份, SP和IDP之间的信任关系是需要提前建立的，即SP和IDP需要提前把双方的信息预先配置到对方，通过证书信任的方式来建立互信。

SAML协议的标准定义可参考：

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html

六、各协议简单对比

上面简单介绍了主流的几种SSO协议，本质上它们大同小异，都是基于中心信任的机制，服务提供者和身份提供者之间通过互信来交换用户信息，只是每个协议信息交换的细节不同，或者概念上有些不同。

最后，通过一个简单对比表格来总结本文重点内容：