认证和授权

认证：确认该用户的身份是他所声明的那个人
授权：根据用户身份授予他访问特定资源的权限
当用户登录应用系统时，系统需要先认证用户身份，然后依据用户身份再进行授权。认证与授权需要联合使用，才能让用户真正登入并使用应用系统。

CAS

CAS，Central Authentication Server，一种常见的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 Client2的时候，用户不需要再次认证，即会跳过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：请求访问服务访问的应用
抽象的授权流程大致为：

假定一个在线音乐服务，用户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协议都不具备的。

OpenID Connect

OpenID Connect简称OIDC，是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的Authorization的场景，还额外定义了Authentication的场景。
相比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
OIDC引入了关于如何获取详细userinfo的Endpoint；
OIDC定义了类似于SAML Metadata的Discovery接口，俗称well-known接口
OIDC协议的登陆授权流程和OAuth2.0基本类似, 整个流程的参与者也类似，只不过换了个术语：
OpenID Provider：简称OP，负责认证和授权
Replying Party：简称RP，OAuth2.0中的client

可以说OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。
详细协议标准定义参考：
https://openid.net/specs/openid-connect-core-1_0.html

SAML2.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：身份认证服务器主动发起
下面是大致的认证流程：

1.End user从浏览器中请求访问某SP：https://www.example.com ；
2.https://www.example.com 发现用户未登录，则发起SAML的AuthnRequest请求至IDP，用户浏览器跳转至IDP页面；
3.IDP发现用户处于未登录状态，重定向用户至IDP的登录页面，请求用户进行身份验证
4.用户在登录页面中进行身份认证，通常情况下需要校验用户名和密码
5.IDP校验用户身份，若成功，则把包含着用户身份信息的校验结果，以SAML Response的形式，签名/加密发送给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协议，本质上它们大同小异，都是基于中心信任的机制，服务提供者和身份提供者之间通过互信来交换用户信息，只是每个协议信息交换的细节不同，或者概念上有些不同。

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

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