【spring security oauth2】JSON Web Token（JWT）作用

1. 背景

说起JWT，我们应该来谈一谈基于token的认证和传统的Session认证的区别。

1.1 传统的session认证

我们知道，http协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据http协议，我们并不能知道是哪个用户发送的请求，所以为了让我们的应用能识别是哪个用户发出的，我们只能在服务器存储一份用户登陆的信息，这份登陆信息会在响应时传递给服务器，告诉其保存为cookie，以便下次请求时发送给我们的应用，这样我们的英哟个就能识别请求来自哪个用户了，这就是传统的基于sessino认证

但是这种基于session的认证使应用本身很难得扩展，随着不用客户端的增加，独立的服务器已无法承载更多的用户，而这个时候基于session认证应用的问题就会暴露出来

1.2 基于session认证所显露的问题

Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大

扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性

CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。

1.3 基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或会话信息。这也就意味着机遇tokent认证机制的应用不需要去考虑用户在哪一台服务器登陆了，这就为应用的扩展提供了便利。

流程是这样的：

• 用户使用用户名密码请求服务器
• 服务器进行验证用户信息
• 服务器通过验证发送给用户一个token
• 客户端存储token，并在每次请求时附加这个token值
• 服务器验证token，并返回数据

综上所述，token是存在客户端的，解决了服务器端存储占用问题，也不用考虑分布式问题，但是普通的token是没有意义的字符串，通过jwt，定义了有意义的token，缺点是字符变多。

2. 什么是JWT

终于来到了著名的JWT部分了，JWT全称为Json Web Token，最近随着微服务架构的流行而越来越火，号称新一代的认证技术。今天我们就来看一下，jwt的本质到底是什么。

我们先来看一下OAuth2的token技术有没有什么痛点，相信从之前的介绍中你也发现了，token技术最大的问题是不携带用户信息，且资源服务器无法进行本地验证，每次对于资源的访问，资源服务器都需要向认证服务器发起请求，一是验证token的有效性，二是获取token对应的用户信息。如果有大量的此类请求，无疑处理效率是很低的，且认证服务器会变成一个中心节点，对于SLA和处理性能等均有很高的要求，这在分布式架构下是很要命的。

最基础的oauth2技术应用场景是拥有一个认证授权中心O，如果用户需要登录多个系统时，假设存在ＡＢＣ三个子系统，如果访问A时，从认证授权中心O获得一个token，然后访问B时，可以直接携带之前获得的token，这样确实省了一次输入用户名和密码，但是B无法判断这个token是否有效，B只好后台发起一次校验的请求，发送到O，这样一来，如果都要这么做的话，O作为一个中心节点压力会很大。造成这个问题的原因是因为token是一个无状态的字符串，什么是无状态？就是没有标识，类似身份证和姓名就是标识，那么当token是个无意义的随机字符串时，就是无状态的。

JWT就是在这样的背景下诞生的，从本质上来说，jwt就是一种特殊格式的token。普通的oauth2颁发的就是一串随机hash字符串，本身无意义，而jwt格式的token是有特定含义的，分为三部分：

• 头部Header
• 载荷Payload
• 签名Signature

这三部分均用base64进行编码，当中用.进行分隔，一个典型的jwt格式的token类似xxxxx.yyyyy.zzzzz。关于jwt格式的更多具体说明，不是本文讨论的重点，大家可以直接去官网查看官方文档，这里不过多赘述。

相信看到签名大家都很熟悉了，没错，jwt其实并不是什么高深莫测的技术，相反非常简单。认证服务器通过对称或非对称的加密方式利用payload生成signature，并在header中申明签名方式，仅此而已。通过这种本质上极其传统的方式，jwt可以实现分布式的token验证功能，即资源服务器通过事先维护好的对称或者非对称密钥（非对称的话就是认证服务器提供的公钥），直接在本地验证token，这种去中心化的验证机制无疑很对现在分布式架构的胃口。jwt相对于传统的token来说，解决以下两个痛点：

• 通过验证签名，token的验证可以直接在本地完成，不需要连接认证服务器
• 在payload中可以定义用户相关信息，这样就轻松实现了token和用户信息的绑定

在上面的那个资源服务器和认证服务器分离的例子中，如果认证服务器颁发的是jwt格式的token，那么资源服务器就可以直接自己验证token的有效性并绑定用户，这无疑大大提升了处理效率且减少了单点隐患。

当ABC都持有密钥的时候，通过自己解密token，根据结果就能判断是否是有效的token，就不用每次转发去O进行判断了

3. JWT适用场景与不适用场景

就像布鲁克斯在《人月神话》中所说的名言一样：“没有银弹”。JWT的使用上现在也有一种误区，认为传统的认证方式都应该被jwt取代。事实上，jwt也不能解决一切问题，它也有适用场景和不适用场景。
适用场景：

• 一次性的身份认证
• api的鉴权

这些场景能充分发挥jwt无状态以及分布式验证的优势

不适用的场景：

传统的基于session的用户会话保持

不要试图用jwt去代替session。这种模式下其实传统的session+cookie机制工作的更好：

• jwt因为其无状态和分布式，事实上只要在有效期内，是无法作废的，用户的签退更多是一个客户端的签退，服务端token仍然有效，你只要使用这个token，仍然可以登陆系统。
• 另外一个问题是续签问题，使用token，无疑令续签变得十分麻烦，当然你也可以通过redis去记录token状态，并在用户访问后更新这个状态，但这就是硬生生把jwt的无状态搞成有状态了，而这些在传统的session+cookie机制中都是不需要去考虑的。这种场景下，考虑高可用，我更加推荐采用分布式的session机制，现在已经有很多的成熟框架可供选择了（比如spring session）。

jwt适用于单点登录系统吗，如果是传统简单的独立业务，是不需要的

参考

深入理解Spring Cloud Security OAuth2及JWT