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认证中心的通信了。

 

posted @ 2024-06-28 09:08  吴飞ff  阅读(22)  评论(0编辑  收藏  举报