【项目杂记】JWT（上）：JWT 介绍及与 Session 对比

JWT 全称 JSON WEB TOKEN，所以它本质上也是个 token。JWT 由 Header、Payload、Signature 三部分组成，结构上类似 JSON 对象，最后经 base64 编码后生成 xxx.yyyyy.zzzz 形式的 token 字符串。

1）Header：描述了 token 的基本信息，比如 token 类型与签名用的算法

header = '{"typ":"JWT", "alg":"HS256"}'  # HS256 表示使用 HMAC-SHA256 生成签名

2）Payload：载荷，它包含声明（要求）。声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型: registered, public 和 private。

• Registered claims : 这里有一组预定义的声明，它们不是强制的，但是推荐。比如：

  iss: 该JWT的签发者 
  sub: 该JWT所面向的用户 
  aud: 接收该JWT的一方 
  exp(expires): 什么时候过期，这里是一个Unix时间戳 
  iat(issued at): 在什么时候签发的
  

• Public claims : 公共的声明可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息，但不建议添加敏感信息，因为该部分在客户端可解密。

• Private claims : 私有声明是提供者和消费者所共同定义的声明，用于在同意使用它们的各方之间共享信息，并且不是注册的或公开的声明。一般不建议存放敏感信息，因为base64是对称解密的，意味着该部分信息可以归类为明文信息。

{
    "iat":1422779638,
    "name": 'zhangsan'
}

3）Signature：签名，用于接收方校验消息在传递过程中是否被篡改、伪造。关于签名算法：

• 哈希算法：MD5、SHA-1、SHA-256、HMAC-SHA256 等
  • 特点：属于哈希算法，计算数字摘要，不可逆，有碰撞
  • 生成签名：MD5 签名通常先按照一定规则排列待签名数据，进行加盐（拼key），然后使用 MD5 摘要算法计算摘要，得到的散列值即为 sign
  • MD5 验签即按照相同的规则排列待签名数据，使用相同的 key，然后使用 MD5 摘要算法计算摘要，对比自己得到的 sign 值和对方传过来的 sign 值是否相等
• 加密算法：RSA、DSA、ECDS 等
  • 特点：属于加密算法，对数据进行加解密，可逆
  • 生成签名：使用 MD5、SHA-256 等算法计算待签名字符串的「数字摘要」，使用私钥加密，生成「加密数字摘要」
  • 验证签名：对「加密数字摘要」通过公钥进行解密，生成「数字摘要2」，比较「数字摘要」与「数字摘要2」，结果相同则签名验证通过

注：加密和签名是两回事，加密的目的是防止信息泄露，签名的目的是防止篡改和伪造。Token 本身并没有任何加密机制，它依赖于 HTTPS 的通道保密能力。不过应该可以自己为Token增加加密机制，这就带来了额外的开销。

下面来看官网的一张图：

JWT 与 Session 对比

Session 是将用户信息、授权列表等都存在服务器，然后将 sessionId（或者摘要）通过 cookie 发送给客户端。这个 id 很短，相比 jwt 更节省网络开支，服务器每次收到 id 也很容易拿到数据。

Jwt 也是通过 cookie 发送给客户端，只不过 Jwt 传递的数据更长（因为数据里包含了用户 id、签名等）；待服务端收到用户请求时再尝试解密，如果解密成功代表没有被篡改，并读取内容。

=> Session 是空间换时间；Token 是时间换空间。两者各有千秋，并不是谁就有什么巨大优势。

关于 JWT 如何进行鉴权请参考：

• 【项目杂记】JWT（中）：项目中使用 JWT 时用到的工具类
• 【项目杂记】JWT（下）：使用 JWT 鉴权整体逻辑实例