JWT 简介、陷阱及建议

HEADER 部分是 JSON 格式的数据，经过 base64url 编码后所得。HEADER 通常包含 typ和 alg，大多数时候也会包含 kid。详细内容参考 JWS 和 JWE 。这里只介绍最常用的字段和值。

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "abcdef1234567890"
}

(1) typ

表示内容类型。既然是JWT，就一直填写 "JWT" 值就可以了。注意大写。大写不是 标准 要求的，但是有些JWT实现只认大写。

(2) alg

表示签名字段(第三个部分)使用何种签名算法，具体dinginess在 JWA。

+--------------+-------------------------------+--------------------+
| "alg" Param  | Digital Signature or MAC      | Implementation     |
| Value        | Algorithm                     | Requirements       |
+--------------+-------------------------------+--------------------+
| HS256        | HMAC using SHA-256            | Required           |
| HS384        | HMAC using SHA-384            | Optional           |
| HS512        | HMAC using SHA-512            | Optional           |
| RS256        | RSASSA-PKCS1-v1_5 using       | Recommended        |
|              | SHA-256                       |                    |

| RS384        | RSASSA-PKCS1-v1_5 using       | Optional           |
|              | SHA-384                       |                    |
| RS512        | RSASSA-PKCS1-v1_5 using       | Optional           |
|              | SHA-512                       |                    |
| ES256        | ECDSA using P-256 and SHA-256 | Recommended+       |
| ES384        | ECDSA using P-384 and SHA-384 | Optional           |
| ES512        | ECDSA using P-521 and SHA-512 | Optional           |
| PS256        | RSASSA-PSS using SHA-256 and  | Optional           |
|              | MGF1 with SHA-256             |                    |
| PS384        | RSASSA-PSS using SHA-384 and  | Optional           |
|              | MGF1 with SHA-384             |                    |
| PS512        | RSASSA-PSS using SHA-512 and  | Optional           |
|              | MGF1 with SHA-512             |                    |

| none         | No digital signature or MAC   | Optional           |
|              | performed                     |                    |
+--------------+-------------------------------+--------------------+

签名算法分为3类，第一类是 "HS" 开头的，使用对称密钥，HMAC算法进行签名和验证；第二类是 "RS/ES/PS" 开头的，使用非对称密钥进行签名和验证；第三类是 none，不签名，一般 alg 不设置为 none。

(3) kid

表示密钥ID，方便验证端选择验证签名的密钥。很多系统不使用这个字段，

PAYLOAD 也称作 Claims, JSON 格式的数据，经过 base64url 编码后所得。可以填入任何需要的值。这里只介绍最常用的字段，这些常用字段都是可选的，可以不设置。

{
  "iss": "123456-compute@developer.gserviceaccount.com",
  "sub": "123456-compute@developer.gserviceaccount.com",
  "aud": "https://firestore.googleapis.com/",
  "exp": 1511903600
}

(1) 签发者谁签发的这个 JWT。经常是一段网址，如 "https://login.example.com/" ，也有很多系统使用字符串。具体怎么标识签发者由系统实现时自行决定。

(2) sub 签发给谁。

(3) aud 这个 JWT 将用来请求哪个服务。

(4) exp 表示这个 JWT 的超时时间，超过这个时间则不再被系统承认。

将前面所述的两部分使用 "." 连接后，签名并 base64url 所得。签名算法列表如前所述。

签名保证了数据数据不可伪造补课修改，但数据仍然是明文的。

HMACSHA256(
  base64UrlEncode(HEADER) + "." +
  base64UrlEncode(PAYLOAD),
  secret)

使用 JWT 作为令牌，签名肯定是必要的。但是表示签名算法的 alg 字段，明文写在 HEADER 里。这是公认的标准设计问题，alg 字段本不该存在。

目前已知的攻击方式至少有两种：

(1) 将 alg 字段改为 "none" 攻击者按照格式构造一个JWT，并将 alg 字段设置为 none。如果验证方按照 JWT 的 alg 字段指定的算法验证 JWT，发现 alg 为 none，就直接通过验证了。

(2) 将非对称签名算法改为对称签名算法例如，将 alg="RS256" 改为 alg="HS256"。 攻击者截获一个 RS256 签名方式的 JWT，按照其格式构造并修改，设置 alg="SHA256"，并使用公钥作为签名密钥签名。正常情况下，验证方按照 alg 字段指定的算法验证 JWT，发现 alg="RS256"，使用公钥按照 RS256 算法验证；被使用次方式攻击时，发现 alg="HS256"，则使用 HMAC-SHA256 算法，使用RSA的公钥作为签名密钥验证。公钥一般是公开的，所以这个构造是可能的。

对称密钥太短或者太有规律，就跟使用弱密码一样，有很多这方面的 破解 工具 。

PAYLOAD 是明文的，千万别把敏感信息写在 JWT 里。见过把用户的密码写在 JWT 里，被人拿到就泄露了； 也有把用户信息如手机号身份证号写在 JWT 里的，违反了大多数国家的法律法规。

当然 JWT 也有 加密方案，只是不常用。

这与具体实现的系统有关。如果 HEADER.kid="../../../../../../../dev/null"，你的系统是不是使用空的密钥验证签名呢？ 如果 HEADER.kid="xxx' UNION SELECT 'aaa"，你的系统会不会使用 "aaa" 作为密钥验证签名呢？

微软专门写了个 JSON Web Token Best Current Practices，照做就可以。当然还有其它注意事项：

(1) 防止 XSS, 如果在 cookie 中使用 JWT，使用 HttpOnly 标志。

(2) 别存 JWT。

(3) 不要相信并依赖 JWT 中的字段，验证字段与期望是否匹配。特别注意验证 alg 字段的值是否跟要求的一致。

(4) 对称签名密钥够长，至少跟哈希算法长度一致。

(5) token 只是 token，别用来管理 Session。

(6) 不要把敏感信息写在 JWT 里。