SSO、CAS、OAuth、OIDC的区别
认证与授权的区别
- 认证（Authentication，AuthN）即“你是谁”，确认用户身份。
- 授权（Authoriztion，AuthZ）即“你可以做啥”，根据用户身份授予他访问特定资源的权限。
当用户登录系统时，系统需要先认证用户身份，再依据用户身份授权。认证和授权需要联合使用，才能让用户真正登录并使用应用系统。
单点登录（Single Sign-On，SSO）
多个站点都要登录，但是每个站点都维护一套登录服务太过麻烦，只需要一套SSO系统，就可以帮助用户快捷访问网络中的多个站点。该协议通过多个系统之间的用户身份信息的交换来实现单点登录。用户只需要记忆一个口令，登陆一次，就可以访问多个系统。
SSO是一种实现目标，具体怎么做请看下面各个具体的实现。
CAS
Central Authtication Service，CAS。常见的B/S架构SSO协议。
仅用于AuthN，CAS认证流程包括几部分参与者：
- Client：通常为使用浏览器的用户
- CAS Client：实现CAS协议的web应用
- CAS Server：统一认证的CAS服务器
流程如下：
- 用户在浏览器里请求访问web应用example
- 浏览器发起一个GET请求访问example的网页 https://www.example.com
- 应用example发现当前用户处于未登录状态，Redirect用户至CAS服务器进行认证
- 请求CAS服务器
- CAS发现用户未登录，要求用户登录
- CAS服务器返回登录页面至浏览器
- 用户在登录界面中输入用户名和口令（或其他认证方式）
- 用户将用户名和口令通过POST，提交给CAS服务器
- CAS对用户进行认证，若用户名和口令正确，则生成SSO会话，并把会话ID通过cookie的方式返回至用户的浏览器端（此时，用户在CAS服务端处于登陆状态）
- CAS服务器同时也会把用户重定向至CAS Client，并且同时发送一个Server Ticket
- CAS Client收到Server Ticket，请求CAS Server对ticket进行校验
- CAS Server把校验结果返回给CAS Client，校验结果包括ticket是否合法，以及ticket中包含的用户信息
- 至此，CAS Client根据Service Ticket得知登录用户身份，CAS Client处于登录态。
当登录一个Client2时，用户不需要再次认证，跳过5，6，7，8，9这几个步骤。
用的越来越少，因为它之解决认证部分，不授权。
OAuth 2.0
其实是一种AuthZ协议，不用来认证，关注授权本身。但是在实际使用中，授权脱离了认证没有任何意义。
OAuth 2.0解决的主要场景是：第三方应用如何被授权访问资源服务器。整个流程包括以下几个部分：
- Resource Owner：资源拥有者，通常为终端用户
- Resource Server：资源提供者
- Authorization Sever：授权服务器
- Client：请求访问服务的应用
大致流程如下:
假定一个在线音乐服务，用户zhangsan（Resource Owner）想通过某音视频播放软件（client）来播放在线音乐，但是在播放音乐之前，该音视频软件必须得通过YuFu(即玉符IDaaS)（Authorization Server）认证授权，得到zhangsan的同意之后才能访问在线音乐。
在这个场景中，zhangsan为Resource Owner，在线音乐服务为Resource Server，Client为某音视频播放软件，YuFu作为Authorization Server。
- 音视频软件向zhangsan发起授权请求，请求zhangsan同意访问在线音乐服务
- 根据不同的授权模式，zhangsan同意该授权，且返回一个"授权"给音视频服务，音视频服务携带zhangsan的授权，请求YuFu颁发一个access_token，用于访问在线音乐
- YuFu校验音视频服务自身的合法性之后，颁发access_token
- 音视频服务携带access_token，代表zhangsan请求访问在线音乐
- 在线音乐服务校验完access_token以后，提供音乐服务。播放器开始播放音乐。
上述是一个抽象的授权流程，而在具体实现中，在前三步中会有几个变种，即不同的授权模式，常见的授权模式包括:
- Authorization Code Grant：授权码模式，最为常用，最安全，强烈推荐
- lmplicit 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协议都不具备的。
OpenID Connect
OpenID Connect简称OIDC，是基于OAuth 2.0扩展出的一个协议。除了能实现OAuth2.0的AuthZ，还额外定义了AuthN场景，是当今最流行的协议。
相比OAuth 2，OICD引入了id_token和userinfo相关的概念：
- OAuth 2.0只是定义了access_token/refresh_token，但是这俩只是为了保护Resource Server的，并没有包含Resource Owner的信息；
- OIDC引入了id_token的概念，用这个特殊的token来表示这是Resource Owner的身份证：
- 标准化id_token的格式：即大家熟知的JWT；
- 标准化id_token的内容：standard claims；
- OIDC引入了关于如何获取详细userinfo的Endpoint；
- OIDC定义了类似于SAML Metadata的Discovery接口，俗称well-known接口：
OIDC协议的登陆授权流程和OAuth2.0基本类似，整个流程的参与者也类似，只不过换了个术语：
- OpenlD Provider：简称OP，负责认证和授权
- Relying Party：简称RP，OAuth 2.0中的Client
OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。
SAML 2.0
古老的协议，没人用了。
Security Assertion Markup Language，基于XML的标准协议。
简单对比
| 比较项 | CAS | OAuth | OIDC | SAML |
|---|---|---|---|---|
| 支持AuthN | √ | × | √ | √ |
| 支持AuthZ | × | √ | √ | × |
| 传输方式 | HTTP | HTTP | HTTP | HTTP |
| 票据格式 | server ticket，proxy ticket 协议定义为一个opaque的ticket，没有标准格式 |
acces_token,refresh_token 协议定义为一个opaque的ticket，没有标准格式 |
acces_token,refresh_token,id_token access_token, refresh_token同OAuth2.0，是一个opaque的token，没有标准格式 id_token是一个标准的JWT格式的token，且有标准claim的定义 |
assertion，AuthNRequest等 基于XML格式，遵循SAML统一格式定义 |
| 主要应用场景 | B/S架构，基于浏览器的SSO | B/S架构，基于浏览器的授权 | B/S架构。基于浏览器的SSO和授权 PKCE模式可以用来实现移动端的SSO场景 |
B/S架构，基于浏览器的SSO |
| 优势 | 基本没优势 | 协议实现简单，能解决场景多 成熟度高，社区支持广泛 |
协议简单易实现，能解决的场景多 成熟度高 可以同时AuthN和AuthZ |
最全面的SSP协议之一 |
