分类：jwt| 发布时间：2025-01-08 14:32:00
原文：rfc7519
JSON Web Token（JWT）是一种紧凑的、URL安全的方式，用于表示在两方之间传递的声明。 JWT中的声明被编码为一个JSON对象，该对象用作JSON Web签名（JWS）结构的有效载荷，或者用作JSON Web加密（JWE）结构的明文，从而使得这些声明可以通过数字签名或通过消息认证码（MAC）进行完整性保护，并且/或者被加密。
这是一个互联网标准跟踪文档。
本文档是互联网工程任务组（IETF）的一项成果，代表了IETF社区的共识。它已接受公开审查，并已获得互联网工程指导组（IESG）的批准发布。 有关互联网标准的更多信息，请参见 RFC 5741的第2节。
关于本文件的当前状态、任何勘误以及如何提供反馈的信息，可以在以下网址获取：http://www.rfc-editor.org/info/rfc7519。
版权（c）2015 IETF Trust 及文档作者所列的人员。版权所有。
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.
本文件受 BCP 78 及 IETF Trust 关于 IETF 文档的法律条款（http://trustee.ietf.org/license-info）约束，自本文件发布之日生效。 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。 从本文件中提取的代码组件必须包含简化 BSD 许可证文本，具体如《信托法律条款》第4.e节所述，并按简化 BSD 许可证的描述提供。
JSON Web Token（JWT）是一种紧凑的声明表示格式，旨在用于空间受限的环境，例如 HTTP 授权头和 URI 查询参数。 JWT编码了要传输的声明，这些声明作为JSON RFC7159 对象被使用，作为JSON Web签名（JWS）JWS 结构的有效载荷或 JSON Web 加密（JWE）JWE 结构的明文，从而使得这些声明可以被数字签名或通过消息认证码（MAC）进行完整性保护，并且/或者被加密。 JWT 始终使用 JWS 紧凑序列化格式或 JWE 紧凑序列化格式进行表示。
JWT的建议发音与英语单词“jot”相同。
本文件中的关键词 “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“NOT RECOMMENDED”、“MAY” 和 “OPTIONAL” 应按照 RFC 2119 中用于指示要求级别的关键词中的描述进行解释。 该解释仅应在这些术语以全大写字母出现时应用。
术语“JSON Web签名（JWS）”、“Base64url编码”、“头部参数”、“JOSE头部”、“JWS紧凑序列化”、“JWS有效载荷”、“JWS签名”和“未加密JWS”由JWS规范 JWS 定义。
术语 “JSON Web加密（JWE）”、“内容加密密钥（CEK）”、“JWE紧凑序列化”、“JWE加密密钥”和“JWE初始化向量”由JWE规范 JWE 定义。
术语 “密文”、“数字签名”、“消息认证码（MAC）” 和 “明文” 由《互联网安全词汇表，第2版》 RFC4949 定义。
这些术语由本规范定义：
JWT 表示一组声明，作为一个JSON对象被编码在 JWS 和/或 JWE 结构中。 这个 JSON 对象就是 JWT 声明集（JWT Claims Set）。 根据 RFC 7159第4节 RFC7159，JSON对象由零个或多个名称/值对（或成员）组成，其中名称是字符串，值是任意 JSON 值。 这些成员就是 JWT 所表示的声明。 该 JSON 对象可以在任何 JSON 值或结构字符之前或之后包含空白字符和/或换行符，符合 RFC 7159第2节 的规定 RFC7159。
JWT声明集中的成员名称称为声明名称（Claim Names），对应的值称为声明值（Claim Values）。
JOSE 头部的内容描述了应用于 JWT 声明集的加密操作。 如果 JOSE 头部用于 JWS，则 JWT 被表示为 JWS，声明通过数字签名或消息认证码（MAC）保护，JWT 声明集是 JWS 有效载荷。 如果 JOSE 头部用于 JWE，则 JWT 被表示为 JWE，声明被加密，JWT 声明集是 JWE 加密的明文。 JWT 还可以被封装在另一个 JWE 或 JWS 结构中，形成嵌套 JWT，从而实现嵌套签名和加密操作。
JWT 被表示为由点（'.'）字符分隔的URL安全部分的序列。 每个部分包含一个 base64url 编码的值。 JWT 的部分数目取决于最终 JWS 的表示，使用 JWS 紧凑序列化或 JWE 紧凑序列化表示。
以下示例中的 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表示对应的字节如下：
[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]
对 JOSE 头部 UTF-8 表示的字节进行 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]
对JWS有效载荷进行Base64url编码，得到这个编码后的JWS有效载荷（这里包含的换行符，只是为了更好展示）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
使用 HMAC SHA-256 算法计算编码后的 JOSE 头部和编码后的 JWS 有效载荷的消息认证码（MAC），并按照 JWS 中规定的方式对 HMAC 值进行 Base64url 编码，得到以下编码后的JWS签名：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
按照这个顺序将这些编码后的部分拼接起来，并在各部分之间用点（'.'）字符分隔，得到完整的JWT（这里包含的换行符，只是为了更好展示）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
此计算的详细说明请参见 JWS 的 附录A.1。 有关加密 JWT 的示例，请参见 附录A.1。
JWT 声明集表示一个JSON对象，其成员是 JWT 传递的声明。 JWT 声明集中的声明名称（Claim Names）必须是唯一的；JWT解析器必须拒绝包含重复声明名称的 JWT，或者使用一个只返回词法上最后一个重复成员名称的JSON解析器，具体参见 ECMAScript 5.1 第15.12节（"The JSON Object"）ECMAScript。
一个 JWT 被认为有效所必须包含的声明集是依赖于上下文的，超出了本规范的范围。 JWT 的特定应用将要求实现以特定方式理解和处理一些声明。 然而，在没有这些要求的情况下，所有实现不理解的声明必须被忽略。
JWT 声明名称有三类：已注册声明名称（Registered Claim Names）、公共声明名称（Public Claim Names）和私有声明名称（Private Claim Names）。
以下声明名称已在 IANA 的 “JSON Web Token声明” 注册表中注册，该注册表由第10.1节建立。 下面定义的声明都不是在所有情况下必须使用或实现的，而是为一组有用的、可互操作的声明提供一个起点。 使用 JWT 的应用程序应定义它们使用的特定声明以及何时需要这些声明或这些声明是否可选。 所有名称都很简短，因为 JWT 的核心目标之一是使表示尽可能简洁。
“iss”（issuer，发行者）声明标识发行JWT的主体。 该声明的处理通常是应用程序特定的。 “iss”值是一个区分大小写的字符串，包含一个StringOrURI值。 使用此声明是可选(OPTIONAL)的。
“sub”（subject，主题）声明标识JWT的主题主体。 JWT 中的声明通常是关于主题的陈述。 主题值必须(MUST)在发行者的上下文中局部唯一，或者是全局唯一的。 该声明的处理通常是应用程序特定的。 “sub”值是一个区分大小写的字符串，包含一个 StringOrURI 值。 使用此声明是可选(OPTIONAL)的。
“aud”（audience，受众）声明标识 JWT 的接收者。 每个计划处理 JWT 的主体必须(MUST)在受众声明中标识自己。 如果处理该声明的主体没有在“aud”声明中标识自己，当该声明存在时，JWT 必须被拒绝。 一般情况下，“aud”值是一个区分大小写的字符串数组，每个字符串包含一个 StringOrURI 值。 在 JWT 只有一个受众的特殊情况下，“aud”值可以是一个包含 StringOrURI 值的单个区分大小写的字符串。 受众值的解释通常是应用程序特定的。 使用此声明是可选(OPTIONAL)的。
“exp”（expiration time，过期时间）声明标识 JWT 不能在其过期时间之后接受进行处理。 处理 “exp” 声明时，当前日期/时间必须早于 “exp” 声明中列出的过期日期/时间。
实现者可以(MAY)提供一些小的宽限时间，通常不超过几分钟，以考虑时钟偏差。 其值必须(MUST)是包含NumericDate值的数字。 使用此声明是可选(OPTIONAL)的。
“nbf”（not before，不可用前）声明标识在此时间之前，JWT 不能被接受(MUST NOT)进行处理。 处理“nbf”声明时，当前日期/时间必须(MUST)晚于或等于“nbf”声明中列出的不可用前日期/时间。 实现者可以(MAY)提供一些小的宽限时间，通常不超过几分钟，以考虑时钟偏差。 其值必须(MUST)是一个包含NumericDate值的数字。 使用此声明是可选(OPTIONAL)的。
“iat”（issued at，发行时间）声明标识 JWT 的发行时间。 此声明可用于确定 JWT 的年龄。 其值必须(MUST)是一个包含NumericDate值的数字。 使用此声明是可选(OPTIONAL)的。
“jti”（JWT ID）声明为 JWT 提供一个唯一的标识符。 标识符值必须(MUST)以一种确保几乎没有概率将相同值意外分配给不同数据对象的方式进行分配； 如果应用程序使用多个发行者，必须(MUST)防止不同发行者产生的值发生冲突。 “jti”声明可用于防止JWT被重放。“jti”值是一个区分大小写的字符串。 使用此声明是可选(OPTIONAL)的。
声明名称可以由使用 JWT 的人员随意定义。 然而，为了防止冲突，任何新的声明名称应该要么在由 第10.1节 建立的IANA“JSON Web Token声明”注册表中注册，要么是一个公共名称：一个包含冲突防止名称的值。 在每种情况下，定义名称或值的人需要采取合理的预防措施，确保他们对用于定义声明名称的命名空间部分有控制权。
JWT 的生产者和消费者可以(MAY)同意使用私有声明名称：即那些既不是已注册声明名称 第4.1节 也不是公共声明名称 第4.2节 的名称。 与公共声明名称不同，私有声明名称容易发生冲突，因此应谨慎使用。
对于 JWT 对象，JOSE 头部表示的 JSON 对象的成员描述应用于 JWT 的加密操作，并可选地包含JWT的其他属性。 根据 JWT 是 JWS 还是 JWE，适用相应的 JOSE 头部值规则。
本规范进一步规定了在 JWT 是 JWS 和 JWE 两种情况下，以下头部参数的使用。
由 JWS 和 JWE 定义的 "typ"（类型）头部参数用于JWT应用程序声明该完整JWT的媒体类型 IANA.MediaTypes。 当应用程序数据结构中可能包含不仅仅是 JWT 的其他值时，JWT 应用程序使用此参数来区分可能存在的不同类型的对象；如果已知对象是JWT，通常应用程序不会使用此参数。 此参数会被JWT实现忽略；任何对该参数的处理都由 JWT 应用程序执行。 如果存在，推荐其值为 "JWT"，以表明该对象是一个JWT。 尽管媒体类型名称不区分大小写，为了与旧版实现兼容，推荐(RECOMMENDED)始终使用大写字符拼写 "JWT"。 使用此头部参数是可选(OPTIONAL)的。
由 JWS 和 JWE "cty"（内容类型）头部参数用于本规范中传达关于JWT的结构信息。
在未使用嵌套签名或加密操作的常规情况下，不推荐(NOT RECOMMENDED)使用此头部参数。 在使用嵌套签名或加密的情况下，必须(MUST)包含此头部参数；在这种情况下，值必须(MUST)为 "JWT"，以表明该 JWT 中携带了一个嵌套JWT。 尽管媒体类型名称不区分大小写，为了与旧版实现兼容，推荐(RECOMMENDED)始终使用大写字符拼写 "JWT"。 有关嵌套 JWT 的示例，请参见 附录A.2。
在某些使用加密 JWT 的应用程序中，拥有一些声明的未加密表示是有用的。 例如，这可以用于应用程序处理规则，以确定在解密之前是否以及如何处理 JWT。
本规范允许将 JWT 声明集中的声明根据应用程序需要，作为头部参数复制到 JWE 类型的 JWT 中。 如果存在这些复制的声明，接收它们的应用程序应验证其值是否相同，除非应用程序定义了这些声明的其他特定处理规则。 确保仅将可以以未加密方式传输的声明作为头部参数值复制到JWT中的责任由应用程序承担。
本规范的 第10.4.1节 注册了 "iss"（发行者）、"sub"（主题）和"aud"（受众）头部参数名称，以便在需要的加密 JWT 中提供这些声明的未加密副本。 其他规范可以(MAY)根据需要，将已注册的声明名称注册为头部参数名称。
为了支持那些 JWT 内容通过JWT内以外的方式（例如包含JWT的一个数据结构上的签名）进行保护的使用场景，JWT 可以在没有签名和/或加密的情况下创建。 未加密的 JWT 是一个 JWS，其 "alg" 头部参数值为 "none"，并且其 JWS 签名值为空字符串，如 JWA 规范中所定义；它是一个未加密的 JWS，JWT 声明集作为其 JWS 有效载荷。
以下示例JOSE头部声明编码的对象是未加密JWT（Unsecured JWT）：
以下是一个声明了编码的对象是未加密的 JWT 的 JOSE 头
{"alg":"none"}
对 JOSE 头部的 UTF-8 表示形式的字节数组进行 Base64url 编码，得到以下编码后的 JOSE 头部值：
eyJhbGciOiJub25lIn0
以下是一个 JWT 声明集示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
对 JWT 声明集的 UTF-8 表示形式的字节数组进行 Base64url 编码，得到以下结果（这里包含的换行符，只是为了更好展示）
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
编码后的 JWS 签名为空字符串。
按照这个顺序将这些编码后的部分拼接起来，并在各部分之间用点（'.'）字符分隔，得到完整的JWT（这里包含的换行符，只是为了更好展示）：
eyJhbGciOiJub25lIn0
.
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt
cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
.
为了创建 JWT，执行以下步骤。 对于没有输入输出依赖关系的步骤，执行顺序不影响结果。
在验证 JWT 时，执行以下步骤。 对于没有输入输出依赖关系的步骤，执行顺序不影响结果。 如果任何步骤失败，则 JWT 必须(MUST)被拒绝——即应用程序应将其视为无效输入。
最后，请注意，决定在特定上下文中可以使用哪些算法是由应用程序来决定的。 即使 JWT 能够成功验证，如果 JWT 中使用的算法对应用程序不可接受，则应用程序应当(SHOULD)拒绝该 JWT。
处理 JWT 不可避免地需要将已知字符串与 JSON 对象中的成员和值进行比较。 例如，在检查算法时，将使用Unicode UNICODE 字符串编码“alg”与 JOSE 头部中的成员名称进行比较，以确定是否有匹配的头部参数名称。
JSON 成员名称比较的规则在 RFC 7159 的第8.3节 中进行了描述。 由于执行的字符串比较操作仅包括相等和不等，因此相同的规则可以用于将成员名称和成员值与已知字符串进行比较。
除非成员的定义明确指出该成员值应使用不同的比较规则，否则必须(MUST) 使用这些比较规则进行所有 JSON 字符串比较。 在本规范中，只有“typ”和“cty”成员值不使用这些比较规则。
某些应用程序可能会在区分大小写的值中包含不区分大小写的信息，例如将DNS名称作为“iss”（发行者）声明值的一部分。 在这些情况下，如果多个方需要生成相同的值以便进行比较，应用程序可能需要定义一种约定来规范表示不区分大小写部分的大小写方式，例如将其转换为小写。 （然而，如果所有其他方直接消费生成方原封不动发出的值，而不试图与独立生成的值进行比较，那么生成方使用的大小写形式就无关紧要。）
本节定义了本规范中必须实现的算法和特性。 使用本规范的应用程序可以对其使用的实现施加额外的要求。 例如，一个应用程序可能要求支持加密 JWT 和嵌套 JWT，而另一个应用程序可能要求支持使用 P-256 曲线和 SHA-256 哈希算法（“ES256”）的椭圆曲线数字签名算法（ECDSA）来签署 JWT。
在 JSON Web 算法 JWA 中指定的签名和 MAC 算法中，符合规范的 JWT 实现必须实现 HMAC SHA-256（“HS256”）和 “none”。 建议实现还支持使用 SHA-256 哈希算法的 RSASSA-PKCS1-v1_5（“RS256”）和使用 P-256 曲线和 SHA-256 哈希算法的 ECDSA（“ES256”）。 支持其他算法和密钥大小是可选(OPTIONAL)的。
对加密 JWT 的支持是可选(OPTIONAL)的。 如果实现提供加密功能，在 JWA 中指定的加密算法中，符合规范的实现必须实现 RSAES-PKCS1-v1_5，2048 位密钥（“RSA1_5”）、使用 128 位和 256 位密钥的 AES 密钥封装（“A128KW”和“A256KW”）以及使用 AES-CBC 和 HMAC SHA-2 的复合认证加密算法（“A128CBC-HS256”和“A256CBC-HS512”）。 建议(RECOMMENDED) 实现还支持使用 Elliptic Curve Diffie-Hellman Ephemeral Static（ECDH-ES）来协商用于封装内容加密密钥的密钥（“ECDH-ES+A128KW”和“ECDH-ES+A256KW”）以及使用128位和256位密钥的 AES Galois/Counter模式（GCM）（“A128GCM”和“A256GCM”）。 支持其他算法和密钥大小是可选(OPTIONAL)的。
对嵌套 JWT 的支持是可选(OPTIONAL)的。
本规范注册了 URN "urn:ietf:params:oauth:token-type:jwt"，供那些使用 URI（而不是,例如媒体类型）声明内容类型的应用程序使用，以指示所引用的内容是 JWT。
本节建立了 IANA 的 “JSON Web Token Claims”注册表，用于 JWT 声明名称。 该注册表记录声明名称及其定义的规范的参考。 此节注册了 4.1节 中定义的声明名称。
值的注册基于 “规范要求”RFC5226，在 jwt-reg-review@ietf.org 邮件列表上经过三周的审查期，并在一个或多个指定专家的建议下进行。 然而，为了允许在发布之前分配值，指定专家可以在确认该规范将发布后批准注册。
发送至邮件列表以供审查的注册请求应使用适当的主题（例如：“请求注册声明：example”）。
在审查期内，指定专家将批准或拒绝注册请求，并将这一决定传达给审查列表和 IANA。 拒绝应包括解释，并在适用时提供如何使请求成功的建议。 对于长于21天未做决定的注册请求，可以将其提交给 IESG（使用iesg@ietf.org邮件列表）以供解决。
指定专家应考虑的标准包括：提议的注册是否重复了现有功能，是否可能具有广泛的适用性，或仅对单一应用程序有用，以及注册描述是否清晰。
IANA 必须仅接受指定专家的注册表更新，并应将所有注册请求引导到审查邮件列表。
建议任命多位指定专家，这些专家能够代表使用本规范的不同应用程序的观点，以便对注册决策进行广泛知情的审查。 如果某个注册决策可能被认为会使某位专家产生利益冲突，该专家应将决策的判断权交由其他专家。
o Claim Name: "iss" o Claim Description: Issuer o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7519 o Claim Name: "sub" o Claim Description: Subject o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7519 o Claim Name: "aud" o Claim Description: Audience o Change Controller: IESG o Specification Document(s): Section 4.1.3 of RFC 7519 o Claim Name: "exp" o Claim Description: Expiration Time o Change Controller: IESG o Specification Document(s): Section 4.1.4 of RFC 7519 o Claim Name: "nbf" o Claim Description: Not Before o Change Controller: IESG o Specification Document(s): Section 4.1.5 of RFC 7519 o Claim Name: "iat" o Claim Description: Issued At o Change Controller: IESG o Specification Document(s): Section 4.1.6 of RFC 7519 o Claim Name: "jti" o Claim Description: JWT ID o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7519
本节将在 IANA 的 “OAuth URI” 注册表中注册值“token-type:jwt”，该注册表由《An IETF URN Sub-Namespace for OAuth》RFC6755 建立，可用于指示内容是JWT。
o URN: urn:ietf:params:oauth:token-type:jwt o Common Name: JSON Web Token (JWT) Token Type o Change Controller: IESG o Specification Document(s): RFC 7519
本节将在 “IANA媒体类型”注册表 IANA.MediaTypes 中注册 “application/jwt” 媒体类型 RFC2046，按照RFC 6838 RFC6838 中描述的方式进行注册，该媒体类型可用于指示内容是 JWT。
o 类型名称：application o 子类型名称：jwt o 必需参数：无 o 可选参数：无 o 编码考虑：8位；JWT值被编码为一系列经过base64url编码的值（其中一些可能为空字符串），由句点（.）字符分隔。 o 安全考虑：请参见 RFC 7519 中的“安全考虑”部分 o 互操作性考虑：无 o 发布规范：RFC 7519 o 使用此媒体类型的应用程序：OpenID Connect、Mozilla Persona、Salesforce、Google、Android、Windows Azure、Amazon Web Services及其他众多应用 o 片段标识符考虑：无 o 附加信息：
魔术数字：无
文件扩展名：无
Macintosh文件类型代码：无
o 联系人及电子邮件地址：Michael B. Jones，mbj@microsoft.com o 预期用途：常见 o 使用限制：无 o 作者：Michael B. Jones，mbj@microsoft.com o 变更控制者：IESG o 临时注册？：否
本节将注册 第4.1节 中定义的特定声明名称，注册到由 JWS 建立的 IANA “JSON Web 签名和加密头部参数” 注册表中，用于在 JWS 中作为头部参数复用的声明，详见第 5.3节。
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): Section 4.1.1 of RFC 7519 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): Section 4.1.1 of RFC 7519 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): Section 4.1.1 of RFC 7519
JWT/JWS/JWE/JWK 代理必须解决与任何加密应用程序相关的所有安全问题。 这些问题包括保护用户的非对称私钥和对称密钥，并采取应对各种攻击的措施。
JWS 规范中的所有安全注意事项也适用于 JWT，使用加密时的 JWE 安全注意事项也是如此。 特别是，JWS 的 第 10.12 节（“JSON 安全注意事项”）和第 10.13 节（“Unicode 比较安全注意事项”）同样适用于 JWT 声明集，就像它们适用于 JOSE 标头一样。
除非 JWT 的内容已通过加密保护并与信任决策所需的上下文绑定，否则无法在信任决策中依赖其内容。 特别是，用于签署和/或加密 JWT 的密钥通常需要可验证地处于被确定为 JWT 发行者的一方的控制之下。
虽然从语法上讲，嵌套 JWT 的签名和加密操作可以按任何顺序应用，但如果签名和加密都是必需的，则通常生产者应该先对消息进行签名，然后对结果进行加密（从而加密签名）。 这可以防止签名被剥离的攻击，只留下加密的消息，并为签名者提供隐私。 此外，在许多司法管辖区，加密文本上的签名不被视为有效。
请注意，底层 JWS 和 JWE 规范已经解决了与签名和加密操作顺序相关的安全问题的潜在担忧；特别是，由于 JWE 仅支持使用经过身份验证的加密算法，因此在许多情况下适用的关于可能需要在加密后签名的加密问题不适用于本规范。
JWT 可能包含隐私敏感信息。 在这种情况下，必须采取措施防止向非预期方泄露此信息。 实现此目的的一种方法是使用加密的 JWT 并对接收者进行身份验证。 另一种方法是确保包含未加密隐私敏感信息的 JWT 仅使用支持端点身份验证的加密协议（例如传输层安全性 (TLS)）进行传输。 从 JWT 中删除隐私敏感信息是减少隐私问题的最简单方法。
[ECMAScript] Ecma International, "ECMAScript Language Specification, 5.1 Edition", ECMA Standard 262, June 2011, <http://www.ecma-international.org/ecma-262/5.1/ECMA-262.pdf>.
[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC20] Cerf, V., "ASCII format for Network Interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <http://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[CanvasApp] Facebook, "Canvas Applications", 2010, <http://developers.facebook.com/docs/authentication/canvas>.
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", September 2010, <http://jsonenc.info/jss/1.0/>.
[MagicSignatures] Panzer, J., Ed., Laurie, B., and D. Balfanz, "Magic Signatures", January 2011, <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>.
[OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core-2.0-os, March 2005, <http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[POSIX.1] IEEE, "The Open Group Base Specifications Issue 7", IEEE Std 1003.1, 2013 Edition, 2013, <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15>.
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, DOI 10.17487/RFC3275, March 2002, <http://www.rfc-editor.org/info/rfc3275>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <http://www.rfc-editor.org/info/rfc6755>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[SWT] Hardt, D. and Y. Goland, "Simple Web Token (SWT)", Version 0.9.5.1, November 2009, <http://msdn.microsoft.com/en-us/library/windowsazure/hh781551.aspx>.
[W3C.CR-xml11-20060816] Cowan, J., "Extensible Markup Language (XML) 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml11-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml11-20060816>.
[W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
本节包含 JWT 示例。 有关其他 JWT 示例，请参阅本文档 第 6.1 节 和 JWS 附录 A.1 - A.3。
此示例使用 RSAES-PKCS1-v1_5 和 AES_128_CBC_HMAC_SHA_256 将与 第 3.1 节 中使用的相同声明加密给接收者。
以下示例 JOSE 标头声明：
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
除了使用 第 3.1 节 中 JWT 声明集的 UTF-8 表示的字节数组作为明文外，此 JWT 的计算与 JWE 附录 A.2 中的计算相同，包括使用的密钥。
本例中的最终结果（仅用于显示目的而带有换行符）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0。
QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM
ONFABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG
TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMUjPyYwEsRhDhzjAD26ima
SOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52
YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a
1rZgN5TiysnmzTROF869lQ。
AxY8DCtDaGlsbGljb3RoZQ。
MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM
HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8。
fiK51VwhsxJ-siBMR-YFiA
此示例展示了如何使用 JWT 作为 JWE 或 JWS 的有效负载来创建嵌套 JWT。 在本例中，JWT 声明集首先被签名，然后被加密。
内部签名的 JWT 与 JWS 附录 A.2 中的示例相同。 因此，这里不再重复其计算。 然后，此示例使用 RSAES-PKCS1-v1_5 和 AES_128_CBC_HMAC_SHA_256 将此内部 JWT 加密给接收者。
以下示例 JOSE 标头声明：
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
使用 Base64url 编码 JOSE Header 的 UTF-8 表示的字节数组，可生成此编码的 JOSE Header 值：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
此 JWT 的计算与 JWE 附录 A.2 的计算相同，只是使用了不同的 JOSE Header、纯文本、JWE 初始化向量和内容加密密钥值。 （使用的 RSA 密钥相同。）
JWT 使用的明文是 JWS 附录 A.2.1 末尾的 JWS 的 ASCII RFC20 表示的字节数组（删除所有空格和换行符），这是一个 458 个字节的序列。
使用的 JWE 初始化向量值（使用 JSON 数组表示法）是：
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
此示例使用以下 base64url 编码值表示的内容加密密钥：
GawgguFyGrWKav7AX4VKUg
此嵌套 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
安全断言标记语言 (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 旨在提供一种简单的安全令牌格式，该格式足够小，可以放入 URI 中的 HTTP 标头和查询参数中。 它通过支持比 SAML 更简单的令牌模型和使用 JSON RFC7159 对象编码语法来实现这一点。 它还支持使用消息认证代码 (MAC) 保护令牌，并使用比 XML DSIG 更小（且灵活性更低）的格式保护数字签名。
因此，虽然 JWT 可以执行 SAML 断言的某些功能，但 JWT 并非旨在完全替代 SAML 断言，而是在考虑易于实施或紧凑性时使用的令牌格式。
JWT 和 SWT 的核心都是允许在应用程序之间传递声明集。 对于 SWT，声明名称和声明值都是字符串。 对于 JWT，声明名称是字符串，而声明值可以是任何 JSON 类型。 这两种令牌类型都为其内容提供加密保护：SWT 采用 HMAC SHA-256，而 JWT 则提供多种算法选择，包括签名、MAC 和加密算法。
作者承认 JWT 的设计有意受到 SWT 的设计和简单性以及 Dick Hardt 在 OpenID 社区中讨论的 JSON 令牌想法的影响。
之前 Magic Signatures MagicSignatures、JSON Simple Sign JSS 和 Canvas Applications CanvasApp 探索了用于签署 JSON 内容的解决方案，所有这些解决方案都影响了本文档。
本规范是 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 和 Tom Yu。
Hannes Tschofenig 和 Derek Atkins 担任 OAuth 工作组主席，
Sean Turner、Stephen Farrell 和 Kathleen Moriarty 在本规范制定期间担任安全领域主管。
作者地址
Michael B. Jones Microsoft
电子邮件：mbj@microsoft.com URI：http://self-issued.info/
John Bradley Ping Identity
电子邮件：ve7jtb@ve7jtb.com URI：http://www.thread-safe.com/
Nat Sakimura Nomura Research Institute
电子邮件：n-sakimura@nri.co.jp URI：http://nat.sakimura.org/