单点登录(SSO)与JWT

一、 背景知识

什么是SSO

单点登录（Single sign On）说就是：一次登录后可免登陆访问其他的可信平台。比如我们登录淘宝网后，再打开天猫首页可以发现已经是登录状态了。SSO 是一种比较流行的服务于企业业务整合的一种解决方案。SSO 这个概念已经出现很久很久了，目前各种平台都有非常成熟的实现，比如OpenSSO，OpenAM，Kerberos，CAS等

Authentication和Authorization的区别：

• Authentication：用户认证，指的是验证用户的身份，例如你希望以小A的身份登录，那么应用程序需要通过用户名和密码确认你真的是小A。
• Authorization：授权，指的是确认你的身份之后提供给你权限，例如用户小A可以修改数据，而用户小B只能阅读数据。

由于http协议是无状态的，每一次请求都无状态。当一个用户通过用户名和密码登录了之后，他的下一个请求不会携带任何状态，应用程序无法知道他的身份，那就必须重新认证。因此我们希望用户登录成功之后的每一次http请求，都能够保存他的登录状态。
目前主流的用户认证方法有基于token和基于session两种方式。

二、session与jwt的区别和优缺点；

基于session的用户认证

基于session的认证流程如下：

1. 用户输入其登录信息
2. 服务器验证信息是否正确，并创建一个session，然后将其存储在数据库中
3. 服务器为用户生成一个sessionId，将具有sesssionId的Cookie将放置在用户浏览器中
4. 在后续请求中，会根据数据库验证sessionID，如果有效，则接受请求
5. 一旦用户注销应用程序，会话将在客户端和服务器端都被销毁

改进：共享 cookie

基于 cookie-session 机制的系统中，登录系统后会返回一个 sessionId 存储在 cookie 中，如果我们能够让另外一个系统也能获取到这个 cookie，不就获取到凭证信息了，无需再次登录。刚好浏览器的 cookie 可以实现这样的效果。
cookie 允许同域名(或者父子域名)的不同端口中共享 cookie,这点和 http 的同域策略不一样（http 请求只要协议、域名、端口不完全相同便认为跨域）。因此只需将多个应用前台页面部署到相同的域名（或者父子域名），然后共享 session 便能够实现单点登录。

上面方案显而易见的限制就是不仅前台页面需要共享 cookie，后台也需要共享 session，可以用jwt来干掉 session

基于token（令牌）的用户认证

最常用的是JSON Web Token（jwt）：

1. 用户输入其登录信息
2. 服务器验证信息是否正确，并返回已签名的token
3. token储在客户端，例如存在local storage或cookie中
4. 之后的HTTP请求都将token添加到请求头里
5. 服务器解码JWT，并且如果令牌有效，则接受请求
6. 一旦用户注销，令牌将在客户端被销毁，不需要与服务器进行交互一个关键是，令牌是无状态的。后端服务器不需要保存令牌或当前session的记录。

基于回调实现

此架构中，业务系统 A 和业务系统 B 之间不需要有任何联系，他们都只和 SSO 认证平台打交道，因此可以任意部署，没有同域的限制。你可能就要问了这样要怎么共享身份凭证（也就是 jwt 字符串）？这里就要通过 url 参数来进行操作了。
文字总结来说是这样的：jwt 存到认证平台前端的 localStore(不一定是 localStore，cookie，sessionStore 都可以),然后业务平台携带自己的回调地址跳转到认证中心的前台，认证中心的前台再将 ujwt 作为 url 参数，跳回到那个回调地址上，这样就完成了 jwt 的共享。

文字很可能看不懂，下面是整个过程的路程图：

三、jwt的组成

jwt的认证原理：

一个jwt(JSON WEB TOKEN)实际上就是一个字符串，它由三部分组成，头部、载荷与签名，这三个部分都是json格式。
头部（Header）
头部用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的算法等。
{
“typ”: “JWT”,
“alg”: “HS256”
}
在这里，我们说明了这是一个JWT，并且我们所用的签名算法是HS256算法。
载荷（Payload）
载荷可以用来放一些不敏感的信息。
{
“iss”: “John Wu JWT”,
“iat”: 1441593502,
“exp”: 1441594722,
“aud”: “www.example.com”,
“sub”: “jrocket@example.com”,
“from_user”: “B”,
“target_user”: “A”
}
这里面的前五个字段都是由JWT的标准所定义的。
• iss: 该JWT的签发者
• sub: 该JWT所面向的用户
• aud: 接收该JWT的一方
• exp(expires): 什么时候过期，这里是一个Unix时间戳
• iat(issued at): 在什么时候签发的
把头部和载荷分别进行Base64编码之后得到两个字符串，然后再将这两个编码后的字符串用英文句号.连接在一起（头部在前），形成新的字符串：eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0

签名（signature）
最后，我们将上面拼接完的字符串用HS256算法进行加密。在加密的时候，我们还需要提供一个密钥（secret）。加密后的内容也是一个字符串，最后这个字符串就是签名，把这个签名拼接在刚才的字符串后面就能得到完整的jwt。header部分和payload部分如果被篡改，由于篡改者不知道密钥是什么，也无法生成新的signature部分，服务端也就无法通过，在jwt中，消息体是透明的，使用签名可以保证消息不被篡改。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJmcm9tX3VzZXIiOiJCIiwidGFyZ2V0X3VzZXIiOiJBIn0.rSWamyAYwuHCo7IFAgd1oRpSP7nzL7BF5t7ItqpKViM

四、JWT的使用

1.搭建环境

spring boot 框架先搭起来，由于是简易项目，除 spring boot web 基本依赖，只需要如下的额外依赖：

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.4</version>
</dependency>
<dependency>
<groupId>com.auth0</groupId>
<artifactId>java-jwt</artifactId>
<version>3.7.0</version>
</dependency>

2.后台实现

后台做的事情并不多，只有以下 5 个方法：

• /login : 登录成功后签发一个 jwt token
  在 demo 中只是简单对比用户名密码如果是一样的认为登录成功，返回 token
• /checkJwt : 检查 jwt 的有效性
  检查传来的 jwt-token 是否有效，返回失效的 jwt 列表
• /refreshjwt : 刷新 jwt
  判断该 jwt 是否快要过期，如果快要过期，生成一个新的 jwt 返回
• /inValid : 让某个 jwt 失效
  jwt 如何失效一直是一个比较麻烦的问题，各有利弊。本例中采用的是为每个 jwt 生成一个随机的秘钥 secret，将 jwt–secret 保存到 redis 中，想要让某个 jwt 失效，只需将该记录在 redis 中删除即可（这样在解密时便无法获取到 secret）。但是这样让无状态的认证机制变成有状态了（记录了 jwt 和 secret 的对应关系）。

总结来说 SSO 后台主要只做了两件事:验证用户名密码返回 jwt；验证 jwt 是否合法。具体代码查看 github 上 sso 目录下的代码。

3.前台实现

前台的逻辑较为复杂，不是那么容易理解，不明白的多看几遍上面的流程图。
再次回到 SSO 的重点：分享登录状态。要如何在前台将登录状态(在这里就是 jwt 字符串)分享出去呢？由于浏览器的限制，除了 cookie 外没有直接共享数据的办法。既然没有直接共享，那肯定是有间接的办法的！
这个办法就是回调。系统 A 的前台在跳转到 SSO 的前台时，将当前路径作为 url 参数传递给 sso 前台，sso 前台在获取到 jwt 后，再跳转到系统 A 传过来的 url 路径上，并带上 jwt 作为 url 参数。这就完成了 jwt 的一次共享，从 sso 共享到系统 A。
打个比方：你点了个外卖，别人要怎么把外卖给你呢？显然你会留下的地址，让别人带上饭送到这个地址，然后你就能享用美食了。这和 jwt 的传递非常相识了。
系统 A 说：我要 jwt，快把它送到http://localhost:8081/test1/这个地址上。
SSO 说：好嘞，这个地址是合法的可以送 jwt 过去，这就跳转过去：http://localhost:8081/test1/?jwt=abcdefj.asdf.asdfasf
系统 A 说：不错不错，真香。
要注意这里有个坑就是：如果另外一个恶意系统 C 安装相同的格式跳转到 SSO，想要获取 jwt，这显然是不应该给它的。所以在回跳回去的时候要判断一下这个回调地址是不是合法的，能不能给 jwt 给它，可以向后台请求判断也可以在 sso 前台直接写死合法的地址。在 demo 是没有这个判断过程的。

4.实现业务系统

业务系统代码非常简单，主要是用了一个拦截器，拦截 http 请求，提取出 token 向 sso 认证中心验证 token 是否有效，有效放行，否则返回错误给前端。

五、区别和优缺点

基于session和基于jwt的方式的主要区别就是用户的状态保存的位置，session是保存在服务端的，而jwt是保存在客户端的。

jwt的优点：

1. 可扩展性好
   应用程序分布式部署的情况下，session需要做多机数据共享，通常可以存在数据库或者redis里面。而jwt不需要。
2. 无状态
   jwt不在服务端存储任何状态。RESTful API的原则之一是无状态，发出请求时，总会返回带有参数的响应，不会产生附加影响。用户的认证状态引入这种附加影响，这破坏了这一原则。另外jwt的载荷中可以存储一些常用信息，用于交换信息，有效地使用 JWT，可以降低服务器查询数据库的次数。

jwt的缺点：

1. 安全性
   由于jwt的payload是使用base64编码的，并没有加密，因此jwt中不能存储敏感数据。而session的信息是存在服务端的，相对来说更安全。
2. 性能
   jwt太长。由于是无状态使用JWT，所有的数据都被放到JWT里，如果还要进行一些数据交换，那载荷会更大，经过编码之后导致jwt非常长，cookie的限制大小一般是4k，cookie很可能放不下，所以jwt一般放在local storage里面。并且用户在系统中的每一次http请求都会把jwt携带在Header里面，http请求的Header可能比Body还要大。而sessionId只是很短的一个字符串，因此使用jwt的http请求比使用session的开销大得多。
3. 一次性
   无状态是jwt的特点，但也导致了这个问题，jwt是一次性的。想修改里面的内容，就必须签发一个新的jwt。
   （1）无法废弃
   通过上面jwt的验证机制可以看出来，一旦签发一个jwt，在到期之前就会始终有效，无法中途废弃。例如你在payload中存储了一些信息，当信息需要更新时，则重新签发一个jwt，但是由于旧的jwt还没过期，拿着这个旧的jwt依旧可以登录，那登录后服务端从jwt中拿到的信息就是过时的。为了解决这个问题，我们就需要在服务端部署额外的逻辑，例如设置一个黑名单，一旦签发了新的jwt，那么旧的就加入黑名单（比如存到redis里面），避免被再次使用。
   （2）续签
   如果你使用jwt做会话管理，传统的cookie续签方案一般都是框架自带的，session有效期30分钟，30分钟内如果有访问，有效期被刷新至30分钟。一样的道理，要改变jwt的有效时间，就要签发新的jwt。最简单的一种方式是每次请求刷新jwt，即每个http请求都返回一个新的jwt。这个方法不仅暴力不优雅，而且每次请求都要做jwt的加密解密，会带来性能问题。另一种方法是在redis中单独为每个jwt设置过期时间，每次访问时刷新jwt的过期时间。

可以看出想要破解jwt一次性的特性，就需要在服务端存储jwt的状态。但是引入 redis 之后，就把无状态的jwt硬生生变成了有状态了，违背了jwt的初衷。而且这个方案和session都差不多了。

总结

适合使用jwt的场景：
• 有效期短
• 只希望被使用一次
比如，用户注册后发一封邮件让其激活账户，通常邮件中需要有一个链接，这个链接需要具备以下的特性：能够标识用户，该链接具有时效性（通常只允许几小时之内激活），不能被篡改以激活其他可能的账户，一次性的。这种场景就适合使用jwt。
而由于jwt具有一次性的特性。单点登录和会话管理非常不适合用jwt，如果在服务端部署额外的逻辑存储jwt的状态，那还不如使用session。基于session有很多成熟的框架可以开箱即用，但是用jwt还要自己实现逻辑。

参考

很久之前记录下的了，以后找到了再加上！