一、单系统登录机制

http无状态：任何用户都能访问，如何保护特殊资源？如何识别同一用户？

会话机制

• 原理： 服务器和客户端共同维护一个状态

• 实现：客户端第一次请求服务器，服务器创建一个会话并将会话Id作为响应的一部分返回给客户端，客户端存储会话Id，并在后续的请求中带上会话Id，服务器端根据请求中的Id识别是否同一用户

• 会话id存储介质(会话上下文)

· 1.每次请求参数，方式不靠谱

· 2.Cookie：认证成功后，服务器端将token/令牌注入到Cookie上下文返回客户端，客户端下次访问自动携带Cookie信息

tomcat：SessionId key是JSESSIONID

二、多系统的复杂性

背景：多系统组成的应用群，复杂性应该由系统内部承担，而不是用户

一个多系统整体，用户只需登录和注销一次

核心问题：多系统为什么不能同步登录状态？

1、前端token无法在多系统之间共享

2、后端Session无法在多系统之间共享

解决方案：

1、共享Cookie同步会话

概述：前端同域、后端同Redis

· 1、共享Cookie来解决token共享问题

o 主域名Cookie在二级域名下的共享

o stp.com下的Cookie，在s1.stp.com、s2.stp.com等子域名都是可以共享访问

· 2.使用Redis解决Session共享问题

o Alone独立Redis插件 做到权限缓存直连 SSO-Redis 数据中心

2、URL重定向传播会话

· 问题：跨域模式下共享Cookie失效

· 概述：前端不同域、后端同Redis

· 实现思路

3、Http请求获取会话

· 概述：前端不同域、后端不同Redis

· 问题分析

o 后端不使用共享 Redis 时，会对架构产生哪些影响：1.Client 端无法直连 Redis 校验 ticket，取出账号id。2.Client 端无法与 Server 端共用一套会话，需要自行维护子会话。3.由于不是一套会话，所以无法“一次注销，全端下线”，需要额外编写代码完成单点注销。

o 无刷单点注销:有了单点登录就必然要有单点注销，网上给出的大多数解决方案是将注销请求重定向至SSO-Server中心，逐个通知Client端下线在某些场景下，页面的跳转可能造成不太好的用户体验，Sa-Token-SSO 允许你以 REST API 的形式构建接口，做到页面无刷新单点注销。1.Client 端在校验 ticket 时，将注销回调地址发送到 Server 端。2.Server 端将此 Client 的注销回调地址存储到 Set 集合。3.Client 端向 Server 端发送单点注销请求。4.Server 端遍历Set集合，逐个通知 Client 端下线。5.Server 端注销下线。6.单点注销完成。

总结

模式一 【前端同域 + 后端同redis】：采用共享 Cookie 来做到前端 Token 的共享，从而达到后端的 Session 会话共享

模式二【前端不同域 + 后端同redis】：采用 URL 重定向，以 ticket 码为授权中介，做到多个系统间的会话传播

模式三【前端不同域 + 后端不同redis】：采用 Http 请求主动查询会话，做到 Client 端与 Server 端的会话同步

三、SSO

SSO【Single Sign On】

在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分

原理

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

具体实现

统一认证中心 sso-server

· 用户认证【验证用户名/密码】

· 创建全局会话

· 创建授权令牌

· 与client通信授予令牌

· 校验令牌有效性

· 系统注册

· 接收client注销请求，注销所有会话

认证客户端 【SDK】sso-client

· 拦截子系统未登录的请求，跳转至sso认证中心

· 接收并存储sso认证中心发送的令牌

· 与sso通信校验令牌的有效性

· 建立局部会话

· 拦截用户的注销请求，向sso认证中心发送注销请求

· 接收sso认证中心发出的注销请求，销毁局部会话

部署图

四、思维导图

更多明细请查看思维导图：