什么是SSO

SSO( Single Sign On)，即单点登录。是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分。

简单来说，在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录；用户只需注销一次，各个系统即可感知该用户已经注销。

单系统登录

众所周知，HTTP是无状态的协议，这意味着服务器无法确认用户的信息。于是乎，W3C就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。

如果说Cookie是检查用户身上的”通行证“来确认用户的身份，那么Session就是通过检查服务器上的”客户明细表“来确认用户的身份的。Session相当于在服务器中建立了一份“客户明细表”。

HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一个用户。于是乎：服务器向用户浏览器发送了一个名为JESSIONID的Cookie，它的值是Session的id值。其实Session是依据Cookie来识别是否是同一个用户。

虽然单系统的登录解决方案很完美，但对于多系统应用群已经不再适用了，为什么呢？

单系统登录解决方案的核心是cookie，cookie携带会话id在浏览器与服务器之间维护会话状态。但cookie是有限制的，这个限制就是cookie的域（通常对应网站的域名），浏览器发送http请求时会自动携带与该域匹配的cookie，而不是所有cookie

既然这样，为什么不将web应用群中所有子系统的域名统一在一个顶级域名下，例如“*.baidu.com”，然后将它们的cookie域设置为“baidu.com”，这种做法理论上是可以的，甚至早期很多多系统登录就采用这种同域名共享cookie的方式。

共享cookie的方式存在众多局限。首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是web服务器）要相同，不然cookie的key值（tomcat为JSESSIONID）不同，无法维持会话，共享cookie的方式是无法实现跨语言技术平台登录的，比如java、php、.net系统之间；第三，cookie本身不安全。

多系统登录的问题和解决方式

Session 不共享问题

单系统登录功能主要是用Session保存用户信息来实现的，但我们清楚的是：多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。

解决系统之间Session不共享问题有一下几种方案：

  • Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）【会影响集群的性能呢，不建议】
  • 根据请求的IP进行Hash映射到对应的机器上（这就相当于请求的IP一直会访问同一个服务器）【如果服务器宕机了，会丢失了一大部分Session的数据，不建议】
  • 把Session数据放在Redis中（使用Redis模拟Session）【建议】

我们请求<https://www.google.com/>时，浏览器会自动把google.com的Cookie带过去给google的服务器，而不会把<https://www.baidu.com/>的Cookie带过去给google的服务器。

这就意味着，由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。

针对Cookie存在跨域问题，有几种解决方案：

  1. 服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来，此后请求都把这个Token带上就行了
  2. 多个域名共享Cookie，在写到客户端的时候设置Cookie的domain。
  3. 将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）

SSO-CAS

CAS （Central Authentication Service）

sso认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心建立全局会话（生成一份Token，写到Cookie中，保存在浏览器上）。随后，认证中心重定向回系统A，并把Token携带过去给系统A。

接着，系统A去sso认证中心验证这个Token是否正确，如果正确，则系统A和用户建立局部会话（创建Session）。到此，系统A和用户已经是登录状态了。

此时，用户想要访问系统Bwww.java4y.com受限的资源(比如说订单功能，订单功能需要登录后才能访问)，系统Bwww.java4y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。

注意，因为之前用户与认证中心www.sso.com已经建立了全局会话（当时已经把Cookie保存到浏览器上了），所以这次系统B重定向到认证中心www.sso.com是可以带上Cookie的。

认证中心根据带过来的Cookie发现已经与用户建立了全局会话了，认证中心重定向回系统B，并把Token携带过去给系统B。

接着，系统B去sso认证中心验证这个Token是否正确，如果正确，则系统B和用户建立局部会话（创建Session）。到此，系统B和用户已经是登录状态了。

其实SSO认证中心就类似一个中转站。

image-20240207114043185

SSO-JWT

JWT（JSON Web Token）是一种轻量级的开放标准（RFC 7519），用于在各方之间安全地传输信息。在SSO系统中，JWT被广泛应用于认证和授权，可以实现基于令牌的单点登录（SSO）。

JWT是一种自包含的令牌，它由三部分组成：头部、载荷和签名。头部包含了JWT类型和使用的加密算法；载荷包含了JWT所包含的信息，如用户身份、角色、权限等；签名则用于验证JWT的真实性和完整性。

在SSO系统中，JWT通常用于跨域认证和授权，实现以下流程：

  1. 用户在第一次登录时，SSO服务器会生成一个JWT令牌，并将该令牌发送给用户。
  2. 用户访问其他应用程序或系统时，将JWT令牌随请求一同发送给目标应用程序或系统。
  3. 目标应用程序或系统通过验证JWT令牌的签名，确认该令牌是由SSO服务器颁发的，并可以解析出JWT中的用户信息。
  4. 目标应用程序或系统可以根据JWT中的用户信息进行身份验证和授权，让用户在不同的应用程序或系统之间实现无缝切换。

SSO-企微认证

PaaS企微认证SSO是根据企业微信提供了OAuth的授权登录方式，可以让从企业微信终端打开的网页获取成员的身份信息，从而免去登录的环节。企业应用中的URL链接（包括自定义菜单或者消息中的链接），均可通过OAuth2.0验证接口来获取成员的UserId身份信息。

企微SSO再根据UserId查询用户表数据找到企微userid对应的用户信息，根据用户信息颁发JWT-token.

SSO-微信小程序认证

PaaS微信小程序认证是根据微信小程序登录 调用 wx.login() 获取 临时登录凭证code ，并回传到开发者服务器。
调用 auth.code2Session 接口，换取 用户唯一标识 OpenID 、 用户在微信开放平台帐号下的唯一标识UnionID（若当前小程序已绑定到微信开放平台帐号） 和 会话密钥 session_key，根据OpenID和UnionID 生成登录凭证。

SSO-OAuth 2.0

系统对接SSO-OAuth2.0,通过sso单点登录获取授权码并跳转到自己的系统,用授权码code获取用户信息比对自己的系统用户数据,以确认登录成功。

接入流程

image-20240122114748174

  1. 用户访问第三方服务，第三方服务通过构造OAuth2链接（参数包括当前第三方服务的身份ID，以及重定向URI），将用户引导到认证服务器的授权页
  2. 用户选择是否同意授权
  3. 若用户同意授权，则认证服务器将用户重定向到第一步指定的重定向URI，同时附上一个授权码。
  4. 第三方服务收到授权码，带上授权码来源的重定向URI，并向认证服务器申请凭证。
  5. 认证服务器检查授权码和重定向URI的有效性，通过后颁发AccessToken（调用凭证）,根据AccessToken和授权码可获得用户数据

OAuth2.0协议支持多种授权模式，如授权码模式、隐式授权模式、密码凭证授权模式、客户端模式等，每种模式都有不同的应用场景和安全性。

模式 说明
授权码模式 第三方应用先申请一个授权码code，然后根据code获取令牌accessToken
隐式授权模式 有些web应用为纯前端应用，该模式允许直接向前端颁发令牌
密码凭证授权模式 如果你高度信任某个应用，RFC 6379也允许用户把用户名和密码直接告诉该应用
客户端凭证模式 指客户端以自己的名义，而不是以用户的名义，向“服务提供商”进行认证

OAuth2.0协议的优点

  1. 安全性：OAuth2.0协议通过授权码、访问令牌等机制，保证了用户的资源不会被未经授权的第三方应用程序访问。
  2. 可扩展性：OAuth2.0协议支持多种授权模式，可以适用于不同类型的应用程序和系统。
  3. 简单性：OAuth2.0协议是一种简单的授权协议，易于实现和使用。
  4. 可移植性：OAuth2.0协议可以在不同的平台和语言之间使用，可以提高系统的可移植性和互操作性。

SSO-OIDC

英文全称为 OpenID Connect，缩写为 OIDC，是一个基于 OAuth2 协议的身份认证标准协议。它在 OAuth2 上构建了一个身份层，提供完善的身份认证功能。

OIDC的交互时序图如下：

image-20240207144926930