一、什么是 JWT
Json web token，是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519)。
JWT 是流行的跨域身份验证解决方案。
该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密。
二、传统的 session 认证
跨域身份验证
- 用户向服务器发送用户名和密码。
- 验证服务器后，相关数据（如用户角色、登录时间等）将保存在当前会话中。
- 服务器向用户返回 session_id，session 信息都会写入到用户的 Cookie。
- 用户的每个后续请求都将通过 在Cookie 中取出 session_id 传给服务器。
- 服务器收到 session_id 并对比之前保存的数据，确认用户的身份。
http 协议本身是一种无状态的协议，而这就意味着如果用户向我们的应用提供了用户名和密码来进行用户认证，那么下一次请求时，用户还要再一次进行用户认证才行，因为根据 http 协议，我们并不能知道是哪个用户发出的请求，所以为了让我们的应用能识别是哪个用户发出的请求，我们只能在服务器存储一份用户登录的信息，这份登录信息会在响应时传递给浏览器，告诉其保存为 cookie，以便下次请求时发送给我们的应用，这样我们的应用就能识别请求来自哪个用户了，这就是传统的基于 session 认证。
但是这种基于 session 的认证使应用本身很难得到扩展，随着不同客户端用户的增加，独立的服务器已无法承载更多的用户，而这时候基于 session 认证应用的问题就会暴露出来.
2.1 基于 session 认证所显露的问题
Session
每个用户经过我们的应用认证之后，应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言 session 都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性
用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。
CSRF
因为是基于 cookie 来进行用户识别的, cookie 如果被截获，用户就会很容易受到跨站请求伪造的攻击。
三、基于 token 的鉴权机制
基于 token 的鉴权机制类似于 http 协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于 token 认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。
流程上是这样的：
- 用户使用用户名密码来请求服务器
- 服务器进行验证用户的信息
- 服务器通过验证发送给用户一个 token
- 客户端存储 token，并在每次请求时附送上这个 token 值
- 服务端验证 token 值，并返回数据
这个 token 必须要在每次请求时传递给服务端，它应该保存在请求头里。另外，服务端要支持 CORS（跨来源资源共享）策略，一般我们在服务端这么做就可以了 Access-Control-Allow-Origin: *。
四、JWT
4.1 JWT 内容
JWT是由三段信息构成的，将这三段信息文本用 . 链接一起就构成了 Jwt 字符串：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
4.2 JWT 的构成
- 第一部分为头部（header）
- 第二部分为载荷（payload）
- 第三部分为签证（signature)
4.2.1 header
jwt 的头部承载两部分信息：
- typ 声明令牌的类型
- alg 声明签名的算法。通常直接使用 HMAC SHA256（写为 HS256）
完整的头部就像下面这样的 JSON：
{
'typ': 'JWT',
'alg': 'HS256'
}
然后使用 Base64 URL 算法将上述 JSON 对象转换为字符串保存，构成了第一部分。
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
4.2.2 payload
有效载荷是JWT的主体内容部分，也是一个 JSON 对象，包含需要传递的数据。这些有效信息包含三个部分：
- 标准中注册的声明
- 公共的声明
- 私有的声明
标准中注册的声明（建议但不强制使用）：
| 字段名 | 说明 |
|---|---|
| iss | jwt签发者 |
| sub | jwt所面向的用户 |
| aud | 接收jwt的一方 |
| exp | jwt的过期时间，这个过期时间必须要大于签发时间 |
| nbf | 定义在什么时间之前，该jwt都是不可用的 |
| iat | jwt的签发时间 |
| jti | jwt的唯一身份标识，主要用来作为一次性 token，从而回避重放攻击。 |
公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息，但不建议添加敏感信息，因为该部分在客户端可解密。
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为 base64 编码有对应的解码，意味着该部分信息可以归类为明文信息。
定义一个 payload：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后将其进行 base64 编码，得到 Jwt 的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
4.2.3 signature
jwt 的第三部分是签名哈希部分，是对上面两部分数据签名，通过指定的算法生成哈希，以确保数据不会被篡改。由三部分组成：
- header（base64 后的）
- payload（base64 后的）
- secret（密码，仅存在服务器）
这个部分需要 base64 编码后的 header 和 base64 编码后的payload 使用 . 连接组成的字符串，然后通过 header 中声明的签名方式进行加盐 secret 组合生成摘要，然后就构成了 jwt 的第三部分。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret)
// TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
将这三部分用 . 连接成一个完整的字符串，构成了最终的jwt：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
secret 是保存在服务器端的，jwt 的签发生成也是在服务器端的，secret 就是用来进行 jwt 的签发和 jwt 的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个 secret, 那就意味着客户端是可以自我签发 jwt 了。
4.3 Base64URL 算法
JWT 头和有效载荷序列化的算法都用到了 Base64URL。该算法和常见 Base64 算法类似，稍有差别。
作为令牌的 JWT 可以放在 URL 中（例如 api.example/?token=xxx）。 Base64 中用的三个字符是 +，/ 和 =，由于在 URL 中有特殊含义，因此 Base64URL 中对他们做了替换：去掉 =，- 替换 +，_ 替换 /。
五、应用
一般是在请求头里加入 Authorization，并加上 Bearer 标注：
fetch('api/user/1', {
headers: {
'Authorization': 'Bearer ' + token
}
})
服务端会验证 token，如果验证通过就会返回相应的资源。整个流程：
生成 token 代码
import io.jsonwebtoken.Claims;
import io.jsonwebtoken.JwtBuilder;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
public class JWTUtil {
public static String creatCompact(JSONObject jsonObject, long TTLMillis) {
SignatureAlgorithm signatureAlgorithm = SignatureAlgorithm.HS256;
long nowMillis = System.currentTimeMillis();
Date now = new Date(nowMillis);
// 生成签名密钥
byte[] apiKeySecretBytes = DatatypeConverter.parseBase64Binary(DigestUtil.encodeBase64(SECRET));
Key signingKey = new SecretKeySpec(apiKeySecretBytes, signatureAlgorithm.getJcaName());
// 添加构成 JWT 的参数
JwtBuilder builder = Jwts.builder().setHeaderParam("typ", "JWT")
.setIssuedAt(now) // 创建时间
.setIssuer(issuer) // 发送谁
.setAudience(audience) // 个人签名
.setSubject(jsonObject.toString()) // 主题，也差不多是个人的一些信息
.signWith(signatureAlgorithm, signingKey); // 估计是第三段密钥
// 添加 Token 过期时间
if (TTLMillis >= 0) {
// 过期时间
long expMillis = nowMillis + TTLMillis
Date expDate = new Date(expMillis);
// 系统时间之前的 token 都是不可以被承认的
builder.setExpiration(expDate).setNotBefore(now);
}
// 生成 jwt token
return builder.compact();
}
}
六、总结
优点
- 因为 json 的通用性，所以 JWT 是可以进行跨语言支持的，像 JAVA、JavaScript、NodeJS、PHP等很多都可以使用。
- 因为有了 payload 部分，所以 JWT 可以在自身存储一些其他业务逻辑所必要的非敏感信息。
- 便于传输，jwt 的构成非常简单，字节占用很小，所以它是非常便于传输的。
- 它不需要在服务端保存会话信息, 所以它易于应用的扩展
安全相关
使用 base64 把 JSON 编码，其实只不过是先扁平化再用 64 个可读无冲突字符来表达，毫无加密效果。SHA256 的摘要只是为 JSON 数据生成一个“指纹”，防止被篡改，属于完整性范畴，也无任何加密效果，摘要不等于签名，签名是用私钥加密摘要。所以 Token 本身并没有任何加密机制，它依赖于 HTTPS 的通道保密能力。可以自己为 Token 增加加密机制，这就带来了额外的开销。
jwt 只是缓解了 session 对于服务器的压力，安全性也只是相对加强了点。
jwt 不仅可用于认证，还可用于信息交换。善用 jwt 有助于减少服务器请求数据库的次数。
- 不应该在 jwt 的 payload 部分存放敏感信息，因为该部分是客户端可解密的部分。生成原始令牌后，可以使用该令牌再次对其进行加密。
- 保护好 secret 私钥，该私钥非常重要。
- 协议不保证安全性的。oauth2 也没有保证安全性，安全性需要自己去做，token 设成有时效性的，这样有一定的安全性；或者加一个 ip 干扰因子。
- 为了减少盗用和窃取，不建议使用 HTTP 协议来传输代码，而是使用加密的 HTTPS 协议进行传输
七、内容来源
Dearmadman - 什么是 JWT -- JSON WEB TOKEN
官网
10分钟了解JSON Web令牌（JWT）