单点登录（SSO）小记
What
单点登录（SSO，Single Sign-On）指对于多个应用，只要在其中一个中登录了就可直接访问其中任一应用而不用再登录、同样地只要在其中一个登出了就不能再访问其中任一应用。借助SSO可以实现统一的Authenticate、Authorize服务。
SSO的方案：Gateway、CAS、SAML、OAuth2.0或OpenID Connect
SSO与OAuth2.0的区别：前者是一种思想，避免各应用要分别登录，后者是一种授权协议，可以实现前者的效果。SSO的实现有很多方案，比较流行的实现是CAS。
SSO与 Spring Security、Shiro 等的区别：后两者是具体的技术，用于实现SSO中的认证与鉴权。
实现方案
如下几种方案中，前面的方案可以视为后面的方案的特例，越后面的方案越通用。
方案1 - Gateway
弄一个统一的网关，所有服务都放在该网关后面，前端的任何请求都经过该网关，对用户的认证、授权、登出等都在网关层做。由网关负责进行用户Authenticate、Authorize、转发到下游服务等操作，下游服务不再需要进行Authenticate操作。在Java里通常是业务网关，如Zuul、Spring Gateway等。
在实现上既可以由网关直接去访问数据库校验用户也可以调用专门的用户中心服务来校验用户，但本质上都是有一个统一的用户中心。
显然，此法要求你对所有服务都有控制权，否则没法把它们组织到一个网关下。比如一个组内的各种产品（如教育产品线下的各子产品），或者一个产品背后的各种微服务。
特点：各服务需要有统一的用户中心；各服务不需要自己实现任何认证和授权逻辑（由网关统一实现）；要求方案实施者对各服务有绝对控制权，将各服务统一组织在网关背后。
方案2 - CAS（Central Authentication Service）
（参阅：https://developer.ibm.com/zh/articles/os-cn-cas/）
前面的方案要求所有产品在一个网关后面，然而实际上很多情况下该条件难以满足，比如你公司内的OA系统、EHR系统，硬要把它们组织到一个网关下对于开发、维护都会很麻烦。此时可用CAS。
从结构上看，CAS包括两部分：CAS Server 和 CAS Client。
CAS Server 需要独立部署，主要负责对用户的认证工作；可在此直接去访问数据库校验用户也可以调用专门的用户中心服务来校验用户。
CAS Client 与受保护的客户端应用部署在一起，负责处理对客户端受保护资源的访问请求。需要登录时，重定向到 CAS Server。
过程概要：浏览器访问某个应用，应用通过CAS Client发现尚未登录（无session信息）则将浏览器重定向CAS Server；CAS Server让用户登录然后签发与该Service关联的ticket返回给浏览器，并重定向回该Service；Service拿着ticket向CAS Server校验ticket并请求用户信息，设置session，然后返回sessionId给浏览器；之后通过session信息交互。
协议具体工作过程如下：
CAS Client 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。
对于访问受保护资源的每个 Web 请求，CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket，如果没有，则说明当前用户尚未登录，于是将请求重定向到指定好的 CAS Server 登录地址，并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。
用户在第 3 步中输入认证信息，如果登录成功，CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket，并缓存以待将来验证，之后系统自动重定向到 Service 所在地址，并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后，在第 5，6 步中与 CAS Server 进行身份验证，以确保 Service Ticket 的合法性。
简而言之，此方案有专门的CAS Server负责认证，而每个应用都要集成CAS Client；当前端访问应用时，CAS Client会校验用户是否登录，若未登录则定向到CAS Server让用户登录并从CAS Server获得用户的信息。
与Gateway方案相比，CAS不再要求所有应用在一个网关后（实际上也可以将CAS视为一个逻辑上的Gateway，从这角度上看与上一个方案一样），但仍需要有一个统一的用户中心。
特点：各服务需要有统一的用户中心；各服务需要自己实现部分的认证和授权逻辑（集成CAS Client、与CAS Server交互）；各服务通常同属于一个组织，如公司。
此方式下的具体处理过程：
登录：
登出：
更多参考资料：
https://www.cnblogs.com/ywlaker/p/6113927.html
https://blog.csdn.net/anumbrella/article/details/80821486
https://github.com/xuxueli/xxl-sso/tree/master/xxl-sso-server （实现）
方案3 - SAML（Security Assertion Markup Language）
（参阅：http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html、https://developers.onelogin.com/saml）
当没有一个统一的用户中心时（如不同公司的产品整合做到单点登录的效果），上述方案都不可行了，此时可用SAML，SAML可使不相关的两个系统互认身份。
SAML是个Authenticate、Authorize协议。它定义了一套XML语法，用于将用户的唯一标识从一个应用（身份提供者）中的转换为另一应用（服务提供者）中的，这用户在后者中并不存在、且两应用没有共同的用户中心。
协议具体工作过程：
SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.
Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:
The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
The identity of the user is established and the user is provided with app access.
与CAS类似，此方案也需要各应用实现SAML协议的交换逻辑。
特点：不需要各服务有统一的用户中心；各服务需要自己实现部分的认证和授权逻辑（实现SAML协交换逻辑）；不要求各服务同属于一个组织，可以是任意不同服务。
方案4 - OAuth2.0/OpenID Connect
OAuth2.0协议用来授权第三方站点来访问本站点的资源。当这里的“资源”指用户信息时，通常就可用当前站点的账号来登录第三方系统。常见的很多站点上的“用微信登录”、“用QQ登录”等就是用的此协议。
OAuth2.0大多用在互不相关无法互相控制的两个系统间，而不是像CAS一样各个子系统处于一个组织或公司下可以自己控制。借助此协议，只要多个系统中有一个是OAuth Authorization Server，其他系统就可以当做是该Server的Oauth Client，这样就可以以Server中的用户来登录这些系统。
此方案的效果看上去很像SSO，但严格来说不是SSO方案，因为通常每个系统内部还会维护用户信息表，表中维护本系统用户与OAuth Server用户的关联关系。
20210407更新：此方案实际上有专门的标准，OpenID Connect。
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by Clients by including the openid scope value in the Authorization Request. Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token (see Section 2). OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs). OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs).
特点：不需要各服务有统一的用户中心；各服务需要自己实现部分的认证和授权逻辑（实现OAuth授权流程）；不要求各服务同属于一个组织，可以是任意不同服务。
