[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
PROPOSED STANDARD
Updated by: 7797, 8725 Errata ExistInternet Engineering Task Force (IETF) M. Jones
Request for Comments: 7519 Microsoft
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Sakimura
NRI
May 2015
JSON Web 令牌（JWT）
摘要
JSON Web Token（JWT）是一种紧凑、URL 安全的方式，用于表示在两个参与方之间传输的声明。
JWT 中的声明被编码为一个 JSON 对象，该对象作为 JSON Web Signature（JWS）结构的有效载荷，
或作为 JSON Web Encryption（JWE）结构的明文使用，从而使这些声明能够被进行数字签名，
或通过消息认证码（MAC）进行完整性保护，和/或被加密。
本文档状态
本文档是 Internet 标准轨道（Standards Track）文档。
本文档是 Internet 工程任务组（IETF）的成果。
它代表了 IETF 社区的共识。
本文档已经过公开审查，并已获 Internet 工程指导组（IESG）批准发布。
有关 Internet 标准的更多信息，参见
RFC 5741 的第 2 节。
有关本文档当前状态、任何勘误信息，以及如何提供反馈的信息，
可通过以下地址获取：
http://www.rfc-editor.org/info/rfc7519。
Jones, et al. Standards Track [Page 1]
RFC 7519 JSON Web Token (JWT) May 2015
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jones, et al. Standards Track [Page 2]
RFC 7519 JSON Web Token (JWT) May 2015
目录
1. 引言 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. 记法约定 . . . . . . . . . . . . . . . . . . . . . . . . 4
2. 术语 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token（JWT）概述 . . . . . . . . . . . . . . . . . . 6
3.1. JWT 示例 . . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT 声明 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. 已注册的声明名称 . . . . . . . . . . . . . . . . . . . 9
4.1.1. “iss”（签发者）声明 . . . . . . . . . . . . . . . . . 9
4.1.2. “sub”（主体）声明 . . . . . . . . . . . . . . . . . 9
4.1.3. “aud”（受众）声明 . . . . . . . . . . . . . . . . . 9
4.1.4. “exp”（过期时间）声明 . . . . . . . . . . . . . . . 9
4.1.5. “nbf”（不早于）声明 . . . . . . . . . . . . . . . 10
4.1.6. “iat”（签发时间）声明 . . . . . . . . . . . . . . . 10
4.1.7. “jti”（JWT ID）声明 . . . . . . . . . . . . . . . . 10
4.2. 公共声明名称 . . . . . . . . . . . . . . . . . . . . . 10
4.3. 私有声明名称 . . . . . . . . . . . . . . . . . . . . . . 10
5. JOSE 头部 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. “typ”（类型）头部参数 . . . . . . . . . . . . . . . . 11
5.2. “cty”（内容类型）头部参数 . . . . . . . . . . . . . . 11
5.3. 将声明复制为头部参数 . . . . . . . . . . . . . . . . 12
6. 非安全 JWT . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. 非安全 JWT 示例 . . . . . . . . . . . . . . . . . . . . 12
7. 创建与验证 JWT . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. 创建 JWT . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. 验证 JWT . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. 字符串比较规则 . . . . . . . . . . . . . . . . . . . . 15
8. 实现要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. 声明内容为 JWT 的 URI . . . . . . . . . . . . . . . . . . . 17
10. IANA 注意事项 . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token 声明注册表 . . . . . . . . . . . . . . . 17
10.1.1. 注册模板 . . . . . . . . . . . . . . . . . . . . . 18
10.1.2. 初始注册表内容 . . . . . . . . . . . . . . . . . . 18
10.2. urn:ietf:params:oauth:token-type:jwt
子命名空间注册 . . . . . . . . . . . . . . . . . . . . 19
10.2.1. 注册表内容 . . . . . . . . . . . . . . . . . . . . . 19
10.3. 媒体类型注册 . . . . . . . . . . . . . . . . . . . . . . . 20
10.3.1. 注册表内容 . . . . . . . . . . . . . . . . . . . . . 20
10.4. 头部参数名称注册 . . . . . . . . . . . . . . . . . . . . 20
10.4.1. 注册表内容 . . . . . . . . . . . . . . . . . . . . . 21
11. 安全性注意事项 . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. 信任决策 . . . . . . . . . . . . . . . . . . . . . . . 21
11.2. 签名与加密顺序 . . . . . . . . . . . . . . . . . . . . 21
12. 隐私注意事项 . . . . . . . . . . . . . . . . . . . . . . . . 22
13. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. 规范性引用 . . . . . . . . . . . . . . . . . . . . . . 22
13.2. 参考性引用 . . . . . . . . . . . . . . . . . . . . . . 23
Jones, et al. Standards Track [Page 3]
RFC 7519 JSON Web Token (JWT) May 2015
附录 A. JWT 示例 . . . . . . . . . . . . . . . . . . . . . . . . 26
A.1. 加密的 JWT 示例 . . . . . . . . . . . . . . . . . . . . . 26
A.2. 嵌套 JWT 示例 . . . . . . . . . . . . . . . . . . . . . 26
附录 B. JWT 与 SAML 断言的关系 . . . . . . . . . . . . . . . . 28
附录 C. JWT 与 Simple Web Token（SWT）的关系 . . 28
致谢 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
作者地址 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1. 引言
JSON Web Token（JWT）是一种紧凑的声明表示格式，
旨在用于诸如 HTTP 授权头字段和 URI 查询参数等
受限空间的环境。JWT 将要传输的声明编码为一个 JSON
[RFC7159] 对象，
该对象作为 JSON Web Signature（JWS）
[JWS] 结构的有效载荷，
或作为 JSON Web Encryption（JWE）
[JWE] 结构的明文，
从而使这些声明能够被进行数字签名，
或通过消息认证码（MAC）进行完整性保护，和/或被加密。
JWT 始终使用 JWS 紧凑序列化形式或 JWE 紧凑序列化形式来表示。
JWT 的推荐读音与英语单词 “jot” 相同。
1.1. 记法约定
本文档中出现的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、
“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和
“OPTIONAL”，应按照
《Key words for use in RFCs to Indicate Requirement Levels》
[RFC2119]
中的描述进行解释。
仅当这些术语以全大写形式出现时，才适用该解释。
2. 术语
术语 “JSON Web Signature（JWS）”、“Base64url 编码”、“头部参数”、“JOSE 头部”、
“JWS 紧凑序列化”、“JWS 有效载荷”、“JWS 签名” 以及 “非安全 JWS”，
均由 JWS 规范
[JWS] 定义。
术语 “JSON Web Encryption（JWE）”、“内容加密密钥（CEK）”、“JWE 紧凑序列化”、
“JWE 加密密钥” 以及 “JWE 初始化向量”，
均由 JWE 规范
[JWE] 定义。
术语 “密文”、“数字签名”、“消息认证码（MAC）” 以及 “明文”，
定义于《Internet Security Glossary, Version 2》
[RFC4949]。
Jones, et al. Standards Track [Page 4]
RFC 7519 JSON Web Token (JWT) May 2015
本规范定义了以下术语：
JSON Web Token（JWT）
一个字符串，用于表示一组声明，这些声明以 JSON 对象形式存在，
并被编码到 JWS 或 JWE 中，从而使这些声明能够被进行数字签名、
使用 MAC 保护，和/或被加密。
JWT 声明集
一个 JSON 对象，包含由 JWT 传递的声明。
声明
关于某个主体所断言的一条信息。
一个声明由声明名称和声明值组成的名称/值对表示。
声明名称
声明表示中的名称部分。
声明名称始终是一个字符串。
声明值
声明表示中的值部分。
声明值可以是任意 JSON 值。
嵌套 JWT
使用了嵌套签名和/或加密的 JWT。
在嵌套 JWT 中，一个 JWT 被用作外层 JWS 或 JWE 结构的
有效载荷或明文值。
非安全 JWT
其声明未进行完整性保护或加密的 JWT。
抗冲突名称
命名空间中的一种名称分配方式，使其与其他名称发生冲突的概率极低。
抗冲突命名空间的示例包括：域名、ITU-T X.660 与 X.670
建议系列中定义的对象标识符（OID），以及
通用唯一标识符（UUID）
[RFC4122]。
在使用行政委派的命名空间时，名称的定义者需要采取合理的预防措施，
以确保其对用于定义名称的命名空间部分具有控制权。
StringOrURI
一个 JSON 字符串值，附加要求是：
虽然可以使用任意字符串值，但任何包含 “:” 字符的值
都 MUST 是一个 URI
[RFC3986]。
StringOrURI 值以区分大小写的字符串进行比较，
不进行任何转换或规范化。
Jones, et al. Standards Track [Page 5]
RFC 7519 JSON Web Token (JWT) May 2015
NumericDate
一个 JSON 数值，表示从 1970-01-01T00:00:00Z UTC
到指定 UTC 日期/时间所经过的秒数，
不考虑闰秒。
这等同于 IEEE Std 1003.1（2013 版）
[POSIX.1]
中 “自纪元以来的秒数” 的定义，
其中每天严格按 86400 秒计算，
不同之处在于可以表示非整数值。
有关日期/时间的一般细节以及 UTC 的具体说明，
参见 RFC 3339
[RFC3339]。
3. JSON Web Token（JWT）概述
JWT 以 JSON 对象的形式表示一组声明，
并被编码到 JWS 和/或 JWE 结构中。
该 JSON 对象即为 JWT 声明集。
根据 RFC 7159 的第 4 节
[RFC7159]，
JSON 对象由零个或多个名称/值对（或成员）组成，
其中名称是字符串，值是任意 JSON 值。
这些成员即为 JWT 所表示的声明。
根据 RFC 7159 的第 2 节
[RFC7159]，
该 JSON 对象 MAY 在任意 JSON 值或结构字符之前或之后
包含空白字符和/或换行符。
JWT 声明集中的成员名称称为声明名称，
对应的值称为声明值。
JOSE 头部的内容描述了应用于 JWT 声明集的密码学操作。
如果 JOSE 头部用于 JWS，则 JWT 被表示为一个 JWS，
声明被进行数字签名或使用 MAC 保护，
此时 JWT 声明集即为 JWS 有效载荷。
如果 JOSE 头部用于 JWE，则 JWT 被表示为一个 JWE，
声明被加密，
此时 JWT 声明集即为被 JWE 加密的明文。
一个 JWT 可以被封装在另一个 JWE 或 JWS 结构中，
以创建一个嵌套 JWT，从而实现嵌套的签名和加密。
JWT 由一系列 URL 安全的部分组成，
各部分之间使用句点字符（“.”）分隔。
每一部分都包含一个 base64url 编码的值。
JWT 中部分的数量取决于最终所使用的表示形式，
即 JWS 紧凑序列化或 JWE 紧凑序列化。
Jones, et al. Standards Track [Page 6]
RFC 7519 JSON Web Token (JWT) May 2015
3.1. JWT 示例
以下示例中的 JOSE 头部声明该被编码的对象是一个 JWT，
并且该 JWT 是一个使用 HMAC SHA-256 算法进行 MAC 处理的 JWS：
{"typ":"JWT",
"alg":"HS256"}
为消除上述 JSON 对象表示中可能存在的歧义，
下面同时给出了本示例中 JOSE 头部所使用的
实际 UTF-8 表示的八位字节序列。
（请注意，歧义可能由于不同平台对换行符的表示
（CRLF 与 LF）、行首和行尾空格的差异、
最后一行是否包含终止换行符等原因而产生。
在本示例所使用的表示中，
第一行没有前导或尾随空格，
第一行与第二行之间使用 CRLF 换行（13, 10），
第二行有一个前导空格（32）且没有尾随空格，
并且最后一行不包含终止换行符。）
本示例中 JOSE 头部 UTF-8 表示对应的八位字节
（使用 JSON 数组记法）如下：
[123, 34, 116, 121, 112, 34, 58, 34, 74, 87, 84, 34, 44, 13, 10, 32,
34, 97, 108, 103, 34, 58, 34, 72, 83, 50, 53, 54, 34, 125]
对上述 UTF-8 表示的 JOSE 头部八位字节进行 Base64url 编码，
得到如下编码后的 JOSE 头部值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
以下是一个 JWT 声明集示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
以下八位字节序列是本示例中上述 JWT 声明集
所使用的 UTF-8 表示，
也是 JWS 的有效载荷：
[123, 34, 105, 115, 115, 34, 58, 34, 106, 111, 101, 34, 44, 13, 10,
32, 34, 101, 120, 112, 34, 58, 49, 51, 48, 48, 56, 49, 57, 51, 56,
48, 44, 13, 10, 32, 34, 104, 116, 116, 112, 58, 47, 47, 101, 120, 97,
109, 112, 108, 101, 46, 99, 111, 109, 47, 105, 115, 95, 114, 111,
111, 116, 34, 58, 116, 114, 117, 101, 125]
Jones, et al. Standards Track [Page 7]
RFC 7519 JSON Web Token (JWT) May 2015
对 JWS Payload 进行 Base64url 编码会得到如下编码后的 JWS Payload
（仅为展示目的而加入了换行）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
使用 HMAC SHA-256 算法对已编码的 JOSE Header 和已编码的 JWS Payload
计算 MAC，并按照 [JWS] 中规定的方式
对 HMAC 值进行 base64url 编码，可得到如下编码后的 JWS Signature：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按以下顺序将这些已编码的部分连接起来，并在各部分之间使用句点（'.'）
字符，即可得到完整的 JWT（仅为展示目的而加入了换行）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
该计算过程在 [JWS] 的
附录 A.1 中有更为详细的说明。
有关加密 JWT 的示例，参见 附录 A.1。
4. JWT 声明
JWT 声明集表示一个 JSON 对象，其成员为 JWT 所传递的声明。
JWT 声明集中的声明名 MUST 是唯一的；
JWT 解析器 MUST 要么拒绝包含重复声明名的 JWT，
要么使用仅返回字面上最后一个重复成员名的 JSON 解析器，
如 ECMAScript 5.1 [ECMAScript] 的
第 15.12 节（“JSON 对象”）中所规定。
为使 JWT 被视为有效而必须包含的声明集合依赖于具体上下文，
不在本规范的范围之内。
JWT 的具体应用将要求实现以特定方式理解和处理某些声明。
然而，在不存在此类要求的情况下，实现 MUST 忽略所有其不理解的声明。
JWT 声明名分为三类：已注册声明名、公有声明名和私有声明名。
Jones, et al. Standards Track [Page 8]
RFC 7519 JSON Web Token (JWT) May 2015
4.1. 已注册声明名
以下声明名已注册于 第 10.1 节 建立的
IANA “JSON Web Token Claims” 注册表中。
下文定义的声明均不打算在所有情况下都成为必须使用或实现的，
而是为一组有用且可互操作的声明提供一个起点。
使用 JWT 的应用应当定义它们所使用的具体声明，以及这些声明
在何时是必需的或可选的。
所有名称都较短，因为 JWT 的一个核心目标是使表示形式保持紧凑。
4.1.1. “iss”（签发者）声明
“iss”（issuer，签发者）声明标识签发 JWT 的主体。
该声明的处理通常是特定于应用的。
“iss” 的值是一个区分大小写的字符串，包含一个 StringOrURI 值。
使用该声明是 OPTIONAL 的。
4.1.2. “sub”（主题）声明
“sub”（subject，主题）声明标识作为 JWT 主题的主体。
JWT 中的声明通常是关于该主题的陈述。
主题值 MUST 要么在签发者的上下文中具有局部唯一性，
要么具有全局唯一性。
该声明的处理通常是特定于应用的。
“sub” 的值是一个区分大小写的字符串，包含一个 StringOrURI 值。
使用该声明是 OPTIONAL 的。
4.1.3. “aud”（受众）声明
“aud”（audience，受众）声明标识 JWT 的预期接收方。
每一个预期处理该 JWT 的主体 MUST 使用受众声明中的某个值来标识自身。
如果在该声明存在时，处理该声明的主体未能使用 “aud” 声明中的值
标识自身，则 MUST 拒绝该 JWT。
在一般情况下，“aud” 的值是一个区分大小写的字符串数组，
每个字符串都包含一个 StringOrURI 值。
在 JWT 只有一个受众的特殊情况下，“aud” 的值 MAY 是一个
区分大小写的字符串，包含一个 StringOrURI 值。
受众值的解释通常是特定于应用的。
使用该声明是 OPTIONAL 的。
4.1.4. “exp”（过期时间）声明
“exp”（expiration time，过期时间）声明标识一个时间点，
在该时间点或之后，JWT MUST NOT 被接受用于处理。
对 “exp” 声明的处理要求当前日期/时间 MUST 早于
“exp” 声明中列出的过期日期/时间。
Jones, et al. Standards Track [Page 9]
RFC 7519 JSON Web Token (JWT) May 2015
实现 MAY 提供一定程度的时间容差，通常不超过几分钟，
以应对时钟偏差。
其值 MUST 是一个包含 NumericDate 值的数字。
使用该声明是 OPTIONAL 的。
4.1.5. “nbf”（不早于）声明
“nbf”（not before，不早于）声明标识一个时间点，
在该时间点之前，JWT MUST NOT 被接受用于处理。
对 “nbf” 声明的处理要求当前日期/时间 MUST 晚于或等于
“nbf” 声明中列出的不早于日期/时间。
实现 MAY 提供一定程度的时间容差，通常不超过几分钟，
以应对时钟偏差。
其值 MUST 是一个包含 NumericDate 值的数字。
使用该声明是 OPTIONAL 的。
4.1.6. “iat”（签发时间）声明
“iat”（issued at，签发时间）声明标识 JWT 被签发的时间。
该声明可用于确定 JWT 的存活时间。
其值 MUST 是一个包含 NumericDate 值的数字。
使用该声明是 OPTIONAL 的。
4.1.7. “jti”（JWT ID）声明
“jti”（JWT ID）声明为 JWT 提供一个唯一标识符。
标识符值 MUST 以一种方式分配，以确保意外将相同值分配给
不同数据对象的概率可以忽略不计；
如果应用使用多个签发者，也 MUST 防止由不同签发者产生的值之间发生冲突。
“jti” 声明可用于防止 JWT 被重放。
“jti” 的值是一个区分大小写的字符串。
使用该声明是 OPTIONAL 的。
4.2. 公有声明名
使用 JWT 的各方可以自由定义声明名。
然而，为了防止冲突，任何新的声明名要么应当注册到
第 10.1 节 建立的 IANA “JSON Web Token Claims” 注册表中，
要么应当是一个公有名称：即包含一个抗冲突名称的值。
在这两种情况下，名称或值的定义者都需要采取合理的预防措施，
以确保其对用于定义声明名的命名空间部分具有控制权。
4.3. 私有声明名
JWT 的生成者和使用者 MAY 约定使用私有名称作为声明名：
即既不是已注册声明名（第 4.1 节），
也不是公有声明名（第 4.2 节）。
与公有声明名不同，
Jones, et al. Standards Track [Page 10]
RFC 7519 JSON Web Token (JWT) May 2015
私有声明名可能发生冲突，应当谨慎使用。
5. JOSE Header
对于一个 JWT 对象，由 JOSE Header 表示的 JSON 对象的成员
描述了应用于该 JWT 的密码学操作，以及（可选的）JWT 的附加属性。
根据 JWT 是 JWS 还是 JWE，适用相应的 JOSE Header 值规则。
本规范进一步规定了以下 Header 参数在 JWT 为 JWS 和为 JWE
这两种情况下的使用方式。
5.1. “typ”（类型）Header 参数
[JWS] 和
[JWE] 定义的
“typ”（type，类型）Header 参数
由 JWT 应用用于声明该完整 JWT 的媒体类型
[IANA.MediaTypes]。
其设计目的是在一个应用数据结构中，可能同时存在 JWT
以及非 JWT 的值时，由 JWT 应用使用该值来区分可能存在的不同对象类型。
当已经明确对象是 JWT 时，应用通常不会使用该参数。
该参数会被 JWT 实现忽略；对该参数的任何处理均由 JWT 应用执行。
如果存在，RECOMMENDED 其值为 “JWT”，以表明该对象是一个 JWT。
虽然媒体类型名称不区分大小写，但为与遗留实现兼容，
RECOMMENDED 始终使用大写形式拼写 “JWT”。
使用该 Header 参数是 OPTIONAL 的。
5.2. “cty”（内容类型）Header 参数
[JWS] 和
[JWE] 定义的
“cty”（content type，内容类型）Header 参数
由本规范用于传达有关 JWT 的结构信息。
在未采用嵌套签名或加密操作的正常情况下，
NOT RECOMMENDED 使用该 Header 参数。
在采用嵌套签名或加密操作的情况下，该 Header 参数 MUST 存在；
此时，其值 MUST 为 “JWT”，以表明该 JWT 中承载的是一个嵌套 JWT。
虽然媒体类型名称不区分大小写，但为与遗留实现兼容，
RECOMMENDED 始终使用大写形式拼写 “JWT”。
有关嵌套 JWT 的示例，参见 附录 A.2。
Jones, et al. Standards Track [Page 11]
RFC 7519 JSON Web Token (JWT) May 2015
5.3. 将声明复制为 Header 参数
在某些使用加密 JWT 的应用中，
以未加密形式表示某些声明是有用的。
例如，这可用于在解密 JWT 之前，
在应用处理规则中确定是否以及如何处理该 JWT。
本规范允许在作为 JWE 的 JWT 中，
根据应用需要，将 JWT 声明集中的声明复制为 Header 参数。
如果存在此类复制的声明，
除非应用为这些声明定义了其他特定的处理规则，
接收它们的应用 SHOULD 验证其值是否完全一致。
确保仅将适合以未加密方式传输的声明
复制为 JWT 中的 Header 参数值，
是应用自身的责任。
本规范的 第 10.4.1 节
注册了 “iss”（签发者）、“sub”（主题）和
“aud”（受众）这三个 Header 参数名，
以便在需要的应用中，
为加密 JWT 提供这些声明的未加密副本。
其他规范 MAY 以类似方式，
根据需要将其他已注册声明名注册为 Header 参数名。
6. 未加密的 JWT
为支持这样一些使用场景：
JWT 内容通过 JWT 内部所包含的签名和/或加密之外的方式进行保护
（例如，对包含 JWT 的数据结构进行签名），
JWT 也 MAY 在不使用签名或加密的情况下创建。
未加密 JWT 是一种 JWS，其 “alg” Header 参数值为 “none”，
且其 JWS Signature 值为空字符串，
如 [JWA] 规范中所定义；
它是一个未加密的 JWS，
并将 JWT 声明集作为其 JWS Payload。
6.1. 未加密 JWT 示例
以下示例 JOSE Header 声明该编码对象是一个未加密 JWT：
{"alg":"none"}
对 JOSE Header 的 UTF-8 表示的字节序列进行 Base64url 编码，
可得到如下编码后的 JOSE Header 值：
eyJhbGciOiJub25lIn0
Jones, et al. Standards Track [Page 12]
RFC 7519 JSON Web Token (JWT) May 2015
以下是一个 JWT 声明集示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
对 JWT 声明集的 UTF-8 表示的字节序列进行 Base64url 编码，
可得到如下编码后的 JWS Payload（仅为展示目的而加入了换行）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
编码后的 JWS Signature 为空字符串。
按以下顺序将这些已编码的部分连接起来，
并在各部分之间使用句点（'.'）字符，
即可得到完整的 JWT（仅为展示目的而加入了换行）：
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
7. 创建与验证 JWT
7.1. 创建 JWT
创建 JWT 时，执行以下步骤。
在各步骤的输入与输出之间不存在依赖关系的情况下，
步骤的执行顺序并不重要。
1. 创建一个包含所需声明的 JWT 声明集。
注意，表示中明确允许存在空白字符，
且在编码之前无需进行规范化处理。
2. 将 Message 设为 JWT 声明集的 UTF-8 表示的字节序列。
3. 创建一个包含所需 Header 参数集合的 JOSE Header。
JWT MUST 符合 [JWS] 或
[JWE] 规范之一。
注意，表示中明确允许存在空白字符，
且在编码之前无需进行规范化处理。
Jones, et al. Standards Track [Page 13]
RFC 7519 JSON Web Token (JWT) May 2015
4. 根据 JWT 是 JWS 还是 JWE，存在以下两种情况：
* 如果 JWT 是 JWS，
使用 Message 作为 JWS Payload 创建一个 JWS；
MUST 遵循 [JWS] 中
指定的所有创建 JWS 的步骤。
* 否则，如果 JWT 是 JWE，
使用 Message 作为 JWE 的明文创建一个 JWE；
MUST 遵循 [JWE] 中
指定的所有创建 JWE 的步骤。
5. 如果将执行嵌套签名或加密操作，
则将 Message 设为该 JWS 或 JWE，
并返回步骤 3，
在该步骤中新创建的 JOSE Header 中
使用值为 “JWT” 的 “cty”（内容类型）。
6. 否则，将生成的 JWS 或 JWE 作为最终的 JWT。
7.2. 验证 JWT
验证 JWT 时，执行以下步骤。
在各步骤的输入与输出之间不存在依赖关系的情况下，
步骤的执行顺序并不重要。
如果列出的任一步骤失败，
则 MUST 拒绝该 JWT——
即由应用将其视为无效输入。
1. 验证 JWT 至少包含一个句点（'.'）字符。
2. 将 Encoded JOSE Header
设为 JWT 中第一个句点（'.'）字符之前的部分。
3. 对 Encoded JOSE Header 进行 Base64url 解码，
并遵循不得使用换行、空白或其他附加字符的限制。
4. 验证所得字节序列是一个完全有效的、
UTF-8 编码的 JSON 对象表示，
且符合 RFC 7159
[RFC7159]；
将该 JSON 对象设为 JOSE Header。
5. 验证所得的 JOSE Header 仅包含
语法和语义均被理解和支持的参数和值，
或者包含那些在不被理解时被规定为应当忽略的参数和值。
6. 使用 [JWE] 的第 9 节中描述的任一方法，
确定 JWT 是 JWS 还是 JWE。
Jones, et al. Standards Track [Page 14]
RFC 7519 JSON Web Token (JWT) May 2015
7. 根据 JWT 是 JWS 还是 JWE，存在以下两种情况：
* 如果 JWT 是 JWS，
遵循 [JWS] 中
指定的验证 JWS 的步骤。
将 Message 设为对 JWS Payload
进行 base64url 解码后的结果。
* 否则，如果 JWT 是 JWE，
遵循 [JWE] 中
指定的验证 JWE 的步骤。
将 Message 设为得到的明文。
8. 如果 JOSE Header 包含值为 “JWT” 的
“cty”（内容类型），
则 Message 是一个曾作为嵌套签名或加密操作对象的 JWT。
在这种情况下，返回步骤 1，
并将 Message 作为 JWT 继续处理。
9. 否则，对 Message 进行 base64url 解码，
并遵循不得使用换行、空白或其他附加字符的限制。
10. 验证所得字节序列是一个完全有效的、
UTF-8 编码的 JSON 对象表示，
且符合 RFC 7159
[RFC7159]；
将该 JSON 对象设为 JWT 声明集。
最后需要注意的是，
在给定上下文中允许使用哪些算法，
由应用自行决定。
即使某个 JWT 能够被成功验证，
只要该 JWT 所使用的算法对应用而言不可接受，
应用仍 SHOULD 拒绝该 JWT。
7.3. 字符串比较规则
处理 JWT 不可避免地需要将已知字符串
与 JSON 对象中的成员和值进行比较。
例如，在检查算法类型时，
会将 Unicode
[UNICODE]
字符串编码的 “alg”
与 JOSE Header 中的成员名进行比较，
以判断是否存在匹配的 Header 参数名。
用于执行成员名比较的 JSON 规则
描述于 RFC 7159 的第 8.3 节
[RFC7159]。
由于执行的字符串比较操作仅限于相等与不等，
因此相同的规则既可用于将成员名与已知字符串比较，
也可用于将成员值与已知字符串比较。
除非成员的定义明确指出该成员值应使用不同的比较规则，
否则 MUST 将这些比较规则用于所有 JSON 字符串比较。
在本规范中，只有 “typ” 和 “cty” 这两个成员值
不使用这些比较规则。
Jones, et al. Standards Track [Page 15]
RFC 7519 JSON Web Token (JWT) May 2015
某些应用可能会在区分大小写的值中
包含大小写不敏感的信息，
例如在 “iss”（签发者）声明值中包含 DNS 名称。
在这些情况下，
如果可能需要多个参与方生成相同的值以便进行比较，
应用可能需要定义一种约定，
用于表示大小写不敏感部分时所采用的规范大小写形式，
例如将其转换为小写。
（然而，如果所有其他参与方
都逐字消费生成方所输出的值，
而不尝试将其与独立生成的值进行比较，
那么生成方所使用的大小写形式将无关紧要。）
8. 实现要求
本节定义了本规范中哪些算法和特性是必须实现的。
使用本规范的应用
可以对其所使用的实现施加额外要求。
例如，一个应用可能要求支持加密 JWT 和嵌套 JWT，
而另一个应用可能要求支持
使用椭圆曲线数字签名算法（ECDSA），
基于 P-256 曲线和 SHA-256 哈希算法
（“ES256”）对 JWT 进行签名。
在 JSON Web Algorithms
[JWA] 中
指定的签名和 MAC 算法中，
符合要求的 JWT 实现
仅 MUST 实现 HMAC SHA-256（“HS256”）和 “none”。
RECOMMENDED 实现还应支持
使用 SHA-256 哈希算法的 RSASSA-PKCS1-v1_5（“RS256”），
以及使用 P-256 曲线和 SHA-256 哈希算法的 ECDSA（“ES256”）。
对其他算法和密钥长度的支持是 OPTIONAL 的。
对加密 JWT 的支持是 OPTIONAL 的。
如果某个实现提供了加密能力，
那么在 [JWA] 中
指定的加密算法中，
符合要求的实现
仅 MUST 实现
使用 2048 位密钥的 RSAES-PKCS1-v1_5（“RSA1_5”），
使用 128 位和 256 位密钥的 AES Key Wrap
（“A128KW” 和 “A256KW”），
以及使用 AES-CBC 和 HMAC SHA-2 的
组合认证加密算法
（“A128CBC-HS256” 和 “A256CBC-HS512”）。
RECOMMENDED 实现还应支持
使用椭圆曲线 Diffie-Hellman 临时静态方式（ECDH-ES）
协商用于包装内容加密密钥的密钥
（“ECDH-ES+A128KW” 和 “ECDH-ES+A256KW”），
以及使用 128 位和 256 位密钥的
AES Galois/Counter Mode（GCM）
（“A128GCM” 和 “A256GCM”）。
对其他算法和密钥长度的支持是 OPTIONAL 的。
对嵌套 JWT 的支持是 OPTIONAL 的。
Jones, et al. Standards Track [Page 16]
RFC 7519 JSON Web Token (JWT) May 2015
9. 用于声明内容为 JWT 的 URI
本规范注册了 URN
“urn:ietf:params:oauth:token-type:jwt”，
供那些使用 URI（而非例如媒体类型）
来声明内容类型的应用使用，
以表明所指内容是一个 JWT。
10. IANA 注意事项
10.1. JSON Web Token 声明注册表
本节为 JWT 声明名称建立 IANA “JSON Web Token Claims” 注册表。
该注册表记录声明名称以及定义该声明的规范的引用。
本节注册了在 第 4.1 节 中定义的声明名称。
值在 jwt-reg-review@ietf.org 邮件列表上经过三周的审查期后，
在一个或多个指定专家（Designated Experts）的建议下，
依据“需要规范（Specification Required）” [RFC5226] 的方式进行注册。
但是，为了允许在规范发布之前分配值，
只要指定专家确信该规范将会发布，
他们就可以批准注册。
发送到邮件列表以供审查的注册请求应使用适当的主题
（例如：“Request to register claim: example”）。
在审查期内，指定专家将批准或拒绝该注册请求，
并将其决定通知审查列表和 IANA。
拒绝时应包含解释，并在适用的情况下，
提供如何使请求成功的建议。
超过 21 天仍未确定的注册请求，
可以提交给 IESG（通过 iesg@ietf.org 邮件列表）
以寻求解决。
指定专家在评审时应应用的标准包括：
判断拟议的注册是否重复了现有功能，
是否可能具有普遍适用性，
或者是否仅对单一应用有用，
以及注册描述是否清晰。
IANA 只能接受来自指定专家的注册表更新，
并应将所有注册请求引导至审查邮件列表。
建议任命多名指定专家，
以代表使用本规范的不同应用的观点，
从而实现对注册决策的广泛而充分的信息化审查。
在某些情况下，如果某个注册决定可能被认为会为某位专家
造成利益冲突，
Jones, et al. Standards Track [Page 17]
RFC 7519 JSON Web Token (JWT) May 2015
该专家应将判断权交由其他专家。
10.1.1. 注册模板
Claim Name：
所请求的名称（例如，“iss”）。
由于本规范的一个核心目标是使最终表示形式保持紧凑，
因此建议名称尽量简短——也就是说，
除非有充分理由，否则不应超过 8 个字符。
该名称区分大小写。
除非指定专家声明有充分理由允许例外，
否则名称在不区分大小写的情况下不得与其他已注册名称匹配。
Claim Description：
对该声明的简要描述（例如，“Issuer”）。
Change Controller：
对于标准轨道 RFC，列出 “IESG”。
对于其他情况，给出负责方的名称。
也可以包含其他详细信息
（例如，邮政地址、电子邮件地址、主页 URI）。
Specification Document(s)：
对指定该参数的文档或文档集的引用，
最好包括可用于获取这些文档副本的 URI。
也可以包含相关章节的指示，但不是必需的。
10.1.2. 初始注册表内容
o Claim Name: "iss"
o Claim Description: 颁发者（Issuer）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.1 节
o Claim Name: "sub"
o Claim Description: 主题（Subject）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.2 节
o Claim Name: "aud"
o Claim Description: 受众（Audience）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.3 节
Jones, et al. Standards Track [Page 18]
RFC 7519 JSON Web Token (JWT) May 2015
o Claim Name: "exp"
o Claim Description: 过期时间（Expiration Time）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.4 节
o Claim Name: "nbf"
o Claim Description: 不早于（Not Before）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.5 节
o Claim Name: "iat"
o Claim Description: 签发时间（Issued At）
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.6 节
o Claim Name: "jti"
o Claim Description: JWT ID
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.7 节
10.2. 子命名空间注册：
urn:ietf:params:oauth:token-type:jwt
10.2.1. 注册表内容
本节在由
“An IETF URN Sub-Namespace for OAuth”
[RFC6755]
建立的 IANA “OAuth URI” 注册表中注册值 “token-type:jwt”，
该值可用于指示内容是一个 JWT。
o URN: urn:ietf:params:oauth:token-type:jwt
o Common Name: JSON Web Token（JWT）令牌类型
o Change Controller: IESG
o Specification Document(s): RFC 7519
Jones, et al. Standards Track [Page 19]
RFC 7519 JSON Web Token (JWT) May 2015
10.3. 媒体类型注册
10.3.1. 注册表内容
本节按照 RFC 6838
[RFC6838]
中描述的方式，
在 “Media Types” 注册表
[IANA.MediaTypes]
中注册媒体类型 “application/jwt”
[RFC2046]，
该媒体类型可用于指示内容是一个 JWT。
o Type name: application
o Subtype name: jwt
o Required parameters: 无
o Optional parameters: 无
o Encoding considerations: 8bit；JWT 值被编码为一系列
base64url 编码的值（其中一些可能是空字符串），
并以句点（“.”）字符分隔。
o Security considerations: 参见 RFC 7519 的安全注意事项章节
o Interoperability considerations: 无
o Published specification: RFC 7519
o Applications that use this media type: OpenID Connect、Mozilla
Persona、Salesforce、Google、Android、Windows Azure、Amazon Web
Services，以及众多其他应用
o Fragment identifier considerations: 无
o Additional information:
Magic number(s): 无
File extension(s): 无
Macintosh file type code(s): 无
o Person & email address to contact for further information:
Michael B. Jones, mbj@microsoft.com
o Intended usage: COMMON
o Restrictions on usage: 无
o Author: Michael B. Jones, mbj@microsoft.com
o Change controller: IESG
o Provisional registration? 否
10.4. 头参数名称注册
本节在由 [JWS]
建立的 IANA
“JSON Web Signature and Encryption Header Parameters” 注册表中，
注册了在 第 4.1 节 中定义的特定声明名称，
这些声明可根据 第 5.3 节
作为 JWE 中复制的头参数使用。
Jones, et al. Standards Track [Page 20]
RFC 7519 JSON Web Token (JWT) May 2015
10.4.1. 注册表内容
o Header Parameter Name: "iss"
o Header Parameter Description: 颁发者（Issuer）
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.1 节
o Header Parameter Name: "sub"
o Header Parameter Description: 主题（Subject）
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.2 节
o Header Parameter Name: "aud"
o Header Parameter Description: 受众（Audience）
o Header Parameter Usage Location(s): JWE
o Change Controller: IESG
o Specification Document(s): RFC 7519 的第 4.1.3 节
11. 安全注意事项
与任何密码学应用相关的所有安全问题，
都必须由 JWT/JWS/JWE/JWK 代理加以处理。
这些问题包括保护用户的非对称私钥和对称密钥，
以及采用针对各种攻击的对策。
JWS 规范中的所有安全注意事项同样适用于 JWT，
而在使用加密时，JWE 的安全注意事项也同样适用。
特别是 [JWS]
的第 10.12 节
（“JSON 安全注意事项”）
和第 10.13 节
（“Unicode 比较安全注意事项”）
以与其适用于 JOSE 头相同的方式，
同样适用于 JWT 声明集。
11.1. 信任决策
除非 JWT 的内容已经通过密码学方式得到保护，
并且与进行信任决策所需的上下文绑定，
否则其内容不能作为信任决策的依据。
特别是，用于对 JWT 进行签名和/或加密的密钥，
通常需要能够被验证为受 JWT 颁发者所标识的实体控制。
11.2. 签名与加密顺序
尽管从语法上看，
对嵌套 JWT 的签名和加密操作可以以任意顺序应用，
但如果既需要签名又需要加密，
通常生成方应先对消息进行签名，
然后再对结果进行加密
Jones, et al. Standards Track [Page 21]
RFC 7519 JSON Web Token (JWT) May 2015
（即对签名进行加密）。
这可以防止签名被剥离、只留下加密消息的攻击，
同时也为签名者提供隐私保护。
此外，在许多司法辖区中，
对加密文本进行签名并不被视为有效。
请注意，
与签名和加密操作顺序相关的潜在安全问题，
已经由底层的 JWS 和 JWE 规范加以解决；
特别是，由于 JWE 仅支持使用经过认证的加密算法，
在许多上下文中适用的、
关于是否需要在加密之后再进行签名的密码学顾虑，
并不适用于本规范。
12. 隐私注意事项
JWT 可能包含隐私敏感信息。
在这种情况下，必须采取措施，
防止这些信息被披露给非预期的参与方。
实现这一目标的一种方式是使用加密的 JWT，
并对接收方进行认证。
另一种方式是确保包含未加密隐私敏感信息的 JWT
仅通过使用支持端点认证的加密协议进行传输，
例如传输层安全协议（TLS）。
从 JWT 中省略隐私敏感信息，
是将隐私问题降至最低的最简单方法。
13. 参考文献
13.1. 规范性参考
[ECMAScript]
Ecma International，《ECMAScript 语言规范，
第 5.1 版》，ECMA 标准 262，2011 年 6 月，
<http://www.ecma-international.org/ecma-262/5.1/
ECMA-262.pdf>。
[IANA.MediaTypes]
IANA，《媒体类型》，
<http://www.iana.org/assignments/media-types>。
[JWA] Jones, M.，《JSON Web 算法（JWA）》，RFC 7518，
DOI 10.17487/RFC7518，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7518>。
[JWE] Jones, M. 和 J. Hildebrand，《JSON Web 加密（JWE）》，
RFC 7516，DOI 10.17487/RFC7516，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7516>。
Jones, et al. Standards Track [Page 22]
RFC 7519 JSON Web Token (JWT) May 2015
[JWS] Jones, M., Bradley, J. 和 N. Sakimura，《JSON Web
签名（JWS）》，RFC 7515，DOI 10.17487/RFC，2015 年 5 月，
<http://www.rfc-editor.org/info/rfc7515>。
[RFC20] Cerf, V.，《用于网络互换的 ASCII 格式》，STD 80，
RFC 20，DOI 10.17487/RFC0020，1969 年 10 月，
<http://www.rfc-editor.org/info/rfc20>。
[RFC2046] Freed, N. 和 N. Borenstein，《多用途互联网邮件扩展
（MIME）第二部分：媒体类型》，RFC 2046，
DOI 10.17487/RFC2046，1996 年 11 月，
<http://www.rfc-editor.org/info/rfc2046>。
[RFC2119] Bradner, S.，《在 RFC 中使用的
用于指示需求级别的关键词》，BCP 14，RFC 2119，
DOI 10.17487/RFC2119，1997 年 3 月，
<http://www.rfc-editor.org/info/rfc2119>。
[RFC3986] Berners-Lee, T., Fielding, R. 和 L. Masinter，
《统一资源标识符（URI）：通用语法》，STD 66，
RFC 3986，DOI 10.17487/RFC3986，2005 年 1 月，
<http://www.rfc-editor.org/info/rfc3986>。
[RFC4949] Shirey, R.，《互联网安全术语表，第 2 版》，
FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007 年 8 月，
<http://www.rfc-editor.org/info/rfc4949>。
[RFC7159] Bray, T.（编），《JavaScript 对象表示法（JSON）
数据交换格式》，RFC 7159，DOI 10.17487/RFC7159，2014 年 3 月，
<http://www.rfc-editor.org/info/rfc7159>。
[UNICODE] Unicode 联盟，《Unicode 标准》，
<http://www.unicode.org/versions/latest/>。
13.2. 资料性参考
[CanvasApp]
Facebook，《Canvas 应用》，2010 年，
<http://developers.facebook.com/docs/authentication/
canvas>。
[JSS] Bradley, J. 和 N. Sakimura（编辑），《JSON Simple Sign》，
2010 年 9 月，<http://jsonenc.info/jss/1.0/>。
Jones, et al. Standards Track [Page 23]
RFC 7519 JSON Web Token (JWT) May 2015
[MagicSignatures]
Panzer, J.（编），Laurie, B. 和 D. Balfanz，
《Magic Signatures》，2011 年 1 月，
<http://salmon-protocol.googlecode.com/svn/
trunk/draft-panzer-magicsig-01.html>。
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R. 和 E. Maler，
《OASIS 安全断言标记语言（SAML）V2.0 的断言与协议》，
OASIS 标准 saml-core-2.0-os，2005 年 3 月，
<http://docs.oasis-open.org/security/saml/v2.0/
saml-core-2.0-os.pdf>。
[POSIX.1] IEEE，《The Open Group Base Specifications 第 7 版》，
IEEE Std 1003.1，2013 版，2013 年，
<http://pubs.opengroup.org/onlinepubs/9699919799/
basedefs/V1_chap04.html#tag_04_15>。
[RFC3275] Eastlake 3rd, D., Reagle, J. 和 D. Solo，
《（可扩展标记语言）XML 签名语法与处理》，
RFC 3275，DOI 10.17487/RFC3275，2002 年 3 月，
<http://www.rfc-editor.org/info/rfc3275>。
[RFC3339] Klyne, G. 和 C. Newman，
《互联网中的日期和时间：时间戳》，
RFC 3339，DOI 10.17487/RFC3339，2002 年 7 月，
<http://www.rfc-editor.org/info/rfc3339>。
[RFC4122] Leach, P., Mealling, M. 和 R. Salz，
《通用唯一标识符（UUID）URN 命名空间》，
RFC 4122，DOI 10.17487/RFC4122，2005 年 7 月，
<http://www.rfc-editor.org/info/rfc4122>。
[RFC5226] Narten, T. 和 H. Alvestrand，
《RFC 中 IANA 注意事项章节的编写指南》，
BCP 26，RFC 5226，
DOI 10.17487/RFC5226，2008 年 5 月，
<http://www.rfc-editor.org/info/rfc5226>。
[RFC6755] Campbell, B. 和 H. Tschofenig，
《OAuth 的 IETF URN 子命名空间》，
RFC 6755，DOI 10.17487/RFC6755，2012 年 10 月，
<http://www.rfc-editor.org/info/rfc6755>。
[RFC6838] Freed, N., Klensin, J. 和 T. Hansen，
《媒体类型规范与注册过程》，
BCP 13，
RFC 6838，DOI 10.17487/RFC6838，2013 年 1 月，
<http://www.rfc-editor.org/info/rfc6838>。
Jones, et al. Standards Track [Page 24]
RFC 7519 JSON Web Token (JWT) May 2015
[SWT] Hardt, D. 和 Y. Goland，
《Simple Web Token（SWT）》，版本 0.9.5.1，
2009 年 11 月，
<http://msdn.microsoft.com/en-us/
library/windowsazure/hh781551.aspx>。
[W3C.CR-xml11-20060816]
Cowan, J.，《可扩展标记语言（XML）1.1（第二版）》，
万维网联盟推荐标准 REC-xml11-20060816，
2006 年 8 月，
<http://www.w3.org/TR/2006/REC-xml11-20060816>。
[W3C.REC-xml-c14n-20010315]
Boyer, J.，《规范化 XML 版本 1.0》，
万维网联盟推荐标准 REC-xml-c14n-20010315，
2001 年 3 月，
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>。
Jones, et al. Standards Track [Page 25]
RFC 7519 JSON Web Token (JWT) May 2015
附录 A. JWT 示例
本节包含 JWT 的示例。有关其他 JWT 示例，请参见本文档的
第 6.1 节以及 [JWS] 的附录 A.1 - A.3。
A.1. 加密 JWT 示例
本示例使用 RSAES-PKCS1-v1_5 和 AES_128_CBC_HMAC_SHA_256，
将 第 3.1 节中使用的相同声明加密给接收方。
以下示例 JOSE 头部声明：
o 内容加密密钥使用 RSAES-PKCS1-v1_5 算法加密给接收方，
以生成 JWE 加密密钥。
o 对明文执行经过认证的加密，使用 AES_128_CBC_HMAC_SHA_256
算法生成 JWE 密文和 JWE 认证标签。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
除了使用 第 3.1 节中 JWT 声明集的 UTF-8
表示形式的八位字节作为明文值之外，
此 JWT 的计算方式与 [JWE] 的
附录 A.2 中的 JWE 计算方式完全相同，
包括所使用的密钥。
本示例的最终结果（仅为了显示目的而插入换行）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0.
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima
sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ.
AxY8DCtDaGlsbGljb3RoZQ.
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8.
fiK51VwhsxJ-siBMR-YFiA
A.2. 嵌套 JWT 示例
本示例展示了如何将 JWT 作为 JWE 或 JWS 的有效载荷来创建嵌套 JWT。
在此情况下，JWT 声明集首先被签名，然后再进行加密。
Jones, et al. Standards Track [Page 26]
RFC 7519 JSON Web Token (JWT) May 2015
内部签名的 JWT 与 [JWS] 的
附录 A.2 中的示例完全相同。
因此，此处不再重复其计算过程。
然后，本示例使用 RSAES-PKCS1-v1_5 和
AES_128_CBC_HMAC_SHA_256 将该内部 JWT 加密给接收方。
以下示例 JOSE 头部声明：
o 内容加密密钥使用 RSAES-PKCS1-v1_5 算法加密给接收方，
以生成 JWE 加密密钥。
o 对明文执行经过认证的加密，使用 AES_128_CBC_HMAC_SHA_256
算法生成 JWE 密文和 JWE 认证标签。
o 明文本身是一个 JWT。
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
对 JOSE 头部的 UTF-8 表示形式的八位字节进行 base64url 编码，
可得到如下编码后的 JOSE 头部值：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
此 JWT 的计算方式与 [JWE] 的
附录 A.2 中的 JWE 计算方式相同，
不同之处在于使用了不同的 JOSE 头部、明文、
JWE 初始化向量以及内容加密密钥值。（所使用的 RSA 密钥相同。）
所使用的明文是 [JWS] 的
附录 A.2.1 末尾所示 JWT 的 ASCII
[RFC20] 表示形式的八位字节
（移除了所有空白和换行），其长度为 458 个八位字节。
所使用的 JWE 初始化向量值（采用 JSON 数组表示法）为：
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53,
50]
本示例使用以下 base64url 编码值表示的内容加密密钥：
GawgguFyGrWKav7AX4VKUg
Jones, et al. Standards Track [Page 27]
RFC 7519 JSON Web Token (JWT) May 2015
此嵌套 JWT 的最终结果（仅为了显示目的而插入换行）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldU
In0.
g_hEwksO1Ax8Qn7HoN-BVeBoa8FXe0kpyk_XdcSmxvcM5_P296JXXtoHISr_DD_M
qewaQSH4dZOQHoUgKLeFly-9RI11TG-_Ge1bZFazBPwKC5lJ6OLANLMd0QSL4fYE
b9ERe-epKYE3xb2jfY1AltHqBO-PM6j23Guj2yDKnFv6WO72tteVzm_2n17SBFvh
DuR9a2nHTE67pe0XGBUS_TK7ecA-iVq5COeVdJR4U4VZGGlxRGPLRHvolVLEHx6D
YyLpw30Ay9R6d68YCLi9FYTq3hIXPK_-dmPlOUlKvPr1GgJzRoeC9G5qCvdcHWsq
JGTO_z3Wfo5zsqwkxruxwA.
UmVkbW9uZCBXQSA5ODA1Mg.
VwHERHPvCNcHHpTjkoigx3_ExK0Qc71RMEParpatm0X_qpg-w8kozSjfNIPPXiTB
BLXR65CIPkFqz4l1Ae9w_uowKiwyi9acgVztAi-pSL8GQSXnaamh9kX1mdh3M_TT
-FZGQFQsFhu0Z72gJKGdfGE-OE7hS1zuBD5oEUfk0Dmb0VzWEzpxxiSSBbBAzP10
l56pPfAtrjEYw-7ygeMkwBl6Z_mLS6w6xUgKlvW6ULmkV-uLC4FUiyKECK4e3WZY
Kw1bpgIqGYsw2v_grHjszJZ-_I5uM-9RA8ycX9KqPRp9gc6pXmoU_-27ATs9XCvr
ZXUtK2902AUzqpeEUJYjWWxSNsS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb2
8Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe_nNJgNliWtWpJ_ebuOpE
l8jdhehdccnRMIwAmU1n7SPkmhIl1HlSOpvcvDfhUN5wuqU955vOBvfkBOh5A11U
zBuo2WlgZ6hYi9-e3w29bR0C2-pp3jbqxEDw3iWaf2dc5b-LnR0FEYXvI_tYk5rd
_J9N0mg0tQ6RbpxNEMNoA9QWk5lgdPvbh9BaO195abQ.
AVO9iT5AV4CzvDJCdhSFlQ
附录 B. JWT 与 SAML 断言之间的关系
安全断言标记语言（SAML）2.0
[OASIS.saml-core-2.0-os] 提供了一种创建安全令牌的标准，
其表达能力和安全选项均多于 JWT 所支持的内容。
然而，这种灵活性和表达能力的代价是体积和复杂性。
SAML 对 XML
[W3C.CR-xml11-20060816] 和
XML 数字签名（DSIG）
[RFC3275]
的使用增加了 SAML 断言的体积；
而对 XML，尤其是 XML 规范化
[W3C.REC-xml-c14n-20010315]
的使用则增加了其复杂性。
JWT 的设计目标是提供一种简单的安全令牌格式，
其体积足够小，可以放入 HTTP 头部和 URI 中的查询参数。
为此，JWT 采用了比 SAML 简单得多的令牌模型，
并使用 JSON
[RFC7159]
对象编码语法。
它还支持使用消息认证码（MAC）以及数字签名来保护令牌，
且所采用的格式比 XML DSIG 更小（但灵活性也更低）。
因此，虽然 JWT 可以完成 SAML 断言所能完成的一些事情，
但 JWT 并非旨在作为 SAML 断言的完整替代方案，
而是用于在实现简便性或紧凑性成为考量因素时的一种令牌格式。
Jones, et al. Standards Track [Page 28]
RFC 7519 JSON Web Token (JWT) May 2015
SAML 断言始终是某个实体关于某个主体所作出的陈述。
JWT 通常也以相同的方式使用，
其中作出陈述的实体由 “iss”（发行者）声明表示，
而主体由 “sub”（主体）声明表示。
然而，由于这些声明是可选的，
因此也允许对 JWT 格式进行其他用途的使用。
附录 C. JWT 与简单 Web 令牌（SWT）之间的关系
JWT 和 SWT
[SWT] 在本质上都支持在应用之间传递一组声明。
对于 SWT，声明名称和值均为字符串。
对于 JWT，虽然声明名称是字符串，
但声明值可以是任意 JSON 类型。
这两种令牌类型都为其内容提供了密码学保护：
SWT 使用 HMAC SHA-256，
而 JWT 则可以选择多种算法，
包括签名、MAC 和加密算法。
Acknowledgements
作者确认，JWT 的设计有意受到了 SWT
[SWT] 的设计和简洁性的影响，
以及 Dick Hardt 在 OpenID 社区中讨论的
JSON 令牌相关思想的启发。
用于对 JSON 内容进行签名的解决方案此前已在
Magic Signatures
[MagicSignatures]、
JSON Simple Sign
[JSS] 以及
Canvas Applications
[CanvasApp] 中进行过探索，
这些方案均对本文档产生了影响。
本规范是 OAuth 工作组的成果，
该工作组包含数十名积极且敬业的参与者。
尤其是以下个人提供了想法、反馈和措辞，
对本规范的形成产生了影响：
Dirk Balfanz, Richard Barnes, Brian Campbell, Alissa Cooper, Breno de
Medeiros, Stephen Farrell, Yaron Y. Goland, Dick Hardt, Joe
Hildebrand, Jeff Hodges, Edmund Jay, Warren Kumari, Ben Laurie, Barry
Leiba, Ted Lemon, James Manger, Prateek Mishra, Kathleen Moriarty,
Tony Nadalin, Axel Nennker, John Panzer, Emmanuel Raviart, David
Recordon, Eric Rescorla, Jim Schaad, Paul Tarjan, Hannes Tschofenig,
Sean Turner, and Tom Yu.
Hannes Tschofenig 和 Derek Atkins 担任了 OAuth 工作组主席，
而 Sean Turner、Stephen Farrell 以及 Kathleen Moriarty
在本规范制定期间担任了安全领域主任。
Jones, et al. Standards Track [Page 29]
RFC 7519 JSON Web Token (JWT) May 2015
Authors' Addresses
Michael B. Jones
Microsoft
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley
Ping Identity
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Nat Sakimura
Nomura Research Institute
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Jones, et al. Standards Track [Page 30]