SSO单点登录总结
参考：https://blog.csdn.net/qq_46110252/article/details/137470096
单点登录概念：
简单说，就是多个系统只要登录一次就可以。进入其它系统就不用再次登录 可以正常访问。如，登录了淘宝网站，跳转到天猫的网站直接就正常访问了。（这里不详细说明）
流程说明：
- 首次登录： 用户首次访问淘宝网站。在登录页面，用户输入阿里巴巴的统一账户（例如阿里巴巴账号和密码）。
- SSO认证： 阿里巴巴的SSO系统对用户进行身份验证，验证通过后生成一个令牌（Token）。
- 令牌颁发： 身份验证成功后，SSO系统颁发一个令牌给用户。
- 令牌使用： 用户使用该令牌访问淘宝网站。这个令牌包含有关用户身份的信息。
- 无需重新登录访问天猫： 用户在淘宝登录后，无需重新输入账号和密码，即可直接访问天猫网站。令牌的有效性使用户能够在淘宝和天猫之间实现无缝切换。
说明下：有的系统自己也有登录页就不用跳转SSO的登录页了。但是本质是一样的，登录接口还是要转发到SSO认证中心的 获取token的。
单点登录原理
相比于单系统登录，SSO需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，SSO认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理，用下图说明。
下面对上图简要描述：
-
用户初次访问或未携带 Token：
- 应用1检测到用户初次访问或未携带 Token。
- 应用1发现缺少 Token。
- 应用1返回登录地址给浏览器，并触发浏览器跳转到该登录地址。
-
用户登录认证：
- 用户向 SSO 认证中心进行登录。
- SSO 认证中心验证用户信息成功后，生成 Token 和过期时间。
- 将 Token 和过期时间返回给浏览器。
-
Token 存储与传递：
- 前端将 Token 存储在浏览器的 Cookie 中，域名设置为 test.com。
-
再次访问应用1时：
- 用户再次请求应用1，并携带 Token 在请求头中。
-
本地缓存中获取用户信息：
- 应用1从本地缓存中通过 Token 获取用户信息。
-
获取不到用户信息时，向 SSO 获取：
- 若本地缓存中未找到用户信息，应用1通过 Token 向 SSO 认证中心获取用户信息。
-
SSO 验证 Token：
- SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给应用1。
-
本地缓存用户信息：
- 应用1将用户信息、Token 和过期时间缓存在本地。
-
进一步鉴权和资源返回：
- 应用1进行进一步鉴权，验证成功后返回受保护资源。
-
使用相同 Token 再次获取资源：
- 用户下一次使用相同 Token 请求资源。
-
本地缓存中获取用户信息再次鉴权：
- 应用1通过 Token 从本地获取用户信息。
-
鉴权成功后返回资源：
- 获取到用户信息后再次进行鉴权，成功后返回受保护资源。
-
用户向虚拟电厂平台发起请求：
- 用户从 Cookie 中获取 Token 并携带访问虚拟电厂平台。
-
虚拟电厂平台获取用户信息：
- 虚拟电厂平台通过 Token 从本地缓存中获取用户信息。
-
获取不到用户信息时，向 SSO 获取：
- 若本地缓存中未找到用户信息，虚拟电厂平台通过 Token 向 SSO 认证中心获取用户信息和 Token 过期时间。
-
SSO 验证 Token：
- SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给虚拟电厂平台。
-
虚拟电厂平台本地缓存用户信息：
- 虚拟电厂平台将用户信息、Token 和过期时间缓存在本地。
-
虚拟电厂平台进一步鉴权和资源返回：
- 虚拟电厂平台进行进一步鉴权，验证成功后返回受保护资源。
-
用户登出：
- 用户向 SSO 认证中心进行登出。
-
Token 销毁和消息队列通知：
- SSO 认证中心对 Token 进行验证，验证成功后销毁 Token。
- SSO 认证中心通过消息队列向各个子系统发送通知，销毁局部 Token。
前端需要做的逻辑
- 创建单独的登录页面：
- 前端需要设计并创建一个单独的登录页面，用于用户进行身份验证。这个页面可以由SSO认证中心提供接口。
- 跳转到登录页面：
- 当用户访问各个系统时返回需要登录提示时，前端需要触发浏览器跳转到登录页面。可以通过重定向或打开新的登录窗口的方式实现。
- 处理登录成功后的 Token：
- 在登录页面完成用户身份验证后，前端需要将从服务器获取的 Token 存储在浏览器的 Cookie 中，同时设置域名为 test.com。
- 在请求中携带 Token：
- 在向各个系统发起请求时，前端需要从浏览器的 Cookie 中获取 Token，并将 Token 放置在请求头中，以便进行身份验证。
- 处理各系统的登出操作：
- 前端需要在各个系统中实现登出功能。当用户点击登出按钮时，前端应该向 SSO 认证中心发起登出请求，实现单点登出。
- 处理各系统的更新 Token 操作：
- 如果各个系统需要更新 Token，前端应该向 SSO 认证中心发起更新 Token 的请求，确保用户的身份信息保持最新。
- 与SSO进行通信：
- 前端需要处理与 SSO 认证中心的通信。这包括处理登录请求、登出请求以及更新 Token 的请求。使用适当的前端框架或库，例如 Axios 或 Fetch API，可以更方便地进行这些操作。
个人总结：
- 登录 SSO 认证中心，获取到 token令牌。应用系统拿着 token 去SSO认证中心 验证，有效就会返回 用户信息（就是前端常用的 getUserInfoByToken 接口）。
第一个系统登录了，第二个系统是没有登录，所以必须经过 SSO 认证中心 验证 这一步的。 - 前端页面和系统认证是通过token的，后端会存储这个token对应的 用户信息（session信息）。
- 不同应用系统。他们的session是独立的。应用系统A有token对应的session，应用系统B中不一定有（应用B必须拿着token去SSO验证下）。只有先经过验证的应用系统，该应用前端调用后端携带的token才会认证通过。如果系统B没有经过验证，系统B的前端直接拿着系统A的token调用系统B的接口，系统B肯定是无法认证的（可能报未认证）。
注意：有的系统后端不使用session，而是使用 redis。道理是一样的，应用系统中存储token对应的 用户信息。 - 应用系统和SSO认证中心，有3个基本的通信。登录，验证（也是获取用户信息），登出。
- 应用系统和SSO认证通过后，后面系统前端调用系统后端接口，正常情况 就不会再调用SSO认证中心的通信了。
