单点登录（英语：Single sign-on，缩写为 SSO），顾名思义，只需要登录一次就能访问多个系统。相同的，单一注销（single sign-off）就是指，只需要注销一次，就可以结束对多个系统的访问权限。下面，就一起来研究一下单点登录的适用场景以及背后的实现原理。
单系统登录
http 无状态协议
web 应用采用 browser/server 架构，http 作为通信协议。http 是无状态协议，浏览器的每一次请求，服务器会独立处理，不与之前或之后的请求产生关联，这个过程如下图所示，三次请求/响应对之间没有任何联系。
但这也同时意味着，任何用户都能通过浏览器访问服务器上的资源，如果想保护服务器的某些资源，必须限制浏览器请求；要限制浏览器请求，必须鉴别浏览器请求(响应合法请求，忽略非法请求)；要鉴别浏览器请求，必须清楚浏览器请求状态。既然 http 协议无状态，那就让服务器和浏览器共同维护一个状态吧！这就是会话机制。
会话机制
当浏览器第一次请求服务器时，服务器创建一个会话，并将会话的 id 作为响应的一部分发送给浏览器，浏览器存储会话 id，并在后续第二次和第三次请求中带上会话 id，服务器根据请求中的会话 id 就知道是不是同一个用户了(注:浏览器第一次请求时服务器还没有创建会话)，这个过程用下图说明，后续请求与第一次请求产生了关联。
服务器在内存中保存会话对象，浏览器怎么保存会话 id 呢？你可能会想到两种方式:
- 拼接在 url 中
- cookie
将会话 id 作为每一个请求的参数，服务器接收请求自然能解析参数获得会话 id，并借此判断是否来自同一会话，很明显，这种方式比较低级。那就换浏览器自己来维护这个会话 id 吧，每次发送 http 请求时浏览器自动发送会话 id，cookie 机制正好用来做这件事。cookie 是浏览器用来存储少量数据的一种机制，数据以 key/value 形式存储，浏览器发送 http 请求时自动附带 cookie 信息。tomcat 会话机制当然也实现了 cookie ，访问 tomcat 服务器时，浏览器中可以看到一个名为 JSESSIONID 的 cookie，这就是 tomcat 会话机制维护的会话id，使用了 cookie 的请求响应过程如下图。
登录状态
有了会话机制，登录状态就好明白了，我们假设浏览器第一次请求服务器需要输入用户名与密码验证身份，服务器拿到用户名密码去数据库比对，正确的话说明当前持有这个会话的用户是合法用户，应该将这个会话标记为“已授权”或者“已登录”等等之类的状态，既然是会话的状态，自然要保存在会话对象中，tomcat 在会话对象中设置登录状态如下。
**
HttpSession session = request.getSession;
session.setAttribute(“isLogin”, true);
**
用户再次访问时，tomcat 在会话对象中查看登录状态。
**
HttpSession session = request.getSession;
session.getAttribute(“isLogin”);
**
实现了登录状态的浏览器请求服务器模型如下图所示。
每次请求受保护资源时都会检查会话对象中的登录状态，只有 isLogin=true 的会话才能访问，登录机制因此而实现。
多系统的复杂性
web 系统早已从久远的单系统发展成为如今由多系统组成的应用群，面对如此众多的系统，用户难道要一个一个登录、然后一个一个注销吗？就像下图描述的这样。
web 系统由单系统发展成多系统组成的应用群，复杂性应该由系统内部承担，而不是用户。无论 web 系统内部多么复杂，对用户而言，都是一个统一的整体，也就是说，用户访问 web 系统的整个应用群与访问单个系统一样，登录/注销只要一次就够了。
虽然单系统的登录解决方案很完美，但对于多系统应用群已经不再适用了，为什么呢？
单系统登录解决方案的核心是 cookie，cookie 携带会话 id 在浏览器与服务器之间维护会话状态。但 cookie 是有限制的，这个限制就是 cookie 的域（通常对应网站的域名），浏览器发送 http 请求时会自动携带与该域匹配的 cookie，而不是所有 cookie（否则会存在 CSRF 问题）。
既然这样，为什么不将 web 应用群中所有子系统的域名统一在一个顶级域名下，例如 “*.baidu.com”，然后将它们的 cookie 域设置为 “baidu.com”，这种做法理论上是可以的，甚至早期很多多系统登录就采用这种同域名共享 cookie 的方式。然而，可行并不代表好，共享 cookie 的方式存在众多局限。首先，应用群域名得统一；其次，应用群各系统使用的技术（至少是 web 服务器）要相同，不然 cookie 的 key 值（tomcat 为 JSESSIONID）不同，无法维持会话，共享 cookie 的方式是无法实现跨语言技术平台登录的，比如 java、php、.net 系统之间就无法使用同一个 cookie。
因此，我们需要一种全新的登录方式来实现多系统应用群的登录，这就是单点登录。
单点登录
什么是单点登录？单点登录全称 Single Sign On（以下简称SSO），是指在多系统应用群中登录一个系统，便可在其他所有系统中得到授权而无需再次登录。
登录
相比于单系统登录，sso 需要一个独立的认证中心，只有认证中心能接受用户的用户名密码等安全信息，其他系统不提供登录入口，只接受认证中心的间接授权。间接授权通过令牌实现，先由子系统产生临时令牌，然后 sso 认证中心验证用户的用户名密码没问题，最后 sso 认证中心再通知各子系统令牌生效。之后浏览器端可以利用之前就返回的令牌进行受限资源的访问。
下面对上图简要描述
用户访问 nrb 的受限资源，nrb 发现用户未登录，nrb 生成一个 tokenA，并将 tokenA 返回给用户，然后跳转至 sso 认证中心
sso 认证中心发现用户未登录，将用户引导至登录页面
用户输入用户名密码提交登录申请
sso 认证中心校验用户信息，创建用户与 sso 认证中心之间的会话，并关联 sessionId 和 userId
sso 认证中心通知 nrb 绑定 tokenA 和 userId 并进行保存
sso 认证中心跳转回用户访问的nrb系统
用户利用之前就已经返回的 tokenA 来访问 nrb 的受限资源
用户访问 hades 的受限资源，hades 发现用户未登录，hades 生成一个 tokenB，tokenB 返回给用户，然后跳转至 sso 认证中心
sso 认证中心发现用户已登录
sso 认证中心通知 hades 绑定 tokenB 和 userId 并进行保存
sso 认证中心跳转回用户访问的hades系统
用户利用之前就已经返回的 tokenB 来访问 hades 的受限资源
注销
单点登录自然也要单点注销，在一个子系统中注销，所有子系统的会话都将被销毁，用下面的图来说明。
sso 认证中心一直监听会话的状态，一旦会话销毁，监听器将通知所有管理系统执行注销操作。
- 用户向 hades 系统发起注销请求
- hades 系统向 sso 认证中心发起注销请求，并将用户的 tokenA 和存储在 cookie 中的 sessionId 当做参数传递
- sso 认证中心取出与 sessionId 关联的系统地址和 token
- sso 认证中心向所有关联系统发起注销请求，并指定需要注销的 token
- 各关联系统接收 sso 认证中心的注销请求，销毁指定 token
- sso 认证中心引导用户至登录页面
部署图
单点登录涉及 sso 认证中心与众子系统，子系统与 sso 认证中心需要通信以发送令牌、保存令牌及发起注销请求，因而子系统必须集成 sso 的客户端，sso 认证中心则是 sso 服务端，整个单点登录过程实质是 sso 客户端与服务端通信的过程，用下图描述。
sso 认证中心与 sso 客户端通信方式有多种，这里以简单好用的 httpClient 为例，web service、rpc、restful api 都可以。
实现
简要介绍下基于 java 的实现过程，sso 采用客户端/服务端架构，我们先看 sso-client 与 sso-server 要实现的功能（下面：sso 认证中心= sso-server）。
sso-client
- 拦截子系统未登录用户的请求，生成 token，并将 token、本地 cookie 值和子系统自身地址作为跳转 sso 认证中心的参数进行传递
- 接收 sso 认证中心通知的 token、userId 并进行保存
- 通过 token 与用户建立会话
- 拦截用户注销请求，向 sso 认证中心发送注销请求
- 接收 sso 认证中心发出的注销请求，注销指定 token
sso-server
- 验证用户的账户信息
- 创建 session
- 将 sessionId 与子系统地址及相应的 token，userId 进行关联
- 与 sso-client 通信发送 token、userId
- 校验 session 有效性
- 接受 sso-client 注销请求，注销所有子系统中的 token