主流单点登录SSO协议概述

知识点：

认证和授权
单点登录，以及其主流方案

1，认证与授权

以小区门卫大叔的灵魂3问为例：

你是谁
你来自哪里
你将要到哪里去

认证（authentication），确认用户的身份，解决你是谁的问题
- 门卫大叔只有知道了你是谁，才能确认你是否初步判断是安全的
- 同时在疫情情况下，还会询问你从哪里过来的（外部访问来源），如果是来自于风险区的话，会拒绝你当前的请求，上报风险管控中心
授权（authorization），根据你的身份给你特定的权限，解决你能到哪里去的问题
- 你是一个普通的外部人员，不可能直接给放你进来
- 如果你是一个小区住户，那么门卫大叔才会给你开门（授予响应权限），才能真正进入小区

2，单点登录

SingleSign-On，SSO是一种帮助用户快捷访问网络中多个站点的安全通信技术。

该协议通过多个系统之间的用户身份信息的交换来实现单点登录。使用单点登录系统时，用户只需要登录一次，就可以访问多个系统，不需要记忆多个口令密码。单点登录使用户可以快速访问网络，从而提高工作效率，同时也能帮助提高系统的安全性。

现实生活对照：

2.1，CAS

中央认证服务（central authentication server，CAS），是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样，用户仅需要登录一次，访问其他应用则无需再次登录。

依据CAS的名称可知，它仅用于Authentication认证，和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。

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

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

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

认证流程大致为：

1，Client（终端用户）在浏览器里请求访问web应用example；

2，浏览器发起一个GET请求访问example应用的主页

3，应用example发现当前用户处于未登录状态，redirect（重定向）用户至CAS服务器进行认证

4，用户请求CAS服务器

5，CAS发现当前用户在CAS服务器中处于未登录状态，要求用户必须先进行登录

6，CAS服务器返回登录页面至浏览器

7，用户在登录界面中输入用户名和密码（或者其他认证方式）

8，用户把用户名和密码通过post，提交至CAS服务器

9，CAS对用户身份进行认证，若用户名和密码正确，则生成SSO会话，且会把会话ID（sessionId）通过cookie的方式返回至用户的浏览器端（此时，用户在CAS服务器端处于登录状态）

10，CAS服务器同时也会把用户重定向至CAS Client，且同时发送一个Service Ticket

11，CAS Client的服务端收到这个server ticket以后，请求CAS server对该ticket进行校验

12，CAS Server把校验结果返回给CAS Client，校验结果包括该ticket是否合法，以及该ticket中包含对用户信息

13，至此，CAS Client根据Server ticket得知当前登录用户的身份，CAS Client处于登录态

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

注意：CAS 1.0是一个有些历史的协议，在2.0、3.0版本中，Server Ticket的校验结果均为XML格式，且引入一种proxy模式

up主老齐的意见：

CAS协议是一个比较简陋的单点登录协议，协议本身比较轻量级也比较容易实现，但是能够解决的场景比较单一
杂乱：CAS3.0 又引入了基于SAML对server ticket进行校验
CAS Client和CAS Server之间的互信是通过接口调用的方式来建立的，没有任何加密/签名机制来保证进一步的安全
缺乏校验CAS Client自身身份的机制
市面上实现CAS协议的应用并不多，up主他自己不推荐使用这个

2.2，OAuth 2.0

当前谈到OAuth基本都是说的OAuth 2.0协议，它是一种authorization（授权）协议而非authentication（认证）协议，虽然OAuth2的流程中只描述了authorization，但是在实际使用中，authorization脱离authentication并没有任何意义

OAth 2.0解决的主要场景是：第三方应用如何被授权访问资源服务器。

整个流程参与者为：

resource owner：资源拥有者，通常为终端用户
resource server：资源提供者
authorization server：授权服务器
client：请求访问服务访问的应用

抽象的授权流程大致为：

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

这个场景中，张三为资源拥有者（Resource Owner），在线音乐服务为资源服务器（resource server），client为某音视频播放软件，IDaaS为授权服务器（authorization server）。

流程大致为：

音视频软件向张三发起授权请求，请求张三同意访问在线音乐服务
根据不同的授权模式，张三同意该授权，且返回一个“授权”给音视频服务
音视频服务携带张三的授权，请求IDaaS颁发一个access_token，用于访问在线音乐
IDaaS校验音视频服务自身的合法性之后，颁发access_token
音视频服务携带access_token以后，代表张三请求访问在线音乐
在线音乐服务校验完access_token以后，提供音乐服务权限，播放器可以进行音乐播放

上述流程只是一个大致的初略流程，实际使用中，前三步会有不同的变化（不同的授权模式），比较常见的授权模式为：

Authorization Code Grant（授权码模式）：，最为常见、最安全，强烈推荐
Implicit Grant（隐式授予）：适用于SPA应用（单页Web应用），已经不在推荐使用，被PKCE模式代替
Resouce Owner Password Credentials Grant（资源所有者密码凭据授予）：需要把用户的用户名和密码暴露给client
Client Credentials Grant（客户证书授予）：整个流程没有用户的概念，适用于服务端->服务端调用的场景

通过上述讲解可知，音视频播放器并不需要知道张三的密码，只需要得到张三的授权就可以访问在线音乐，而整个授权就是由authorization server来负责的。

2.3，OIDC

OpenID Cennect简称OIDC，是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的authorization场景，还额外定义了authentication的场景，OIDC协议是当今最为流行的协议。

相比于OAuth 2.0协议，OIDC引入了id_token等和userinfo相关的概念：

整个OAuth2协议，只是定义了access_token/refresh_token，但是这俩token只是为了保护Resource Server的，并没有Resource Owner的身份信息
OIDC引入id_token的概念，用这个特殊的token来表示这个resource owner的身份：
- 标准化id_token的格式：JSON Web Token（JWT）
- 标准化id_token的内容：standard claims（标准要求）
OIDC引入关于如何获取详细userInfo的endpoint
OIDC定义了类似于SAML Metadata的discovery接口，俗称well-known接口

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