单点登录的四种实现方式

在做单点登录功能的时候，在网络上搜索了很多文章，大部分都是站在后端如何处理session共享、有无状态登录的角度攥写的，并没有综合前端如何处理多个子系统之间传输token的角度来说明，故此整合了这样一篇笔记，从多个角度尽量全面地来说明单点登录的几种实方式。

引入

众所周知，HTTP是无状态的协议，这意味着服务器无法确认用户的信息。于是乎，W3C就提出了：给每一个用户都发一个通行证，无论谁访问的时候都需要携带通行证，这样服务器就可以从通行证上确认用户的信息。通行证就是Cookie。

如果说Cookie是检查用户身上的”通行证“来确认用户的身份，那么Session就是通过检查服务器上的”客户明细表“来确认用户的身份的。Session相当于在服务器中建立了一份“客户明细表”。

HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一个用户。于是乎：服务器向用户浏览器发送了一个名为SESSIONID的Cookie，它的值是Session的id值。其实Session是依据Cookie来识别是否是同一个用户。

所以，一般我们单系统实现登录会这样做：

登录：将用户信息保存在Session对象中
如果在Session对象中能查到，说明已经登录
如果在Session对象中查不到，说明没登录（或者已经退出了登录）
注销（退出登录）：从Session中删除用户的信息
记住我（关闭掉浏览器后，重新打开浏览器还能保持登录状态）：配合Cookie来用

单系统登录功能主要是用Session保存用户信息来实现的，但我们清楚的是：多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。

解决系统之间Session不共享问题有一下几种方案：

Tomcat集群Session全局复制（集群内每个tomcat的session完全同步）【会影响集群的性能呢，不建议】
根据请求的IP进行Hash映射到对应的机器上（这就相当于请求的IP一直会访问同一个服务器）【如果服务器宕机了，会丢失了一大部分Session的数据，不建议】
把Session数据放在Redis中（使用Redis模拟Session）【建议】

我们可以将登录功能单独抽取出来，做成一个子系统。

SSO系统生成一个token，并将用户信息存到Redis中，并设置过期时间
其他系统请求SSO系统进行登录，得到SSO返回的token，写到Cookie中
每次请求时，Cookie都会带上，拦截器得到token，判断是否已经登录

到这里，其实我们会发现其实就两个变化：

将登陆功能抽取为一个系统（SSO），其他系统请求SSO进行登录
本来将用户信息存到Session，现在将用户信息存到Redis

上面我们解决了Session不能共享的问题，但其实还有另一个问题。Cookie是不能跨域的

比如说，我们请求<https://www.google.com/>时，浏览器会自动把google.com的Cookie带过去给google的服务器，而不会把<https://www.baidu.com/>的Cookie带过去给google的服务器。

这就意味着，由于域名不同，用户向系统A登录后，系统A返回给浏览器的Cookie，用户再请求系统B的时候不会将系统A的Cookie带过去。

针对Cookie存在跨域问题，有几种解决方案：

服务端将Cookie写到客户端后，客户端对Cookie进行解析，将Token解析出来，此后请求都把这个Token带上就行了
多个域名共享Cookie，在写到客户端的时候设置Cookie的domain。
将Token保存在SessionStroage中（不依赖Cookie就没有跨域的问题了）

到这里，我们已经可以实现单点登录了。

到目前为止，我们在单点登录的过程中遇到了这样几个问题：

1、session共享问题（有状态登录）

2、cookie跨域问题（解决token存储问题）

其中第一个问题除了上面提到的几种方案之外，还可以通过做无状态登录来解决。

接下来从这些方面来介绍目前存在的一些方案。

共享Session

共享Session可谓是实现单点登录最直接、最简单的方式。将用户认证信息保存于Session中，即以Session内存储的值为用户凭证，这在单个站点内使用是很正常也很容易实现的，而在用户验证、用户信息管理与业务应用分离的场景下即会遇到单点登录的问题，在应用体系简单，子系统很少的情况下，可以考虑采用Session共享的方法来处理这个问题。

这个架构可以使用基于Redis的Session共享方案。将Session存储于Redis上，然后将整个系统的全局Cookie Domain设置于顶级域名上，这样SessionID就能在各个子系统间共享。分布式Session共享解决方案，这篇推荐大家看下。

这个方案存在着严重的扩展性问题，首先，http://ASP.NET的Session存储必须为SessionStateItemCollection对象，而存储的结构是经过序列化后经过加密存储的。

并且当用户访问应用时，他首先做的就是将存储容器里的所有内容全部取出，并且反序列化为SessionStateItemCollection对象。

这就决定了他具有以下约束：

1.Session中所涉及的类型必须是子系统中共同拥有的（即程序集、类型都需要一致），这导致Session的使用受到诸多限制；

2.跨顶级域名的情况完全无法处理；

基于OpenId的单点登录

这种单点登录将用户的身份标识信息简化为OpenId存放于客户端，当用户登录某个子系统时，将OpenId传送到服务端，服务端根据OpenId构造用户验证信息，多用于C/S与B/S相结合的系统，属于有状态登录，流程如下：

由上图可以看到，这套单点登录依赖于OpenId的传递，其验证的基础在于OpenId的存储以及发送。

1.当用户第一次登录时，将用户名密码发送给验证服务；

2.验证服务将用户标识OpenId返回到客户端；

3.客户端进行存储；

4.访问子系统时，将OpenId发送到子系统；

5.子系统将OpenId转发到验证服务；

6.验证服务将用户认证信息返回给子系统；

7.子系统构建用户验证信息后将授权后的内容返回给客户端。

这套单点登录验证机制的主要问题在于他基于C/S架构下将用户的OpenId存储于客户端，在子系统之间发送OpenId，而B/S模式下要做到这一点就显得较为困难。为了处理这个问题我们将引出下一种方式，这种方式将解决B/S模式下的OpenId的存储、传递问题。

基于Cookie的OpenId存储方案

我们知道，Cookie的作用在于充当一个信息载体在Server端和Browser端进行信息传递，而Cookie一般是以域名为分割的，例如http://a.xxx.com与http://b.xxx.com的Cookie是不能互相访问的，但是子域名是可以访问上级域名的Cookie的。即http://a.xxx.com和http://b.xxx.com是可以访问http://xxx.com下的Cookie的，于是就能将顶级域名的Cookie作为OpenId的载体。

验证步骤和上第二个方法非常相似：

1、在提供验证服务的站点里登录；

2、将OpenId写入顶级域名Cookie里；

3、访问子系统（Cookie里带有OpenId）

4、子系统取出OpenId通过并向验证服务发送OpenId

5、返回用户认证信息

6、返回授权后的内容

在以上两种方法中我们都可以看到通过OpenId解耦了Session共享方案中的类型等问题，并且构造用户验证信息将更灵活，子系统间的验证是相互独立的，但是在第三种方案里，我们基于所有子系统都是同一个顶级域名的假设，而在实际生产环境里有多个域名是很正常的事情，那么就不得不考虑跨域问题究竟如何解决。

基于jwt的无状态单点登录方案

登录状态

无状态登录

微服务集群中的每个服务，对外提供的都是Rest风格的接口。而Rest风格的一个最重要的规范就是：服务的无状态性，即：

服务端不保存任何客户端请求者信息
客户端的每次请求必须具备自描述信息，通过这些信息识别客户端身份

带来的好处是什么呢？

客户端请求不依赖服务端的信息，任何多次请求不需要必须访问到同一台服务
服务端的集群和状态对客户端透明
服务端可以任意的迁移和伸缩
减小服务端存储压力

无状态登录流程

无状态登录的流程：

当客户端第一次请求服务时，服务端对用户进行信息认证（登录）
认证通过，将用户信息进行加密形成token，返回给客户端，作为登录凭证
以后每次请求，客户端都携带认证的token
服务的对token进行解密，判断是否有效。

jwt实现无状态登录

JWT，全称是Json Web Token，是JSON风格轻量级的授权和身份认证规范，可实现无状态、分布式的Web应用授权；

数据格式

JWT包含三部分数据：

Header：头部，通常头部有两部分信息：
- token类型：JWT
- 加密方式：base64（HS256）
Payload：载荷，就是有效数据，一般包含下面信息：

用户身份信息（注意，这里因为采用base64编码，可解码，因此不要存放敏感信息）

注册声明：如token的签发时间，过期时间，签发人等
这部分也会采用base64编码，得到第二部分数据
Signature：签名，是整个数据的认证信息。根据前两步的数据，再加上指定的密钥（secret）（不要泄漏，最好周期性更换），通指定的算法编码生成。首先，需要指定一个密码（secret）。该密码仅仅保存在服务器中，并且不能向用户公开。然后，使用标头中所指定的签名算法（默认为HS256）根据以下公式生成签名。

1	HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(claims), secret)

JWT交互流程

用户登录
服务的认证，通过后根据secret生成token
将生成的token返回给浏览器，客户端在接收到服务器返回的JWT，就将其保存在Cookie或者localStoreage中，此后，客户端的每次请求都到带上Jwt。如果将它存储在cookie中，就可以自动发送，但是不会解决跨域，因此一般是将它放入到HTTP请求的Header Authorization字段中。当跨域时，也可以将JWT被放置于POST请求的数据主体中。
用户每次请求携带token
服务端利用公钥解读jwt签名，判断签名有效后，从Payload中获取用户信息
处理请求，返回响应结果

因为JWT签发的token中已经包含了用户的身份信息，并且每次请求都会携带，这样服务的就无需保存用户信息，甚至无需去数据库查询，完全符合了Rest的无状态规范。

非对称加密

加密技术是对信息进行编码和解码的技术，编码是把原来可读信息（又称明文）译成代码形式（又称密文），其逆过程就是解码（解密），加密技术的要点是加密算法，加密算法可以分为三类：

对称加密，如AES
- 基本原理：将明文分成N个组，然后使用密钥对各个组进行加密，形成各自的密文，最后把所有的分组密文进行合并，形成最终的密文。
- 优势：算法公开、计算量小、加密速度快、加密效率高
- 缺陷：双方都使用同样密钥，安全性得不到保证
非对称加密，如RSA
- 基本原理：同时生成两把密钥：私钥和公钥，私钥隐秘保存，公钥可以下发给信任客户端
  - 私钥加密，持有公钥才可以解密
  - 公钥加密，持有私钥才可解密
- 优点：安全，难以破解
- 缺点：算法比较耗时
不可逆加密，如MD5，SHA
- 基本原理：加密过程中不需要使用密钥，输入明文后由系统直接经过加密算法处理成密文，这种加密后的数据是无法被解密的，无法根据密文推算出明文。

存在的问题

JWT不仅可用于认证，还可用于信息交换。善用JWT有助于减少服务器请求数据库的次数。
生产的token可以包含基本信息，比如id、用户昵称、头像等信息，避免再次查库
存储在客户端，不占用服务端的内存资源
JWT默认不加密，但可以加密。生成原始令牌后，可以再次对其进行加密。
当JWT未加密时，一些私密数据无法通过JWT传输。
JWT的最大缺点是服务器不保存会话状态，所以在使用期间不可能取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
JWT本身包含认证信息，token是经过base64编码，所以可以解码，因此token加密前的对象不应该包含敏感信息，一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输

CAS（Central Authentication Service）思想

CAS（Central Authentication Service）是一个开源的认证系统，它主要用于为Web应用程序创建和维护单点登录会话。它提供了一个安全可靠的方式来验证用户的身份，并且可以集成到各种Web应用程序中。
在单点登录（SSO）环境中，CAS扮演着非常重要的角色。它充当了一个中心认证服务器，负责验证用户的身份，并生成会话令牌，该令牌可以由其他应用程序用于验证用户的身份。这样，用户只需要在一个应用程序中登录，就可以在其他应用程序中无缝地访问，而无需再次输入用户名和密码。
CAS还提供了多种认证机制，包括基于令牌的认证、基于密码的认证和多因素认证等。此外，它还支持多种协议，如CAS、OAuth、SAML等，这使得它可以与各种不同的Web应用程序集成。

如果已经将登录单独抽取成系统出来，我们还能这样玩。现在我们有两个系统，分别是www.java3y.com和www.java4y.com，一个SSOwww.sso.com

首先，用户想要访问系统Awww.java3y.com受限的资源(比如说购物车功能，购物车功能需要登录后才能访问)，系统Awww.java3y.com发现用户并没有登录，于是重定向到sso认证中心，并将自己的地址作为参数。请求的地址如下：

www.sso.com?service=www.java3y.com

sso认证中心发现用户未登录，将用户引导至登录页面，用户进行输入用户名和密码进行登录，用户与认证中心建立全局会话（生成一份Token，写到Cookie中，保存在浏览器上）

全局会话是若干客户端通过浏览器和单一认证中心之间建立并保持的会话，当某一客户端重定向访问认证中心进行首次登录操作时，浏览器地址栏会由客户端的域名变为认证中心的域名，相当于浏览器发起了一次访问认证中心的请求并建立起全局会话，此时全局会话的JSESSIONID会自动地被浏览器保存在认证中心域名下的cookie中。后续其它客户端再在此台浏览器重定向访问认证中心时，由于浏览器地址栏请求的域名都是认证中心的域名，浏览器会自动带上该域名的cookie访问认证中心，由于cookie中jsessionid相同的，所以是一个会话，称为全局会话，实现了session共享。