单点登录协议有哪些？CAS、OAuth、OIDC等有何异同？ _单点登录协议

单点登录实现中，系统之间的协议对接是非常重要的一环，一般涉及的标准协议类型有 CAS、OAuth、OpenID Connect、SAML，本文将对四种主流 SSO协议进行概述性的介绍，并比较其异同，读者亦可按图索骥、厘清关键概念。
一、认证与授权的区别在介绍具体协议之前，有必要先说明“认证（Authentication）”和“授权（Authorization）”的区别。

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

也就是说，当用户登录应用系统时，系统需要先认证用户身份，然后依据用户身份再进行授权。认证与授权需要联合使用，才能让用户真正登入并使用应用系统。
二、CASCentral 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服务器

认证流程大致为:

文章插图

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

抽象的授权流程大致为: