在单点登录的实现中，系统间的协议对接是一个非常重要的环节。一般涉及的标准协议有CAS、OAuth、OpenID Connect和SAML。本文将对四种主流单点登录协议进行概述，并比较它们的异同。读者也可以按照地图，并阐明关键概念。
首先，身份验证和授权的区别
在介绍具体协议之前，有必要解释一下“认证”和“授权”的区别。
即认证确认用户的身份就是他所声称的人；授权是根据用户的身份授予用户对特定资源的访问权限。也就是说，当用户登录应用系统时，系统需要先对用户的身份进行认证，然后根据用户的身份进行授权。它需要与身份验证和授权结合使用，这样用户才能真正登录和使用应用系统。
二。国际体育仲裁法庭
中央认证服务(CAS)是B/S架构下常见的单点登录协议。与任何其他SSO协议一样，用户只需登录一次，但无需再次登录即可访问其他应用程序。
顾名思义，CAS是一种仅用于身份验证的服务。与OAuth/OIDC协议不同，CAS不能用作授权协议。
目前CAS协议有CAS 1.0、CAS2.0、CAS3.0，这三个版本的认证流程基本相似。
CAS的认证过程包括几个参与者:
客户端:通常是使用浏览器的用户，CAS客户端:实现CAS协议的Web应用，CAS服务器:作为统一认证，CAS服务器的认证流程大致如下:
客户端请求访问Web应用程序示例；在浏览器中；浏览器发起访问示例应用的主页https://www.example.com的GET请求；示例应用程序发现当前用户未登录，将用户重定向到CAS服务器进行认证；用户CAS服务器请求；CAS发现当前用户没有登录CAS服务器，要求用户先登录；CAS服务器向浏览器返回登陆页面；在登录界面输入用户名和密码；通过POST向CAS服务器提交用户名和密码；认证CAS用户身份，如果用户名和密码正确，生成SSO会话，并通过cookie将会话ID返回给用户的浏览器；同时，CAS服务器会将用户重定向到CAS客户端，发送服务票；。CAS客户端的服务器收到该服务票后，请求CAS服务器进行验票；服务器向CAS客户端返回检查结果，检查结果包括票据是否合法，以及票据中包含用户信息；此时，CAS客户端根据服务票知道了当前登录用户的身份，CAS客户端处于登录状态。完成上述过程后，CAS服务器和CAS客户端都处于登录状态。当用户访问另一个CAS客户端2时，用户将跳过步骤5、6、7、8和9，而无需重新认证，从而达到SSO的效果。
注意:CAS 1.0是一个非常简单和粗糙的协议。在2.0和3.0版本中，服务票的验证结果为XML格式，并引入了代理模式。
有关CAS的详细标准定义，请参考:
https://apereo . github . io/CAS/6.2 . x/Protocol/CAS-Protocol-specification . html
作者观点:
1.CAS协议是简单的单点登录协议，轻量级，易于实现，但是可以解决单一场景；
2.杂乱:CAS 3.0还引入了基于SAML的服务票验证；
3.CAS客户端和CAS服务器之间的相互信任是通过接口调用建立的，没有加密/签名机制来保证进一步的安全性；
4.缺乏验证CAS客户端自身身份的机制；
5.市面上CAS协议的应用不多，我不推荐这个协议。
三。OAuth 2.0
说到OAuth，通常指的是OAuth 2.0协议，这是一个授权协议而不是认证协议，虽然OAuth 2的过程中只描述了授权。但是，在实践中，授权脱离认证没有任何意义。
OAuth 2.0解决的主要场景是第三方应用如何被授权访问资源服务器。整个过程的参与者包括几个部分:
资源所有者:资源所有者，通常是最终用户资源服务器:资源提供者授权服务器:授权服务器客户端:请求访问服务的应用抽象的授权过程大致如下:
假设一个在线音乐服务，用户张山想通过一个音视频播放软件播放在线音乐，但是在播放音乐之前，音视频软件必须经过于夫的认证授权，获得张山的同意才能接入在线音乐。
在这个场景中，张三是资源所有者，在线音乐服务是资源服务器，客户端是音视频播放软件，于夫是授权服务器。
音视频软件向张山发送授权请求，请求张山同意接入在线音乐服务；根据不同的授权方式，张三同意授权，向音视频服务返回一个“授权”；音视频服务携带张三的授权，请求于夫颁发访问网络音乐的access _ token于夫检查音视频服务的合法性，然后下发access _ token；音视频服务携带access_token，代表张三请求访问网络音乐；在线音乐服务验证access_token后，提供音乐服务。播放器开始播放音乐。以上是一个抽象的授权过程，但在具体实现中，前三步会有几种变化，即不同的授权模式。常见的授权模式包括:
授权码授予:授权码模式，最常用，最安全，强烈推荐；隐式授予:适用于SPA申请，不再推荐，由PKCE模式替代；所有者密码凭证授予:用户的用户名和密码需要向客户端公开；；客户端凭证授予:整个过程没有用户概念，适用于服务器->服务器调用的场景。可以发现，在整个过程中，音视频播放器不需要知道张三的密码，只需要张三的授权就可以访问在线音乐，授权服务器负责整个授权。
本文将不讨论授权码模式，请参考:
https://tools.ietf.org/html/rfc6749
作者观点:与CAS协议相比，OAutp.0不同的授权模式可以解决更多的场景，更安全，更受欢迎。而且，通过PKCE模式可以实现移动终端的单点登录，这是其他单点登录协议所不具备的。
四。OpenID连接
OpenID Connect，简称OIDC，是基于OAutp.0的扩展协议，除了OAutp.0中的授权场景，还额外定义了认证场景。可以说，OIDC协议是当今最流行的协议。
与OAutp相比，OIDC引入了id_token等一些与userinfo相关的概念:
整个OAutp协议只定义了access_token/refresh_token，但这两个令牌只是用来保护资源服务器的，并没有资源所有者的身份信息。OIDC引入了id_token的概念，用这个特殊的令牌表示这是资源所有者的身份证:标准化ID _ token的格式:大家熟知的JWT；；标准化id_token的内容:标准权利要求引用:https://openid.net/specs/openid-connect-core-1 _ 0.html # standardclaimsoidc引入端点；关于如何获取详细的用户信息；https://openid.net/specs/openid-connect-discovery-1定义了一个类似SAML元数据的发现接口，俗称知名接口:参考:SAML _ 0。HTMLOIDC协议的登录授权过程与OAutp.0基本相似，整个过程的参与者也相似，只是换了另一个术语:
OpenID Provider:简称OP，负责认证授权依赖方:简称RP，OAuth 2.0中的Client。
可以说，OIDC协议是目前最主流的SSO标准协议，对开发者友好，易于实现。
详细的协议标准定义参考:
https://openid.net/specs/openid-connect-core-1_0.html
动词 （verb的缩写）SAML 2.0
SAML协议被称为安全断言标记语言，是基于XML的标准协议。SAML标准通过SAML规范定义了身份提供者和服务提供者之间如何通过加密和签名的方式建立相互信任，从而交换用户身份信息。
SAML是一个非常古老的认证协议，在早期的B/S架构企业应用中非常流行。
SAML协议非常庞大，定义了很多可选的细节。但这也是一把双刃剑，这恰恰是SAML协议的短板。作为实现者，需要同时兼顾这些可选的细节，这给开发者带来了很大的挑战。
从技术上来说，SAML协议是基于XML的，以断言的方式通过签名和加密来交换用户身份信息，类似于OIDC协议中的ID_Token。
SAML流程的参与者包括服务提供者和身份提供者，整个流程包括以下两种使用场景:
SP启动:服务提供商启动IDP启动:身份认证服务器启动。以下是一般的身份验证过程:
End请求从浏览器访问sp:https://www.example.com；当发现https://www.example.com用户未登录时，向IDP发起SAML的AuthnRequest请求，用户浏览器跳转到IDP页面；IDP发现用户未登录，将用户重定向到IDP的登录界面，并请求用户进行身份验证。用户在登录页面进行自我认证，通常需要验证用户名和密码；IDP验证用户的身份，如果成功，将包含用户身份信息的验证结果以SAML响应的形式签名/加密并发送给SP；SP得到用户身份信息后，进行签名验证/解密，得到明文形式的用户身份信息。此时，SP处于登录状态，可以为用户提供服务。可以看到，在整个过程中，IDP负责发布用户身份，SP负责信任IDP发布的用户身份。SP和IDP之间的信任关系需要提前建立，即SP和IDP需要提前相互预配置双方的信息，通过证书信任建立相互信任。
SAML协议的标准定义可以在以下文件中找到:
http://docs . oasis-open . org/security/SAML/post 2.0/sstc-SAML-tech-overview-2.0 . html
不及物动词各种协议的简单比较
以上简单介绍了几种主流的SSO协议。本质上是相似的，都是基于中心信任的机制。服务提供者和身份提供者通过相互信任来交换用户信息，只是每个协议的信息交换细节不同，或者说概念有些不同。
最后用一个简单的对照表来概括本文的重点内容:
更多单点登录的做法，可以搜索“玉韵IDaaS”，进入官网了解。
