JSON web token@07#Creating and Validating JWTs

7. Creating and Validating JWTs (创建和验证 JWTs)

7.1. Creating a JWT (创建一个 JWT)

为了创建一个 JWT，需要执行下面的步骤。在不依赖步骤执行输入和输出的情况下，步骤的执行顺序不重要。

1. 创建一个 JWT Claims Set 包含要求的 claims。 注意在书写的时候空格是明确允许出现的，并且在进行加密之前不需要任何标准化操作。
   
   1. 让 JWT Claims Set 使用 UTF-8 编码，以八进制的形式呈现。
   2. 创建一个 JOSE Header 包含要求的 Header 参数。 这个 JWT MUST 符合 JWS 或者 JWE 规范。注意在书写的时候明确允许出现空格，在进行加密之前不需要进行任何标准化操作。
   3. 根据 JWT 是一个 JWS 还是 JWE，这里有两种情况：
      
      • 如果这个 JWT 是一个 JWS， 用这个 Message 充当 JWS 的 JWS Payload 创建一个 JWS; MUST 遵循 JWS 规范中指定的创建一个 JWS 的所有步骤。
      • 否则，如果这个 JWT 是一个 JWE， 用这个 Message 充当 JWE 的 plaintext 创建一个 JWE; MUST 遵循 JWE 规范中指定的创建一个 JWE 的所有步骤。
   4. 如果将要执行一个内嵌的 signing 或 encryption operation, 让这个 Message 作为 JWS 或者 JWE， 然后返回第3步， 在这步创建新的 JOSE Header 时使用 “cty” (content type) 作为 “JWT” 的值。
   5. 其他情况，让输出结果作为 JWS 或者 JWE。

7.2. Validating a JWT (验证一个 JWT)

当验证一个 JWT 时，需要进行下面的步骤。在不依赖步骤执行输入和输出的情况下，步骤的执行顺序不重要。如果下面罗列步骤中的任何一步失败了，那么 JWT MUST 被拒绝 – 也就是说，应用程序将把它当作一次非法的输入。

1. 验证这个JWT 至少包含一个英文逗号(’.’)。
2. 加密的 JOSE Header 就是 JWT 中第一个引文逗号(’.’)之前的部分。
3. 用 Base64url 解密这个加密的 JOSE Header， 并严格遵循下列步骤：没有换行符，空格 或其他使用的附加字符。
4. 验证输出的八进制序列式一个八进制编码的，表示一个符合 RFC7159 规范的完整且有效的 JSON 对象；让这个 JOSE Header 充当这个 JSON 对象。
5. 验证 JOSE Header 的输出结果只包含语法和语义都能够被理解和支持的参数和值，如果指定的无法明白，将被忽略。
6. 使用 JWE 规定第 9 章所描述的方法来检查这个 JWT 是 JWS 还是 JWE。
7. 根据 JWT 到底是 JWS 还是 JWE，这里有两种情况：
   
   • 如果这个 JWT 是一个 JWS，遵循 JWS 规范指定的验证一个 JWS 的步骤。让这个 Message 作为用 base64url 解密 JWS Payload 后的结果。
   • 否则，如果这个 JWT 是一个 JWE, 遵循 JWE 规范所指定的验证一个 JWE 的步骤。让这个 Message 作为 plaintext 的结果。
8. 如果这个 JOSE Header 包含 “JWT” 中一个 “cty” (content type) 值，那么这个 Message 是一个 JWT。它是 nested signing 或者 encryption operations 的 subject。在这种情况下，返回第一步，把这个 Message 作为 JWT。
9. 其他情况，用 base64url 解密这个 Message。 并遵循下列限制条件：没有换行符，空格或其他使用的附加字符。
10. 验证这个输出的八进制序列是否是 UTF-8 编码，并遵循 RFC7159 规范中记载的完整验证 JSON 对象的方法。然这个 JWT Claims Set 作为这个 JSON 对象。最后，注意它由应用程序决定对给出的 context 使用哪种算法。除非 JWT 使用的这种算法对应用程序来说是支持的，否则即使这个 JWT 能够成功地通过验证。应用程序 SHOULD 拒绝这个 JWT。

7.3. String Comparison Rules (String 比较规则)

处理一个 JWT 必然要求将知道的 strings 同 JSON 对象中成员和值进行比较。例如，检查到底是什么算法，Unicode string 编码的 “alg” 将同 JOSE Header 里面的成员名称进行对比，看里面是否有一个 Header Parameter name 和它一样。

在 RFC7159 规范的 8.3 章节中描述了 JSON 规则中处理 member name 的对比方式。由于单个 String 执行的操作只有一种：要么相等，要么不相等，对已知的字符串，相同的规则可以用于比较两个 member names 和 member values。

这些对比规则 MUST 应用于所有的 JSON string 对比，除非在这种情况下：member 的定义显式地调用了了不同的比较规则来比较 member values。在本规范中，只有 “type” 和 “cty” 的 member values 不需要使用这些对比规则。

一些应用程序可能以区分大小写的值得方式包含大小写敏感的信息，例如 “iss”(issuer) claim value 中的 DNS name 部分。在那些场景下，应用程序可能需要定义一个用于场景的代表公约的规范，以表示区分大小写的部分，例如将他们转换成小写，如果超过了一方可能需要产生相同的值，这样就可以比较。(然而，如果所有其他的消费者方接收生产者方发出逐字的任何值，而不试图以一个独立的生产方的值比较，那么这个情况下生产者使用对比规则将不重要。)