欢迎大家关注 github.com/hsfxuebao ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈
1. 单系统登录机制
1.1 http无状态协议
web应用采用browser/server架构，http作为通信协议。http是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程用下图说明，三次请求/响应对之间没有任何联系
但这也同时意味着，任何用户都能通过浏览器访问服务器资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求，响应合法请求，忽略非法请求；要鉴别浏览器请求，必须清楚浏览器请求状态。既然http协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制
1.2 会话机制
浏览器第一次请求服务器，服务器创建一个会话，并将会话的id作为响应的一部分发送给浏览器，浏览器存储会话id，并在后续第二次和第三次请求中带上会话id，服务器取得请求中的会话id就知道是不是同一个用户了，这个过程用下图说明，后续请求与第一次请求产生了关联
服务器在内存中保存会话对象，浏览器怎么保存会话id呢？你可能会想到两种方式:
请求参数
cookie
将会话id作为每一个请求的参数，服务器接收请求自然能解析参数获得会话id，并借此判断是否来自同一会话，很明显，这种方式不靠谱。那就浏览器自己来维护这个会话id吧，每次发送http请求时浏览器自动发送会话id，cookie机制正好用来做这件事。cookie是浏览器用来存储少量数据的一种机制，数据以”key/value“形式存储，浏览器发送http请求时自动附带cookie信息
tomcat会话机制当然也实现了cookie，访问tomcat服务器时，浏览器中可以看到一个名为“JSESSIONID”的cookie，这就是tomcat会话机制维护的会话id，使用了cookie的请求响应过程如下图
1.3 登录状态
有了会话机制，登录状态就好明白了，我们假设浏览器第一次请求服务器需要输入用户名与密码验证身份，服务器拿到用户名密码去数据库比对，正确的话说明当前持有这个会话的用户是合法用户，应该将这个会话标记为“已授权”或者“已登录”等等之类的状态，既然是会话的状态，自然要保存在会话对象中，tomcat在会话对象中设置登录状态如下
HttpSession session = request.getSession();session.setAttribute("isLogin", true);用户再次访问时，tomcat在会话对象中查看登录状态
HttpSession session = request.getSession();session.getAttribute("isLogin");实现了登录状态的浏览器请求服务器模型如下图描述
每次请求受保护资源时都会检查会话对象中的登录状态，只有 isLogin=true 的会话才能访问，登录机制因此而实现。
2. 多系统的复杂性
web系统早已从久远的单系统发展成为如今由多系统组成的应用群，面对如此众多的系统，用户难道要一个一个登录、然后一个一个注销吗？就像下图描述的这样
web系统由单系统发展成多系统组成的应用群，复杂性应该由系统内部承担，而不是用户。无论web系统内部多么复杂，对用户而言，都是一个统一的整体，也就是说，用户访问web系统的整个应用群与访问单个系统一样，登录/注销只要一次就够了
2.1 为什么会出现跨域问题
浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同，都是跨域。在前后端分离的模式下，前后端的域名是不一致的，此时就会发生跨域访问问题。在请求的过程中我们要想回去数据一般都是post/get请求，所以..跨域问题出现。出于浏览器的同源策略限制。
同源策略（Sameoriginpolicy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。
可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。
同源策略会阻止一个域的javascript脚本和另外一个域的内容进行交互。
所谓同源（即指在同一个域）就是两个页面具有相同的协议（protocol），主机（host）和端口号（port）
2.2 什么是跨域
当一个请求 url 的协议、域名、端口三者之间任意一个与当前页面 url 不同即为跨域
当前页面url 被请求页面url 是否跨域 原因
http://www.test.com/ 和 http://www.test.com/index.html 否 同源（协议、域名、端口号相同）
http://www.test.com/ 和 https://www.test.com/index.html 跨域 协议不同（http/https）
http://www.test.com/ 和 百度一下，你就知道 跨域 主域名不同（test/baidu）
http://www.test.com/ 和 http://blog.test.com/ 跨域 子域名不同（www/blog）
http://www.test.com:8080/ 和 http://www.test.com:7001/ 跨域 端口号不同（8080/7001）
2.3 多系统解决方案
虽然单系统的登录解决方案很完美，但对于多系统应用群已经不再适用了，为什么呢？
单系统登录解决方案的核心是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本身不安全。
因此，我们需要一种全新的登录方式来实现多系统应用群的登录，这就是单点登录
3. 单点登录
什么是单点登录？单点登录全称Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录，包括单点登录与单点注销两部分
3.1 登录
相比于单系统登录，sso需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，sso认证中心验证用户的用户名密码没问题，创建授权令牌，在接下来的跳转过程中，授权令牌作为参数发送给各个子系统，子系统拿到令牌，即得到了授权，可以借此创建局部会话，局部会话登录方式与单系统的登录方式相同。这个过程，也就是单点登录的原理，用下图说明
下面对上图简要描述:
用户访问系统1的受保护资源，系统1发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数
sso认证中心发现用户未登录，将用户引导至登录页面
用户输入用户名密码提交登录申请
sso认证中心校验用户信息，创建用户与sso认证中心之间的会话，称为全局会话，同时创建授权令牌
sso认证中心带着令牌跳转会最初的请求地址（系统1）
系统1拿到令牌，去sso认证中心校验令牌是否有效
sso认证中心校验令牌，返回有效，注册系统1
系统1使用该令牌创建与用户的会话，称为局部会话，返回受保护资源
用户访问系统2的受保护资源
系统2发现用户未登录，跳转至sso认证中心，并将自己的地址作为参数
sso认证中心发现用户已登录，跳转回系统2的地址，并附上令牌
系统2拿到令牌，去sso认证中心校验令牌是否有效
sso认证中心校验令牌，返回有效，注册系统2
系统2使用该令牌创建与用户的局部会话，返回受保护资源
用户登录成功之后，会与sso认证中心及各个子系统建立会话，用户与sso认证中心建立的会话称为全局会话，用户与各个子系统建立的会话称为局部会话，局部会话建立之后，用户访问子系统受保护资源将不再通过sso认证中心，全局会话与局部会话有如下约束关系:
局部会话存在，全局会话一定存在
全局会话存在，局部会话不一定存在
全局会话销毁，局部会话必须销毁
你可以通过博客园、百度、csdn、淘宝等网站的登录过程加深对单点登录的理解，注意观察登录过程中的跳转url与参数
3.2 注销
单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明
sso认证中心一直监听全局会话的状态，一旦全局会话销毁，监听器将通知所有注册系统执行注销操作
下面对上图简要说明:
用户向系统1发起注销请求
系统1根据用户与系统1建立的会话id拿到令牌，向sso认证中心发起注销请求
sso认证中心校验令牌有效，销毁全局会话，同时取出所有用此令牌注册的系统地址
sso认证中心向所有注册系统发起注销请求
各注册系统接收sso认证中心的注销请求，销毁局部会话
sso认证中心引导用户至登录页面
4. 实现
只是简要介绍下基于java的实现过程，不提供完整源码，明白了原理，我相信你们可以自己实现。sso采用客户端/服务端架构，我们先看sso-client与sso-server要实现的功能（下面：sso认证中心=sso-server）
sso-client:
拦截子系统未登录用户请求，跳转至sso认证中心
接收并存储sso认证中心发送的令牌
与sso-server通信，校验令牌的有效性
建立局部会话
拦截用户注销请求，向sso认证中心发送注销请求
接收sso认证中心发出的注销请求，销毁局部会话
sso-server:
验证用户的登录信息
创建全局会话
创建授权令牌
与sso-client通信发送令牌
校验sso-client令牌有效性
系统注册
接收sso-client注销请求，注销所有会话
接下来，我们按照原理来一步步实现sso吧！
4.1 sso-client拦截未登录请求
java拦截请求的方式有servlet、filter、listener三种方式，我们采用filter。在sso-client中新建LoginFilter.java类并实现Filter接口，在doFilter()方法中加入对未登录用户的拦截
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse res = (HttpServletResponse) response; HttpSession session = req.getSession(); if (session.getAttribute("isLogin")) { chain.doFilter(request, response); return; } //跳转至sso认证中心 res.sendRedirect("sso-server-url-with-system-url");}4.2 sso-server拦截未登录请求
拦截从sso-client跳转至sso认证中心的未登录请求，跳转至登录页面，这个过程与sso-client完全一样
4.3 sso-server验证用户登录信息
用户在登录页面输入用户名密码，请求登录，sso认证中心校验用户信息，校验成功，将会话状态标记为“已登录”
@RequestMapping("/login")public String login(String username, String password, HttpServletRequest req) { this.checkLoginInfo(username, password); req.getSession().setAttribute("isLogin", true); return "success";}4.4、sso-server创建授权令牌
授权令牌是一串随机字符，以什么样的方式生成都没有关系，只要不重复、不易伪造即可，下面是一个例子
String token = UUID.randomUUID().toString();
4.5、sso-client取得令牌并校验
sso认证中心登录后，跳转回子系统并附上令牌，子系统（sso-client）取得令牌，然后去sso认证中心校验，在LoginFilter.java的doFilter()中添加几行
// 请求附带token参数String token = req.getParameter("token");if (token != null) { // 去sso认证中心校验token boolean verifyResult = this.verify("sso-server-verify-url", token); if (!verifyResult) { res.sendRedirect("sso-server-url"); return; } chain.doFilter(request, response);}verify()方法使用httpClient实现，这里仅简略介绍，httpClient详细使用方法请参考官方文档
HttpPost httpPost = new HttpPost("sso-server-verify-url-with-token");HttpResponse httpResponse = httpClient.execute(httpPost);4.6 sso-server接收并处理校验令牌请求
用户在sso认证中心登录成功后，sso-server创建授权令牌并存储该令牌，所以，sso-server对令牌的校验就是去查找这个令牌是否存在以及是否过期，令牌校验成功后sso-server将发送校验请求的系统注册到sso认证中心（就是存储起来的意思）
令牌与注册系统地址通常存储在key-value数据库（如redis）中，redis可以为key设置有效时间也就是令牌的有效期。redis运行在内存中，速度非常快，正好sso-server不需要持久化任何数据。
令牌与注册系统地址可以用下图描述的结构存储在redis中，可能你会问，为什么要存储这些系统的地址？如果不存储，注销的时候就麻烦了，用户向sso认证中心提交注销请求，sso认证中心注销全局会话，但不知道哪些系统用此全局会话建立了自己的局部会话，也不知道要向哪些子系统发送注销请求注销局部会话
4.7 sso-client校验令牌成功创建局部会话
令牌校验成功后，sso-client将当前局部会话标记为“已登录”，修改LoginFilter.java，添加几行
if (verifyResult) { session.setAttribute("isLogin", true);}sso-client还需将当前会话id与令牌绑定，表示这个会话的登录状态与令牌相关，此关系可以用java的hashmap保存，保存的数据用来处理sso认证中心发来的注销请求
4.8、注销过程
用户向子系统发送带有“logout”参数的请求（注销请求），sso-client拦截器拦截该请求，向sso认证中心发起注销请求
String logout = req.getParameter("logout");if (logout != null) { this.ssoServer.logout(token);}sso认证中心也用同样的方式识别出sso-client的请求是注销请求（带有“logout”参数），sso认证中心注销全局会话
@RequestMapping("/logout")public String logout(HttpServletRequest req) { HttpSession session = req.getSession(); if (session != null) { session.invalidate();//触发LogoutListener } return "redirect:/";}sso认证中心有一个全局会话的监听器，一旦全局会话注销，将通知所有注册系统注销
HttpSession session = request.getSession();session.getAttribute("isLogin");05. 快速接入SSO
5.1 xxl-sso特性
简洁：API直观简洁，可快速上手
轻量级：环境依赖小，部署与接入成本较低
单点登录：只需要登录一次就可以访问所有相互信任的应用系统
分布式：接入SSO认证中心的应用，支持分布式部署
HA：Server端与Client端，均支持集群部署，提高系统可用性
跨域：支持跨域应用接入SSO认证中心
Cookie+Token均支持：支持基于Cookie和基于Token两种接入方式，并均提供Sample项目
Web+APP均支持：支持Web和APP接入
实时性：系统登陆、注销状态，全部Server与Client端实时共享
CS结构：基于CS结构，包括Server"认证中心"与Client"受保护应用"
记住密码：未记住密码时，关闭浏览器则登录态失效；记住密码时，支持登录态自动延期，在自定义延期时间的基础上，原则上可以无限延期
路径排除：支持自定义多个排除路径，支持Ant表达式,用于排除SSO客户端不需要过滤的路径
5.2 环境
JDK：1.7+
Redis：4.0+
5.3 下载xxl-sso源码
5.4 文档地址
中文文档
5.5 项目结构说明
HttpSession session = request.getSession();session.getAttribute("isLogin");15.6 基于Token方式部署
由于前后端分离开发的模式较多，这里只介绍基于Token方式部署，在一些无法使用Cookie的场景下，可使用该方式，如需要Cookie查看基于cookie方式部署
5.6.1 认证中心（SSO Server）搭建
项目名：xxl-sso-server
配置文件位置：application.properties
HttpSession session = request.getSession();session.getAttribute("isLogin");25.6.2 单点登陆Client端搭建
项目名：xxl-sso-token-sample-springboot
maven依赖
HttpSession session = request.getSession();session.getAttribute("isLogin");3配置文件：application.properties
HttpSession session = request.getSession();session.getAttribute("isLogin");4配置 XxlSsoTokenFilter
HttpSession session = request.getSession();session.getAttribute("isLogin");55.6.3 验证 (模拟请求 Token 方式接入SSO的接口)
修改Host文件：域名方式访问认证中心，模拟跨域与线上真实环境
HttpSession session = request.getSession();session.getAttribute("isLogin");6分别运行 "xxl-sso-server" 与 "xxl-sso-token-sample-springboot"
认证中心搭建成功后，默认为Token方式登陆提供API接口:
1、登陆接口：/app/login
code：200 表示成功、其他失败
msg：错误提示
data: 登陆用户的 sso sessionid
username：账号
password：账号
参数：POST参数
响应：JSON格式
2、注销接口：/app/logout
code：200 表示成功、其他失败
msg：错误提示
sessionId：登陆用户的 sso sessionid
参数：POST参数
响应：JSON格式
3、登陆状态校验接口：/app/logincheck
code：200 表示成功、其他失败
msg：错误提示
data：登陆用户信息
userid：用户ID
username：用户名
sessionId：登陆用户的 sso sessionid
参数：POST参数
响应：JSON格式
idea的http client测试如下：
HttpSession session = request.getSession();session.getAttribute("isLogin");7SSO登录/注销流程验证：
可参考测试用例 ：com.xxl.app.sample.test.TokenClientTest
正常情况下，登录流程如下：
1、获取用户输入的账号密码后，请求SSO Server的登录接口，获取用户 sso sessionid ；（参考代码：TokenClientTest.loginTest）
2、登陆成功后，获取到 sso sessionid ，需要主动存储，后续请求时需要设置在 Header参数 中
3、此时，使用 sso sessionid 访问受保护的 "Client01应用" 和 "Client02应用" 提供的接口，接口均正常返回（参考代码：TokenClientTest.clientApiRequestTest）
正常情况下，注销流程如下：
1、请求SSO Server的注销接口，注销登陆凭证 sso sessionid ；（参考代码：TokenClientTest.logoutTest）
2、注销成功后，sso sessionid 将会全局失效
3、此时，使用 sso sessionid 访问受保护的 "Client01应用" 和 "Client02应用" 提供的接口，接口请求将会被拦截，提示未登录并返回状态码 501（参考代码：TokenClientTest.clientApiRequestTest）
6. 总体设计
6.1 架构图
6.2 功能定位
XXL-SSO 是一个分布式单点登录框架。只需要登录一次就可以访问所有相互信任的应用系统。
借助 XXL-SSO，可以快速实现分布式系统单点登录。
6.3 核心概念
6.4 登录流程剖析
用户于Client端应用访问受限资源时，将会自动 redirect 到 SSO Server 进入统一登录界面
用户登录成功之后将会为用户分配 SSO SessionId 并 redirect 返回来源Client端应用，同时附带分配的 SSO SessionId
在Client端的SSO Filter里验证 SSO SessionId 无误，将 SSO SessionId 写入到用户浏览器Client端域名下 cookie 中
SSO Filter验证 SSO SessionId 通过，受限资源请求放行
6.5 注销流程剖析
用户与Client端应用请求注销Path时，将会 redirect 到 SSO Server 自动销毁全局 SSO SessionId，实现全局销毁
然后，访问接入SSO保护的任意Client端应用时，SSO Filter 均会拦截请求并 redirect 到 SSO Server 的统一登录界面
6.6 基于Cookie，相关概念
登录凭证存储：登录成功后，用户登录凭证被自动存储在浏览器Cookie中
Client端校验登录状态：通过校验请求Cookie中的是否包含用户登录凭证判断
系统角色模型：
SSO Server：认证中心，提供用户登录、注销以及登录状态校验等功能
Client应用：受SSO保护的Client端Web应用，为用户浏览器访问提供服务
用户：发起请求的用户，使用浏览器访问
6.7 基于Token，相关概念
登录凭证存储：登录成功后，获取到登录凭证（xxl_sso_sessionid=xxx），需要主动存储，如存储在 localStorage、Sqlite 中
Client端校验登录状态：通过校验请求 Header参数 中的是否包含用户登录凭证（xxl_sso_sessionid=xxx）判断；因此，发送请求时需要在 Header参数 中设置登陆凭证
系统角色模型：
SSO Server：认证中心，提供用户登录、注销以及登录状态校验等功能
Client应用：受SSO保护的Client端Web应用，为用户请求提供接口服务
用户：发起请求的用户，如使用Android、IOS、桌面客户端等请求访问
6.8 未登录状态请求处理
基于Cookie，未登录状态请求：
页面请求：redirect 到SSO Server登录界面
JSON请求：返回未登录的JSON格式响应数据
code：501 错误码
msg：sso not login.
数据格式：
基于Token，未登录状态请求：
返回未登录的JSON格式响应数据
code：501 错误码
msg：sso not login.
数据格式：
6.9 登录态自动延期
支持自定义登录态有效期窗口，默认24H，当登录态有效期窗口过半时，自动顺延一个周期。
6.10 记住密码
未记住密码时，关闭浏览器则登录态失效；记住密码时，登录态自动延期，在自定义延期时间的基础上，原则上可以无限延期。
6.11 路径排除
自定义路径排除Path，允许设置多个，且支持Ant表达式。用于排除SSO客户端不需要过滤的路径。
参考文章
单点登录原理与简单实现单点登录(SSO)看这一篇就够了