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

在这个场景中，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: 授权码模式，最为常用，最安全，强烈推荐；
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 ConnectOpenID 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: 身份认证服务器主动发起

下面是大致的认证流程：