Spring Security：什么是 JWT？

这是我参与更文挑战的第 30 天，活动详情查看：更文挑战

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

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

JWT 的介绍

JWT，JSON Web Token，作为一个开放的标准，通过紧凑(compact，快速传输，体积小)或者自包含(self-contained，payload中将包含用户所需的所有的信息，避免了对数据库的多次查询)的方式，定义了用于在各方之间发送的安全JSON对象。

为什么要介绍 JWT，因为 JWT 可以很好的充当在访问令牌(access token)和刷新令牌(refresh token)的载体，这是Web双方之间进行安全传输信息的良好方式。当只有授权服务器持有签发和验证JWT的secret，那么就只有授权服务器能验证JWT的有效性以及发送带有签名的JWT，这就唯一保证了以JWT为载体的token的有效性和安全性。

JWT的组成

JWT格式一般如下：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0.IV4XZ0y0nMpmMX9orv0gqsEMOxXXNQOE680CKkkPQcs

它由三部分组成，每部分通过.分隔开，分别是：

Header 头部
Payload 有效负荷
Signature 签名

接着我们对每一部分进行详细的介绍。

Header

头部通常由两部分组成：

typ 类型，一般为jwt。
alg 加密算法，通常是HMAC SHA256或者RSA。

一个简单的头部例子如下：

{
	"alg": "HS256"
	"typ": "JWT"
}

然后这部分JSON会被Base64Url编码用于构成JWT的第一部分：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Playload

有效负载是JWT的第二部分，是用来携带有效信息的载体，主要是关于用户实体和附加元数据的声明，由以下三部分组成：

Registered claims 注册声明，这是一组预定的声明，但并不强制要求，提供了一套有用的、能共同使用的声明。主要有iss(JWT签发者)，exp(JWT过期时间)，sub(JWT面向的用户)，aud(接受JWT的一方)等。
Public claims 公开声明公开声明中可以添加任何信息，一般是用户信息或者业务扩展信息等。
Private claims 私有声明被JWT提供者和消费者共同定义的声明，既不属于注册声明也不属于公开声明。

一般不建议在payload中添加任何的敏感信息，因为Base64是对称解密的，这意味着payload中的信息的是可见的。

一个简单的有效负荷例子：

{
 	"name": "cang wu",
 	"exp": 1518051157,
 	"userId": "123456"
}

这部分JSON会被Base64Url编码用于构成JWT的第二部分：

eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0

Signature

要创建签名，必须需要被编码后的头部、被编码后的有效负荷、一个secret，最后通过在头部的定义的加密算法alg加密生成签名，生成签名的伪代码如下：


HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

用到的加密算法为HMACSHA256

secret是保存在服务端用于验证JWT以及签发JWT，所以必须只由服务端持有，不该流露出去。

一个简单的签名如下：

IV4XZ0y0nMpmMX9orv0gqsEMOxXXNQOE680CKkkPQcs

这将成为JWT的第三部分。

最后这三部分通过.分割，组成最终的JWT，如下所示：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1lIjoiY2FuZyB3dSIsImV4cCI6MTUxODA1MTE1NywidXNlcklkIjoiMTIzNDU2In0.IV4XZ0y0nMpmMX9orv0gqsEMOxXXNQOE680CKkkPQcs

小结

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