SSO单点登录总结

参考：https://blog.csdn.net/qq_46110252/article/details/137470096 

单点登录概念：

　　简单说，就是多个系统只要登录一次就可以。进入其它系统就不用再次登录 可以正常访问。如，登录了淘宝网站，跳转到天猫的网站直接就正常访问了。（这里不详细说明）

　　

流程说明：

1. 首次登录： 用户首次访问淘宝网站。在登录页面，用户输入阿里巴巴的统一账户（例如阿里巴巴账号和密码）。
2. SSO认证： 阿里巴巴的SSO系统对用户进行身份验证，验证通过后生成一个令牌（Token）。
3. 令牌颁发： 身份验证成功后，SSO系统颁发一个令牌给用户。
4. 令牌使用： 用户使用该令牌访问淘宝网站。这个令牌包含有关用户身份的信息。
5. 无需重新登录访问天猫： 用户在淘宝登录后，无需重新输入账号和密码，即可直接访问天猫网站。令牌的有效性使用户能够在淘宝和天猫之间实现无缝切换。

   

    说明下：有的系统自己也有登录页就不用跳转SSO的登录页了。但是本质是一样的，登录接口还是要转发到SSO认证中心的 获取token的。

单点登录原理

​ 相比于单系统登录，SSO需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，SSO认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理，用下图说明。

下面对上图简要描述：

1. 用户初次访问或未携带 Token：

   • 应用1检测到用户初次访问或未携带 Token。
   • 应用1发现缺少 Token。
   • 应用1返回登录地址给浏览器，并触发浏览器跳转到该登录地址。

2. 用户登录认证：

   • 用户向 SSO 认证中心进行登录。
   • SSO 认证中心验证用户信息成功后，生成 Token 和过期时间。
   • 将 Token 和过期时间返回给浏览器。

3. Token 存储与传递：

   • 前端将 Token 存储在浏览器的 Cookie 中，域名设置为 test.com。

4. 再次访问应用1时：

   • 用户再次请求应用1，并携带 Token 在请求头中。

5. 本地缓存中获取用户信息：

   • 应用1从本地缓存中通过 Token 获取用户信息。

6. 获取不到用户信息时，向 SSO 获取：

   • 若本地缓存中未找到用户信息，应用1通过 Token 向 SSO 认证中心获取用户信息。

7. SSO 验证 Token：

   • SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给应用1。

8. 本地缓存用户信息：

   • 应用1将用户信息、Token 和过期时间缓存在本地。

9. 进一步鉴权和资源返回：

   • 应用1进行进一步鉴权，验证成功后返回受保护资源。

10. 使用相同 Token 再次获取资源：

    • 用户下一次使用相同 Token 请求资源。

11. 本地缓存中获取用户信息再次鉴权：

    • 应用1通过 Token 从本地获取用户信息。

12. 鉴权成功后返回资源：

    • 获取到用户信息后再次进行鉴权，成功后返回受保护资源。

13. 用户向虚拟电厂平台发起请求：

    • 用户从 Cookie 中获取 Token 并携带访问虚拟电厂平台。

14. 虚拟电厂平台获取用户信息：

    • 虚拟电厂平台通过 Token 从本地缓存中获取用户信息。

15. 获取不到用户信息时，向 SSO 获取：

    • 若本地缓存中未找到用户信息，虚拟电厂平台通过 Token 向 SSO 认证中心获取用户信息和 Token 过期时间。

16. SSO 验证 Token：

    • SSO 认证中心验证 Token 成功后，将用户信息和 Token 过期时间返回给虚拟电厂平台。

17. 虚拟电厂平台本地缓存用户信息：

    • 虚拟电厂平台将用户信息、Token 和过期时间缓存在本地。

18. 虚拟电厂平台进一步鉴权和资源返回：

    • 虚拟电厂平台进行进一步鉴权，验证成功后返回受保护资源。

19. 用户登出：

    • 用户向 SSO 认证中心进行登出。

20. Token 销毁和消息队列通知：

    • SSO 认证中心对 Token 进行验证，验证成功后销毁 Token。
    • SSO 认证中心通过消息队列向各个子系统发送通知，销毁局部 Token。

前端需要做的逻辑

1. 创建单独的登录页面：
   • 前端需要设计并创建一个单独的登录页面，用于用户进行身份验证。这个页面可以由SSO认证中心提供接口。
2. 跳转到登录页面：
   • 当用户访问各个系统时返回需要登录提示时，前端需要触发浏览器跳转到登录页面。可以通过重定向或打开新的登录窗口的方式实现。
3. 处理登录成功后的 Token：
   • 在登录页面完成用户身份验证后，前端需要将从服务器获取的 Token 存储在浏览器的 Cookie 中，同时设置域名为 test.com。
4. 在请求中携带 Token：
   • 在向各个系统发起请求时，前端需要从浏览器的 Cookie 中获取 Token，并将 Token 放置在请求头中，以便进行身份验证。
5. 处理各系统的登出操作：
   • 前端需要在各个系统中实现登出功能。当用户点击登出按钮时，前端应该向 SSO 认证中心发起登出请求，实现单点登出。
6. 处理各系统的更新 Token 操作：
   • 如果各个系统需要更新 Token，前端应该向 SSO 认证中心发起更新 Token 的请求，确保用户的身份信息保持最新。
7. 与SSO进行通信：
   • 前端需要处理与 SSO 认证中心的通信。这包括处理登录请求、登出请求以及更新 Token 的请求。使用适当的前端框架或库，例如 Axios 或 Fetch API，可以更方便地进行这些操作。

 

 

个人总结：

1. 登录 SSO 认证中心，获取到 token令牌。应用系统拿着 token 去SSO认证中心 验证，有效就会返回 用户信息（就是前端常用的 getUserInfoByToken 接口）。
   第一个系统登录了，第二个系统是没有登录，所以必须经过  SSO 认证中心 验证 这一步的。
2. 前端页面和系统认证是通过token的，后端会存储这个token对应的 用户信息（session信息）。
3. 不同应用系统。他们的session是独立的。应用系统A有token对应的session，应用系统B中不一定有（应用B必须拿着token去SSO验证下）。只有先经过验证的应用系统，该应用前端调用后端携带的token才会认证通过。如果系统B没有经过验证，系统B的前端直接拿着系统A的token调用系统B的接口，系统B肯定是无法认证的（可能报未认证）。
   注意：有的系统后端不使用session，而是使用 redis。道理是一样的，应用系统中存储token对应的 用户信息。
4. 应用系统和SSO认证中心，有3个基本的通信。登录，验证（也是获取用户信息），登出。
5. 应用系统和SSO认证通过后，后面系统前端调用系统后端接口，正常情况 就不会再调用SSO认证中心的通信了。