Internet 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
Internet 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 Token (JWT)
JSON Web令牌（JWT）
Abstract
摘要
JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.
JSON Web令牌（JWT）是一种紧凑、URL安全的方法，用于表示双方之间要传输的声明。JWT中的声明被编码为JSON对象，该JSON对象用作JSON Web签名（JWS）结构的有效负载或JSON Web加密（JWE）结构的明文，使得声明能够通过消息认证码（MAC）和/或加密进行数字签名或完整性保护。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7519.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7519.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 6
3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Registered Claim Names . . . . . . . . . . . . . . . . . 9
4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . 9
4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . 9
4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9
4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . 10
4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . 10
4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . 10
4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10
5. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11
5.3. Replicating Claims as Header Parameters . . . . . . . . . 12
6. Unsecured JWTs . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Example Unsecured JWT . . . . . . . . . . . . . . . . . . 12
7. Creating and Validating JWTs . . . . . . . . . . . . . . . . 13
7.1. Creating a JWT . . . . . . . . . . . . . . . . . . . . . 13
7.2. Validating a JWT . . . . . . . . . . . . . . . . . . . . 14
7.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15
8. Implementation Requirements . . . . . . . . . . . . . . . . . 16
9. URI for Declaring that Content is a JWT . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
10.1.1. Registration Template . . . . . . . . . . . . . . . 18
10.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
10.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . 19
10.2.1. Registry Contents . . . . . . . . . . . . . . . . . 19
10.3. Media Type Registration . . . . . . . . . . . . . . . . 20
10.3.1. Registry Contents . . . . . . . . . . . . . . . . . 20
10.4. Header Parameter Names Registration . . . . . . . . . . 20
10.4.1. Registry Contents . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . 21
11.2. Signing and Encryption Order . . . . . . . . . . . . . . 21
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. JSON Web Token (JWT) Overview . . . . . . . . . . . . . . . . 6
3.1. Example JWT . . . . . . . . . . . . . . . . . . . . . . . 7
4. JWT Claims . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Registered Claim Names . . . . . . . . . . . . . . . . . 9
4.1.1. "iss" (Issuer) Claim . . . . . . . . . . . . . . . . 9
4.1.2. "sub" (Subject) Claim . . . . . . . . . . . . . . . . 9
4.1.3. "aud" (Audience) Claim . . . . . . . . . . . . . . . 9
4.1.4. "exp" (Expiration Time) Claim . . . . . . . . . . . . 9
4.1.5. "nbf" (Not Before) Claim . . . . . . . . . . . . . . 10
4.1.6. "iat" (Issued At) Claim . . . . . . . . . . . . . . . 10
4.1.7. "jti" (JWT ID) Claim . . . . . . . . . . . . . . . . 10
4.2. Public Claim Names . . . . . . . . . . . . . . . . . . . 10
4.3. Private Claim Names . . . . . . . . . . . . . . . . . . . 10
5. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. "typ" (Type) Header Parameter . . . . . . . . . . . . . . 11
5.2. "cty" (Content Type) Header Parameter . . . . . . . . . . 11
5.3. Replicating Claims as Header Parameters . . . . . . . . . 12
6. Unsecured JWTs . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Example Unsecured JWT . . . . . . . . . . . . . . . . . . 12
7. Creating and Validating JWTs . . . . . . . . . . . . . . . . 13
7.1. Creating a JWT . . . . . . . . . . . . . . . . . . . . . 13
7.2. Validating a JWT . . . . . . . . . . . . . . . . . . . . 14
7.3. String Comparison Rules . . . . . . . . . . . . . . . . . 15
8. Implementation Requirements . . . . . . . . . . . . . . . . . 16
9. URI for Declaring that Content is a JWT . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. JSON Web Token Claims Registry . . . . . . . . . . . . . 17
10.1.1. Registration Template . . . . . . . . . . . . . . . 18
10.1.2. Initial Registry Contents . . . . . . . . . . . . . 18
10.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt . . . . . . . . . . 19
10.2.1. Registry Contents . . . . . . . . . . . . . . . . . 19
10.3. Media Type Registration . . . . . . . . . . . . . . . . 20
10.3.1. Registry Contents . . . . . . . . . . . . . . . . . 20
10.4. Header Parameter Names Registration . . . . . . . . . . 20
10.4.1. Registry Contents . . . . . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11.1. Trust Decisions . . . . . . . . . . . . . . . . . . . . 21
11.2. Signing and Encryption Order . . . . . . . . . . . . . . 21
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 26
A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 26
A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . 26
Appendix B. Relationship of JWTs to SAML Assertions . . . . . . 28
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. JWT Examples . . . . . . . . . . . . . . . . . . . . 26
A.1. Example Encrypted JWT . . . . . . . . . . . . . . . . . . 26
A.2. Example Nested JWT . . . . . . . . . . . . . . . . . . . 26
Appendix B. Relationship of JWTs to SAML Assertions . . . . . . 28
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs) . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
JSON Web Token (JWT) is a compact claims representation format intended for space constrained environments such as HTTP Authorization headers and URI query parameters. JWTs encode claims to be transmitted as a JSON [RFC7159] object that is used as the payload of a JSON Web Signature (JWS) [JWS] structure or as the plaintext of a JSON Web Encryption (JWE) [JWE] structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. JWTs are always represented using the JWS Compact Serialization or the JWE Compact Serialization.
JSON Web令牌（JWT）是一种紧凑的声明表示格式，适用于空间受限的环境，如HTTP授权头和URI查询参数。JWTs将要作为JSON[RFC7159]对象传输的声明进行编码，该对象用作JSON Web签名（JWS）[JWS]结构的有效负载或JSON Web加密（JWE）[JWE]结构的明文，使声明能够通过消息认证码（MAC）和/或加密进行数字签名或完整性保护。JWT总是使用JWS紧凑序列化或JWE紧凑序列化来表示。
The suggested pronunciation of JWT is the same as the English word "jot".
JWT的建议发音与英语单词“jot”相同。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. The interpretation should only be applied when the terms appear in all capital letters.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。该解释仅适用于所有大写字母的术语。
The terms "JSON Web Signature (JWS)", "Base64url Encoding", "Header Parameter", "JOSE Header", "JWS Compact Serialization", "JWS Payload", "JWS Signature", and "Unsecured JWS" are defined by the JWS specification [JWS].
术语“JSON Web签名（JWS）”、“Base64url编码”、“头参数”、“JOSE头”、“JWS紧凑序列化”、“JWS有效负载”、“JWS签名”和“不安全JWS”由JWS规范[JWS]定义。
The terms "JSON Web Encryption (JWE)", "Content Encryption Key (CEK)", "JWE Compact Serialization", "JWE Encrypted Key", and "JWE Initialization Vector" are defined by the JWE specification [JWE].
术语“JSON Web加密（JWE）”、“内容加密密钥（CEK）”、“JWE压缩序列化”、“JWE加密密钥”和“JWE初始化向量”由JWE规范[JWE]定义。
The terms "Ciphertext", "Digital Signature", "Message Authentication Code (MAC)", and "Plaintext" are defined by the "Internet Security Glossary, Version 2" [RFC4949].
术语“密文”、“数字签名”、“消息认证码（MAC）”和“明文”由“互联网安全词汇表，版本2”[RFC4949]定义。
These terms are defined by this specification:
这些术语由本规范定义：
JSON Web Token (JWT) A string representing a set of claims as a JSON object that is encoded in a JWS or JWE, enabling the claims to be digitally signed or MACed and/or encrypted.
JSON Web Token（JWT）一个字符串，表示一组声明作为JSON对象，在JWS或JWE中编码，使声明能够进行数字签名、标记和/或加密。
JWT Claims Set A JSON object that contains the claims conveyed by the JWT.
JWT声明设置一个JSON对象，其中包含JWT传递的声明。
Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
声明关于某一主题的一条信息。索赔被表示为由索赔名称和索赔值组成的名称/值对。
Claim Name The name portion of a claim representation. A Claim Name is always a string.
索赔名称索赔陈述的名称部分。声明名称始终是字符串。
Claim Value The value portion of a claim representation. A Claim Value can be any JSON value.
索赔价值索赔表述的价值部分。声明值可以是任何JSON值。
Nested JWT A JWT in which nested signing and/or encryption are employed. In Nested JWTs, a JWT is used as the payload or plaintext value of an enclosing JWS or JWE structure, respectively.
嵌套JWT使用嵌套签名和/或加密的JWT。在嵌套JWT中，JWT分别用作封闭JWS或JWE结构的有效负载或明文值。
Unsecured JWT A JWT whose claims are not integrity protected or encrypted.
无担保JWT其索赔未得到完整性保护或加密的JWT。
Collision-Resistant Name A name in a namespace that enables names to be allocated in a manner such that they are highly unlikely to collide with other names. Examples of collision-resistant namespaces include: Domain Names, Object Identifiers (OIDs) as defined in the ITU-T X.660 and X.670 Recommendation series, and Universally Unique IDentifiers (UUIDs) [RFC4122]. When using an administratively delegated namespace, the definer of a name needs to take reasonable precautions to ensure they are in control of the portion of the namespace they use to define the name.
抗冲突名称命名空间中的名称，该名称允许以不太可能与其他名称冲突的方式分配名称。抗冲突名称空间的示例包括：域名、ITU-T X.660和X.670建议系列中定义的对象标识符（OID）以及通用唯一标识符（UUID）[RFC4122]。当使用管理委派的命名空间时，名称的定义者需要采取合理的预防措施，以确保他们能够控制用于定义名称的命名空间部分。
StringOrURI A JSON string value, with the additional requirement that while arbitrary string values MAY be used, any value containing a ":" character MUST be a URI [RFC3986]. StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.
StringOrURI是一个JSON字符串值，另外还要求，尽管可以使用任意字符串值，但包含“：”字符的任何值都必须是URI[RFC3986]。StringOrURI值作为区分大小写的字符串进行比较，不应用任何转换或规范化。
NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.
NumericDate一个JSON数值，表示从UTC 1970-01-01T00:00:00Z到指定UTC日期/时间的秒数，忽略闰秒。这相当于IEEE Std 1003.1，2013版[POSIX.1]的定义“从纪元算起的秒数”，在该定义中，除了可以表示非整数值外，每天的秒数正好为86400秒。有关一般日期/时间，特别是UTC的详细信息，请参见RFC 3339[RFC3339]。
JWTs represent a set of claims as a JSON object that is encoded in a JWS and/or JWE structure. This JSON object is the JWT Claims Set. As per Section 4 of RFC 7159 [RFC7159], the JSON object consists of zero or more name/value pairs (or members), where the names are strings and the values are arbitrary JSON values. These members are the claims represented by the JWT. This JSON object MAY contain whitespace and/or line breaks before or after any JSON values or structural characters, in accordance with Section 2 of RFC 7159 [RFC7159].
JWT将一组声明表示为JWS和/或JWE结构中编码的JSON对象。这个JSON对象是JWT声明集。根据RFC 7159[RFC7159]第4节，JSON对象由零个或多个名称/值对（或成员）组成，其中名称为字符串，值为任意JSON值。这些成员是JWT代表的索赔。根据RFC 7159[RFC7159]第2节，此JSON对象可能在任何JSON值或结构字符之前或之后包含空格和/或换行符。
The member names within the JWT Claims Set are referred to as Claim Names. The corresponding values are referred to as Claim Values.
JWT声明集中的成员名称称为声明名称。相应的值称为索赔值。
The contents of the JOSE Header describe the cryptographic operations applied to the JWT Claims Set. If the JOSE Header is for a JWS, the JWT is represented as a JWS and the claims are digitally signed or MACed, with the JWT Claims Set being the JWS Payload. If the JOSE Header is for a JWE, the JWT is represented as a JWE and the claims are encrypted, with the JWT Claims Set being the plaintext encrypted by the JWE. A JWT may be enclosed in another JWE or JWS structure to create a Nested JWT, enabling nested signing and encryption to be performed.
JOSE头的内容描述了应用于JWT声明集的加密操作。如果JOSE报头用于JWS，则JWT表示为JWS，并且声明被数字签名或MACE，JWT声明集是JWS有效负载。如果JOSE报头用于JWE，则JWT表示为JWE，并且声明被加密，JWT声明集是由JWE加密的明文。JWT可以封装在另一个JWE或JWS结构中，以创建嵌套JWT，从而能够执行嵌套签名和加密。
A JWT is represented as a sequence of URL-safe parts separated by period ('.') characters. Each part contains a base64url-encoded value. The number of parts in the JWT is dependent upon the representation of the resulting JWS using the JWS Compact Serialization or JWE using the JWE Compact Serialization.
JWT表示为URL安全部分的序列，由句点（'.'）字符分隔。每个部分都包含一个base64url编码值。JWT中的部件数量取决于使用JWS紧凑序列化或使用JWE紧凑序列化的JWE生成的JWS的表示形式。
The following example JOSE Header declares that the encoded object is a JWT, and the JWT is a JWS that is MACed using the HMAC SHA-256 algorithm:
以下示例JOSE Header声明编码对象是JWT，JWT是使用HMAC SHA-256算法进行MACE的JWS：
{"typ":"JWT",
"alg":"HS256"}
{"typ":"JWT",
"alg":"HS256"}
To remove potential ambiguities in the representation of the JSON object above, the octet sequence for the actual UTF-8 representation used in this example for the JOSE Header above is also included below. (Note that ambiguities can arise due to differing platform representations of line breaks (CRLF versus LF), differing spacing at the beginning and ends of lines, whether the last line has a terminating line break or not, and other causes. In the representation used in this example, the first line has no leading or trailing spaces, a CRLF line break (13, 10) occurs between the first and second lines, the second line has one leading space (32) and no trailing spaces, and the last line does not have a terminating line break.) The octets representing the UTF-8 representation of the JOSE Header in this example (using JSON array notation) are:
为了消除上述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]
[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]
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
Base64url对JOSE头的UTF-8表示形式的八位字节进行编码，得到该编码的JOSE头值：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9
The following is an example of a JWT Claims Set:
以下是JWT索赔集的示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
The following octet sequence, which is the UTF-8 representation used in this example for the JWT Claims Set above, is the JWS Payload:
以下八位字节序列是JWS有效载荷，它是本例中用于上述JWT声明集的UTF-8表示：
[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]
[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]
Base64url encoding the JWS Payload yields this encoded JWS Payload (with line breaks for display purposes only):
Base64url编码JWS有效负载将产生此编码的JWS有效负载（换行符仅用于显示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly
9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ
Computing the MAC of the encoded JOSE Header and encoded JWS Payload with the HMAC SHA-256 algorithm and base64url encoding the HMAC value in the manner specified in [JWS] yields this encoded JWS Signature:
使用HMAC SHA-256算法计算编码的JOSE报头和编码的JWS有效载荷的MAC，并以[JWS]中指定的方式对HMAC值进行base64url编码，从而生成该编码的JWS签名：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):
按此顺序将这些编码部分与部分之间的句点（'.'）字符连接，生成完整的JWT（换行符仅用于显示目的）：
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ . dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1NiJ9。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
This computation is illustrated in more detail in Appendix A.1 of [JWS]. See Appendix A.1 for an example of an encrypted JWT.
该计算在[JWS]的附录A.1中有更详细的说明。有关加密JWT的示例，请参见附录A.1。
The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. The Claim Names within a JWT Claims Set MUST be unique; JWT parsers MUST either reject JWTs with duplicate Claim Names or use a JSON parser that returns only the lexically last duplicate member name, as specified in Section 15.12 ("The JSON Object") of ECMAScript 5.1 [ECMAScript].
JWT声明集表示一个JSON对象，其成员是JWT传递的声明。JWT索赔集中的索赔名称必须是唯一的；JWT解析器必须拒绝具有重复声明名称的JWT，或者使用只返回词汇上最后一个重复成员名称的JSON解析器，如ECMAScript 5.1[ECMAScript]第15.12节（“JSON对象”）所述。
The set of claims that a JWT must contain to be considered valid is context dependent and is outside the scope of this specification. Specific applications of JWTs will require implementations to understand and process some claims in particular ways. However, in the absence of such requirements, all claims that are not understood by implementations MUST be ignored.
JWT必须包含的一组声明才被视为有效，这组声明依赖于上下文，不在本规范的范围内。JWTs的特定应用需要实现以特定的方式理解和处理某些声明。然而，在没有此类需求的情况下，必须忽略所有未被实现理解的声明。
There are three classes of JWT Claim Names: Registered Claim Names, Public Claim Names, and Private Claim Names.
JWT索赔名称有三类：注册索赔名称、公共索赔名称和私人索赔名称。
The following Claim Names are registered in the IANA "JSON Web Token Claims" registry established by Section 10.1. None of the claims defined below are intended to be mandatory to use or implement in all cases, but rather they provide a starting point for a set of useful, interoperable claims. Applications using JWTs should define which specific claims they use and when they are required or optional. All the names are short because a core goal of JWTs is for the representation to be compact.
以下声明名称在第10.1节建立的IANA“JSON Web令牌声明”注册表中注册。下面定义的任何权利要求都不是在所有情况下都必须使用或实现的，而是为一组有用的、可互操作的权利要求提供了起点。使用JWT的应用程序应该定义它们使用的特定声明以及它们是必需的还是可选的。所有名称都很短，因为JWTs的核心目标是使表示紧凑。
The "iss" (issuer) claim identifies the principal that issued the JWT. The processing of this claim is generally application specific. The "iss" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
“iss”（发行人）索赔确定了发行JWT的委托人。本索赔的处理通常是针对具体应用的。“iss”值是一个区分大小写的字符串，包含StringOrURI值。此声明的使用是可选的。
The "sub" (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The "sub" value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.
“子”（主题）索赔确定了作为联合工作组主题的委托人。JWT中的声明通常是关于主题的声明。主题值的范围必须是发行人上下文中本地唯一的或全局唯一的。本索赔的处理通常是针对具体应用的。“sub”值是一个区分大小写的字符串，包含StringOrURI值。此声明的使用是可选的。
The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case-sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.
“aud”（受众）声明确定了JWT的目标受众。打算处理JWT的每个委托人必须在受众声明中确定自己的价值。如果处理索赔的委托人在该索赔存在时未在“aud”索赔中使用价值进行标识，则必须拒绝JWT。在一般情况下，“aud”值是一个区分大小写的字符串数组，每个字符串都包含一个StringOrURI值。在JWT只有一个受众的特殊情况下，“aud”值可以是包含StringOrURI值的单个区分大小写的字符串。受众价值观的解释通常是特定于应用的。此声明的使用是可选的。
The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing. The processing of the "exp" claim requires that the current date/time MUST be before the expiration date/time listed in the "exp" claim.
“exp”（到期时间）声明标识了到期时间，在此日期或之后不得接受JWT进行处理。“exp”索赔的处理要求当前日期/时间必须早于“exp”索赔中列出的到期日期/时间。
Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
实现者可能会提供一些小的回旋余地，通常不超过几分钟，以解释时钟偏差。其值必须是包含NumericDate值的数字。此声明的使用是可选的。
The "nbf" (not before) claim identifies the time before which the JWT MUST NOT be accepted for processing. The processing of the "nbf" claim requires that the current date/time MUST be after or equal to the not-before date/time listed in the "nbf" claim. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
“nbf”（非之前）声明确定了不得接受JWT进行处理的时间。“nbf”索赔的处理要求当前日期/时间必须晚于或等于“nbf”索赔中列出的不早于日期/时间。实现者可能会提供一些小的回旋余地，通常不超过几分钟，以解释时钟偏差。其值必须是包含NumericDate值的数字。此声明的使用是可选的。
The "iat" (issued at) claim identifies the time at which the JWT was issued. This claim can be used to determine the age of the JWT. Its value MUST be a number containing a NumericDate value. Use of this claim is OPTIONAL.
“iat”（于发布）索赔确定了JWT发布的时间。该声明可用于确定JWT的年龄。其值必须是包含NumericDate值的数字。此声明的使用是可选的。
The "jti" (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The "jti" claim can be used to prevent the JWT from being replayed. The "jti" value is a case-sensitive string. Use of this claim is OPTIONAL.
“jti”（JWTID）声明为JWT提供了唯一标识符。标识符值的分配方式必须确保相同值意外分配给不同数据对象的概率可以忽略不计；如果应用程序使用多个发行者，则必须防止不同发行者生成的值之间发生冲突。“jti”声明可用于防止JWT被重播。“jti”值是区分大小写的字符串。此声明的使用是可选的。
Claim Names can be defined at will by those using JWTs. However, in order to prevent collisions, any new Claim Name should either be registered in the IANA "JSON Web Token Claims" registry established by Section 10.1 or be a Public Name: a value that contains a Collision-Resistant Name. In each case, the definer of the name or value needs to take reasonable precautions to make sure they are in control of the part of the namespace they use to define the Claim Name.
使用JWTs的人可以随意定义索赔名称。但是，为了防止冲突，任何新的声明名称都应该在第10.1节建立的IANA“JSON Web令牌声明”注册表中注册，或者是一个公共名称：一个包含抗冲突名称的值。在每种情况下，名称或值的定义者都需要采取合理的预防措施，以确保他们能够控制用于定义声明名称的命名空间部分。
A producer and consumer of a JWT MAY agree to use Claim Names that are Private Names: names that are not Registered Claim Names (Section 4.1) or Public Claim Names (Section 4.2). Unlike Public
联合工作组的生产者和消费者可同意使用属于私人名称的索赔名称：非注册索赔名称（第4.1节）或公共索赔名称（第4.2节）。不像公众
Claim Names, Private Claim Names are subject to collision and should be used with caution.
索赔名称、私人索赔名称可能发生冲突，应谨慎使用。
For a JWT object, the members of the JSON object represented by the JOSE Header describe the cryptographic operations applied to the JWT and optionally, additional properties of the JWT. Depending upon whether the JWT is a JWS or JWE, the corresponding rules for the JOSE Header values apply.
对于JWT对象，由JOSE头表示的JSON对象的成员描述了应用于JWT的加密操作以及JWT的附加属性（可选）。根据JWT是JWS还是JWE，JOSE头值的相应规则适用。
This specification further specifies the use of the following Header Parameters in both the cases where the JWT is a JWS and where it is a JWE.
本规范进一步规定了在JWT是JWS和JWE的情况下使用以下头参数。
The "typ" (type) Header Parameter defined by [JWS] and [JWE] is used by JWT applications to declare the media type [IANA.MediaTypes] of this complete JWT. This is intended for use by the JWT application when values that are not JWTs could also be present in an application data structure that can contain a JWT object; the application can use this value to disambiguate among the different kinds of objects that might be present. It will typically not be used by applications when it is already known that the object is a JWT. This parameter is ignored by JWT implementations; any processing of this parameter is performed by the JWT application. If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. Use of this Header Parameter is OPTIONAL.
JWT应用程序使用[JWS]和[JWE]定义的“typ”（type）头参数来声明此完整JWT的媒体类型[IANA.MediaTypes]。当非JWT的值也可能出现在可包含JWT对象的应用程序数据结构中时，这是为了供JWT应用程序使用；应用程序可以使用此值消除可能存在的不同类型对象之间的歧义。当已知对象是JWT时，应用程序通常不会使用它。JWT实现会忽略此参数；此参数的任何处理都由JWT应用程序执行。如果存在，建议其值为“JWT”，以指示此对象为JWT。虽然媒体类型名称不区分大小写，但建议始终使用大写字符拼写“JWT”，以与旧式实现兼容。此标头参数的使用是可选的。
The "cty" (content type) Header Parameter defined by [JWS] and [JWE] is used by this specification to convey structural information about the JWT.
本规范使用[JWS]和[JWE]定义的“cty”（内容类型）头参数来传递关于JWT的结构信息。
In the normal case in which nested signing or encryption operations are not employed, the use of this Header Parameter is NOT RECOMMENDED. In the case that nested signing or encryption is employed, this Header Parameter MUST be present; in this case, the value MUST be "JWT", to indicate that a Nested JWT is carried in this JWT. While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations. See Appendix A.2 for an example of a Nested JWT.
在不使用嵌套签名或加密操作的正常情况下，不建议使用此标头参数。如果使用嵌套签名或加密，则必须存在此头参数；在这种情况下，该值必须为“JWT”，以指示此JWT中包含嵌套JWT。虽然媒体类型名称不区分大小写，但建议始终使用大写字符拼写“JWT”，以与旧式实现兼容。有关嵌套JWT的示例，请参见附录A.2。
In some applications using encrypted JWTs, it is useful to have an unencrypted representation of some claims. This might be used, for instance, in application processing rules to determine whether and how to process the JWT before it is decrypted.
在某些使用加密JWT的应用程序中，对某些声明使用未加密的表示是很有用的。例如，这可以在应用程序处理规则中使用，以确定是否以及如何在JWT解密之前对其进行处理。
This specification allows claims present in the JWT Claims Set to be replicated as Header Parameters in a JWT that is a JWE, as needed by the application. If such replicated claims are present, the application receiving them SHOULD verify that their values are identical, unless the application defines other specific processing rules for these claims. It is the responsibility of the application to ensure that only claims that are safe to be transmitted in an unencrypted manner are replicated as Header Parameter values in the JWT.
此规范允许根据应用程序的需要，将JWT声明集中存在的声明作为JWE的JWT中的头参数进行复制。如果存在此类复制声明，则接收它们的应用程序应验证它们的值是否相同，除非应用程序为这些声明定义了其他特定的处理规则。应用程序的责任是确保在JWT中，只有可以安全地以未加密的方式传输的声明才被复制为头参数值。
Section 10.4.1 of this specification registers the "iss" (issuer), "sub" (subject), and "aud" (audience) Header Parameter names for the purpose of providing unencrypted replicas of these claims in encrypted JWTs for applications that need them. Other specifications MAY similarly register other names that are registered Claim Names as Header Parameter names, as needed.
本规范第10.4.1节注册了“iss”（发行人）、“sub”（主题）和“aud”（受众）标题参数名称，以便在加密JWT中为需要这些名称的应用程序提供这些声明的未加密副本。根据需要，其他规范可以类似地将已注册声明名称的其他名称注册为标头参数名称。
To support use cases in which the JWT content is secured by a means other than a signature and/or encryption contained within the JWT (such as a signature on a data structure containing the JWT), JWTs MAY also be created without a signature or encryption. An Unsecured JWT is a JWS using the "alg" Header Parameter value "none" and with the empty string for its JWS Signature value, as defined in the JWA specification [JWA]; it is an Unsecured JWS with the JWT Claims Set as its JWS Payload.
为了支持JWT内容通过JWT中包含的签名和/或加密以外的方式（例如包含JWT的数据结构上的签名）进行安全保护的用例，还可以在不使用签名或加密的情况下创建JWT。不安全JWT是使用“alg”头参数值“none”的JWS，其JWS签名值为空字符串，如JWA规范[JWA]中所定义；它是一个不安全的JWS，JWT声明被设置为其JWS负载。
The following example JOSE Header declares that the encoded object is an Unsecured JWT:
以下示例JOSE Header声明编码对象是不安全的JWT：
{"alg":"none"}
{"alg":"none"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
Base64url对JOSE头的UTF-8表示形式的八位字节进行编码，得到该编码的JOSE头值：
eyJhbGciOiJub25lIn0
eyJhbGciOiJub25lIn0
The following is an example of a JWT Claims Set:
以下是JWT索赔集的示例：
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
{"iss":"joe",
"exp":1300819380,
"http://example.com/is_root":true}
Base64url encoding the octets of the UTF-8 representation of the JWT Claims Set yields this encoded JWS Payload (with line breaks for display purposes only):
Base64url对JWT声明集的UTF-8表示的八位字节进行编码，从而生成此编码的JWS有效负载（换行符仅用于显示目的）：
eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ
The encoded JWS Signature is the empty string.
编码的JWS签名是空字符串。
Concatenating these encoded parts in this order with period ('.') characters between the parts yields this complete JWT (with line breaks for display purposes only):
按此顺序将这些编码部分与部分之间的句点（'.'）字符连接，生成完整的JWT（换行符仅用于显示目的）：
eyJhbGciOiJub25lIn0 . eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMDA4MTkzODAsDQogImh0dHA6Ly9leGFt cGxlLmNvbS9pc19yb290Ijp0cnVlfQ .
eyJhbGciOiJub25lIn0。EYJPC3MIOIJQB2UILA0KIJLEHAIOJEZMDA4MTKZODAZODAQIMH0DHA6LY9LEGFT cGxlLmNvbS9pc19yb290Ijp0cnVlfQ。
To create a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps.
要创建JWT，请执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。
1. Create a JWT Claims Set containing the desired claims. Note that whitespace is explicitly allowed in the representation and no canonicalization need be performed before encoding.
1. 创建包含所需声明的JWT声明集。请注意，表示中明确允许使用空格，编码前无需执行规范化。
2. Let the Message be the octets of the UTF-8 representation of the JWT Claims Set.
2. 让消息是JWT声明集的UTF-8表示的八位字节。
3. Create a JOSE Header containing the desired set of Header Parameters. The JWT MUST conform to either the [JWS] or [JWE] specification. Note that whitespace is explicitly allowed in the representation and no canonicalization need be performed before encoding.
3. 创建包含所需标题参数集的JOSE标题。JWT必须符合[JWS]或[JWE]规范。请注意，表示中明确允许使用空格，编码前无需执行规范化。
4. Depending upon whether the JWT is a JWS or JWE, there are two cases:
4. 根据JWT是JWS还是JWE，有两种情况：
* If the JWT is a JWS, create a JWS using the Message as the JWS Payload; all steps specified in [JWS] for creating a JWS MUST be followed.
* 如果JWT是JWS，则使用消息作为JWS负载创建JWS；必须遵循[JWS]中指定的创建JWS的所有步骤。
* Else, if the JWT is a JWE, create a JWE using the Message as the plaintext for the JWE; all steps specified in [JWE] for creating a JWE MUST be followed.
* 否则，如果JWT是JWE，则使用消息作为JWE的明文创建JWE；必须遵循[JWE]中指定的创建JWE的所有步骤。
5. If a nested signing or encryption operation will be performed, let the Message be the JWS or JWE, and return to Step 3, using a "cty" (content type) value of "JWT" in the new JOSE Header created in that step.
5. 如果将执行嵌套签名或加密操作，则将消息设为JWS或JWE，并在该步骤中创建的新JOSE头中使用“cty”（内容类型）值“JWT”返回步骤3。
6. Otherwise, let the resulting JWT be the JWS or JWE.
6. 否则，将生成的JWT设为JWS或JWE。
When validating a JWT, the following steps are performed. The order of the steps is not significant in cases where there are no dependencies between the inputs and outputs of the steps. If any of the listed steps fail, then the JWT MUST be rejected -- that is, treated by the application as an invalid input.
验证JWT时，将执行以下步骤。在步骤的输入和输出之间没有依赖关系的情况下，步骤的顺序并不重要。如果列出的任何步骤失败，那么必须拒绝JWT——也就是说，应用程序将其视为无效输入。
1. Verify that the JWT contains at least one period ('.') character.
1. 验证JWT是否至少包含一个句点（'.'）字符。
2. Let the Encoded JOSE Header be the portion of the JWT before the first period ('.') character.
2. 让编码的JOSE头成为第一个句点（'.'）字符之前的JWT部分。
3. Base64url decode the Encoded JOSE Header following the restriction that no line breaks, whitespace, or other additional characters have been used.
3. Base64url按照未使用换行符、空格或其他附加字符的限制对编码的JOSE标头进行解码。
4. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JOSE Header be this JSON object.
4. 验证生成的八位字节序列是符合RFC 7159[RFC7159]的完全有效JSON对象的UTF-8编码表示；让JOSE头成为这个JSON对象。
5. Verify that the resulting JOSE Header includes only parameters and values whose syntax and semantics are both understood and supported or that are specified as being ignored when not understood.
5. 验证生成的JOSE标头仅包含语法和语义都已理解和支持的参数和值，或者在不理解时指定为忽略的参数和值。
6. Determine whether the JWT is a JWS or a JWE using any of the methods described in Section 9 of [JWE].
6. 使用[JWE]第9节中描述的任何方法确定JWT是JWS还是JWE。
7. Depending upon whether the JWT is a JWS or JWE, there are two cases:
7. 根据JWT是JWS还是JWE，有两种情况：
* If the JWT is a JWS, follow the steps specified in [JWS] for validating a JWS. Let the Message be the result of base64url decoding the JWS Payload.
* 如果JWT是JWS，请按照[JWS]中指定的步骤验证JWS。让消息成为base64url解码JWS负载的结果。
* Else, if the JWT is a JWE, follow the steps specified in [JWE] for validating a JWE. Let the Message be the resulting plaintext.
* 否则，如果JWT是JWE，请按照[JWE]中指定的步骤验证JWE。让消息成为结果明文。
8. If the JOSE Header contains a "cty" (content type) value of "JWT", then the Message is a JWT that was the subject of nested signing or encryption operations. In this case, return to Step 1, using the Message as the JWT.
8. 如果JOSE头包含“cty”（内容类型）值“JWT”，则消息是一个JWT，它是嵌套签名或加密操作的主题。在这种情况下，使用消息作为JWT返回到步骤1。
9. Otherwise, base64url decode the Message following the restriction that no line breaks, whitespace, or other additional characters have been used.
9. 否则，base64url将按照未使用换行符、空格或其他附加字符的限制对消息进行解码。
10. Verify that the resulting octet sequence is a UTF-8-encoded representation of a completely valid JSON object conforming to RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.
10. 验证生成的八位字节序列是符合RFC 7159[RFC7159]的完全有效JSON对象的UTF-8编码表示；让JWT声明集成为这个JSON对象。
Finally, note that it is an application decision which algorithms may be used in a given context. Even if a JWT can be successfully validated, unless the algorithms used in the JWT are acceptable to the application, it SHOULD reject the JWT.
最后，请注意，在给定上下文中可以使用哪些算法是应用程序的决定。即使JWT可以成功验证，除非JWT中使用的算法为应用程序所接受，否则它应该拒绝JWT。
Processing a JWT inevitably requires comparing known strings to members and values in JSON objects. For example, in checking what the algorithm is, the Unicode [UNICODE] string encoding "alg" will be checked against the member names in the JOSE Header to see if there is a matching Header Parameter name.
处理JWT不可避免地需要将已知字符串与JSON对象中的成员和值进行比较。例如，在检查算法时，将对照JOSE标头中的成员名称检查Unicode[Unicode]字符串编码“alg”，以查看是否有匹配的标头参数名称。
The JSON rules for doing member name comparison are described in Section 8.3 of RFC 7159 [RFC7159]. Since the only string comparison operations that are performed are equality and inequality, the same rules can be used for comparing both member names and member values against known strings.
RFC 7159[RFC7159]第8.3节描述了用于进行成员名称比较的JSON规则。由于执行的唯一字符串比较操作是相等和不相等，因此可以使用相同的规则将成员名称和成员值与已知字符串进行比较。
These comparison rules MUST be used for all JSON string comparisons except in cases where the definition of the member explicitly calls out that a different comparison rule is to be used for that member value. In this specification, only the "typ" and "cty" member values do not use these comparison rules.
这些比较规则必须用于所有JSON字符串比较，除非该成员的定义明确要求对该成员值使用不同的比较规则。在本规范中，只有“typ”和“cty”成员值不使用这些比较规则。
Some applications may include case-insensitive information in a case-sensitive value, such as including a DNS name as part of the "iss" (issuer) claim value. In those cases, the application may need to define a convention for the canonical case to use for representing the case-insensitive portions, such as lowercasing them, if more than one party might need to produce the same value so that they can be compared. (However, if all other parties consume whatever value the producing party emitted verbatim without attempting to compare it to an independently produced value, then the case used by the producer will not matter.)
一些应用程序可能在区分大小写的值中包含不区分大小写的信息，例如将DNS名称作为“iss”（颁发者）声明值的一部分。在这些情况下，如果多个参与方可能需要生成相同的值以便可以对它们进行比较，则应用程序可能需要定义规范大小写用于表示不区分大小写的部分的约定，例如将它们小写。（但是，如果所有其他方使用制作方逐字发出的任何值，而不尝试将其与独立制作的值进行比较，则制作方使用的案例将不重要。）
This section defines which algorithms and features of this specification are mandatory to implement. Applications using this specification can impose additional requirements upon implementations that they use. For instance, one application might require support for encrypted JWTs and Nested JWTs, while another might require support for signing JWTs with the Elliptic Curve Digital Signature Algorithm (ECDSA) using the P-256 curve and the SHA-256 hash algorithm ("ES256").
本节定义了本规范中强制实施的算法和功能。使用此规范的应用程序可以对其使用的实现施加额外的要求。例如，一个应用程序可能需要支持加密JWT和嵌套JWT，而另一个应用程序可能需要支持使用P-256曲线和SHA-256哈希算法（“ES256”）使用椭圆曲线数字签名算法（ECDSA）对JWT进行签名。
Of the signature and MAC algorithms specified in JSON Web Algorithms [JWA], only HMAC SHA-256 ("HS256") and "none" MUST be implemented by conforming JWT implementations. It is RECOMMENDED that implementations also support RSASSA-PKCS1-v1_5 with the SHA-256 hash algorithm ("RS256") and ECDSA using the P-256 curve and the SHA-256 hash algorithm ("ES256"). Support for other algorithms and key sizes is OPTIONAL.
在JSON Web算法[JWA]中指定的签名和MAC算法中，只有HMAC SHA-256（“HS256”）和“无”必须通过符合JWT实现来实现。建议实现也支持带有SHA-256哈希算法（“RS256”）的RSASSA-PKCS1-v1_5和使用P-256曲线和SHA-256哈希算法（“ES256”）的ECDSA。支持其他算法和密钥大小是可选的。
Support for encrypted JWTs is OPTIONAL. If an implementation provides encryption capabilities, of the encryption algorithms specified in [JWA], only RSAES-PKCS1-v1_5 with 2048-bit keys ("RSA1_5"), AES Key Wrap with 128- and 256-bit keys ("A128KW" and "A256KW"), and the composite authenticated encryption algorithm using AES-CBC and HMAC SHA-2 ("A128CBC-HS256" and "A256CBC-HS512") MUST be implemented by conforming implementations. It is RECOMMENDED that implementations also support using Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES) to agree upon a key used to wrap the Content Encryption Key ("ECDH-ES+A128KW" and "ECDH-ES+A256KW") and AES in Galois/Counter Mode (GCM) with 128- and 256-bit keys ("A128GCM" and "A256GCM"). Support for other algorithms and key sizes is OPTIONAL.
对加密JWT的支持是可选的。如果实现提供加密功能，在[JWA]中规定的加密算法中，只有RSAES-PKCS1-v1_5具有2048位密钥（“RSA1_5”）、AES密钥包装具有128位和256位密钥（“A128KW”和“A256KW”），以及使用AES-CBC和HMAC SHA-2的复合认证加密算法（“A128CBC-HS256”和“A256CBC-HS512”）必须通过一致性实现来实现。建议实现还支持使用椭圆曲线Diffie-Hellman瞬时静态（ECDH-ES）来商定用于包装内容加密密钥（“ECDH-ES+A128KW”和“ECDH-ES+A256KW”）的密钥，以及在Galois/计数器模式（GCM）下使用128位和256位密钥（“A128GCM”和“A256GCM”）的AES。支持其他算法和密钥大小是可选的。
Support for Nested JWTs is OPTIONAL.
对嵌套JWT的支持是可选的。
This specification registers the URN "urn:ietf:params:oauth:token-type:jwt" for use by applications that declare content types using URIs (rather than, for instance, media types) to indicate that the content referred to is a JWT.
本规范注册URN“URN:ietf:params:oauth:token type:jwt”，供使用uri（而不是例如媒体类型）声明内容类型的应用程序使用，以指示引用的内容是jwt。
This section establishes the IANA "JSON Web Token Claims" registry for JWT Claim Names. The registry records the Claim Name and a reference to the specification that defines it. This section registers the Claim Names defined in Section 4.1.
本节为JWT声明名称建立IANA“JSON Web令牌声明”注册表。注册表记录声明名称和对定义声明名称的规范的引用。本节登记了第4.1节中定义的索赔名称。
Values are registered on a Specification Required [RFC5226] basis after a three-week review period on the jwt-reg-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
在jwt reg上经过三周的审查后，根据规范要求[RFC5226]登记数值-review@ietf.org根据一名或多名指定专家的建议，提供邮件列表。但是，为了允许在发布之前分配值，指定专家在确信此类规范将发布后，可批准注册。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register claim: example").
发送至邮件列表供审查的注册请求应使用适当的主题（例如，“注册请求：示例”）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
在审查期内，指定专家将批准或拒绝注册请求，并将此决定告知审查名单和IANA。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。超过21天未确定的注册请求可提请IESG注意（使用iesg@ietf.org邮件列表）以供解决。
Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration description is clear.
指定专家应适用的标准包括确定拟议登记是否与现有功能重复，是否可能具有普遍适用性，或是否仅对单一申请有用，以及登记说明是否清楚。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANA必须只接受指定专家的注册更新，并将所有注册请求发送至审查邮件列表。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions. In cases where a registration decision could
建议任命多名指定专家，他们能够代表使用本规范的不同应用的观点，以便对注册决定进行广泛知情的审查。如果注册决定可能
be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.
被视为对某一专家造成利益冲突，该专家应服从其他专家的判断。
Claim Name: The name requested (e.g., "iss"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- that is, not to exceed 8 characters without a compelling reason to do so. This name is case sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Experts state that there is a compelling reason to allow an exception.
索赔名称：请求的名称（例如，“iss”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——也就是说，如果没有令人信服的理由，名称不能超过8个字符。此名称区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定专家声明有令人信服的理由允许例外。
Claim Description: Brief description of the claim (e.g., "Issuer").
索赔说明：索赔的简要说明（例如，“发行人”）。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请列出“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址、主页URI）。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
规范文档：指指定参数的一个或多个文档，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
o Claim Name: "iss" o Claim Description: Issuer o Change Controller: IESG o Specification Document(s): Section 4.1.1 of RFC 7519
o 索赔名称：“iss”o索赔描述：发行人o变更控制人：IESG o规范文件：RFC 7519第4.1.1节
o Claim Name: "sub" o Claim Description: Subject o Change Controller: IESG o Specification Document(s): Section 4.1.2 of RFC 7519
o 索赔名称：“子”o索赔描述：主体o变更控制者：IESG o规范文件：RFC 7519第4.1.2节
o Claim Name: "aud" o Claim Description: Audience o Change Controller: IESG o Specification Document(s): Section 4.1.3 of RFC 7519
o 索赔名称：“aud”o索赔描述：受众o变更控制者：IESG o规范文件：RFC 7519第4.1.3节
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 索赔名称：“exp”o索赔描述：到期时间o变更控制器：IESG o规范文件：RFC 7519第4.1.4节
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 索赔名称：“nbf”o索赔描述：不在变更前控制器：IESG o规范文件：RFC 7519第4.1.5节
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 索赔名称：“iat”o索赔描述：在变更控制员处发布：IESG o规范文件：RFC 7519第4.1.6节
o Claim Name: "jti" o Claim Description: JWT ID o Change Controller: IESG o Specification Document(s): Section 4.1.7 of RFC 7519
o 索赔名称：“jti”o索赔描述：JWT ID o变更控制员：IESG o规范文件：RFC 7519第4.1.7节
10.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt
10.2. Sub-Namespace Registration of
urn:ietf:params:oauth:token-type:jwt
This section registers the value "token-type:jwt" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755], which can be used to indicate that the content is a JWT.
本节在由“OAuth的IETF URN子命名空间”[RFC6755]建立的IANA“OAuth URI”注册表中注册值“令牌类型：jwt”，该值可用于指示内容是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
o URN:URN:ietf:params:oauth:token type:jwt o Common Name:JSON Web token（jwt）token type o Change Controller:IESG o规范文档：RFC 7519
This section registers the "application/jwt" media type [RFC2046] in the "Media Types" registry [IANA.MediaTypes] in the manner described in RFC 6838 [RFC6838], which can be used to indicate that the content is a JWT.
本节以RFC 6838[RFC6838]中所述的方式在“媒体类型”注册表[IANA.MediaTypes]中注册“应用程序/jwt”媒体类型[RFC2046]，可用于指示内容是jwt。
o Type name: application o Subtype name: jwt o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; JWT values are encoded as a series of base64url-encoded values (some of which may be the empty string) separated by period ('.') characters. o Security considerations: See the Security Considerations section of RFC 7519 o Interoperability considerations: n/a o Published specification: RFC 7519 o Applications that use this media type: OpenID Connect, Mozilla Persona, Salesforce, Google, Android, Windows Azure, Amazon Web Services, and numerous others o Fragment identifier considerations: n/a o Additional information:
o 类型名称：应用程序o子类型名称：jwt o必需参数：n/a o可选参数：n/a 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其他信息：
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a
o Person & email address to contact for further information: Michael B. Jones, mbj@microsoft.com o Intended usage: COMMON o Restrictions on usage: none o Author: Michael B. Jones, mbj@microsoft.com o Change controller: IESG o Provisional registration? No
o 联系人和电子邮件地址，以获取更多信息：Michael B.Jones，mbj@microsoft.como预期用途：常见o使用限制：无o作者：Michael B.Jones，mbj@microsoft.como变更控制员：IESG o临时注册？不
This section registers specific Claim Names defined in Section 4.1 in the IANA "JSON Web Signature and Encryption Header Parameters" registry established by [JWS] for use by claims replicated as Header Parameters in JWEs, per Section 5.3.
本节在IANA“JSON Web签名和加密头参数”注册表中注册了第4.1节中定义的特定索赔名称，该注册表由[JWS]建立，用于根据第5.3节在JWEs中复制为头参数的索赔。
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 标题参数名称：“iss”o标题参数说明：发卡机构o标题参数使用位置：JWE o变更控制器：IESG o规范文件：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): Section 4.1.2 of RFC 7519
o 标题参数名称：“sub”o标题参数说明：主题o标题参数使用位置：JWE o变更控制器：IESG o规范文件：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): Section 4.1.3 of RFC 7519
o 标题参数名称：“aud”o标题参数说明：受众o标题参数使用位置：JWE o变更控制器：IESG o规范文件：RFC 7519第4.1.3节
All of the security issues that are pertinent to any cryptographic application must be addressed by JWT/JWS/JWE/JWK agents. Among these issues are protecting the user's asymmetric private and symmetric secret keys and employing countermeasures to various attacks.
与任何加密应用程序相关的所有安全问题都必须由JWT/JWS/JWE/JWK代理解决。这些问题包括保护用户的非对称私钥和对称密钥以及对各种攻击采取对策。
All the security considerations in the JWS specification also apply to JWT, as do the JWE security considerations when encryption is employed. In particular, Sections 10.12 ("JSON Security Considerations") and 10.13 ("Unicode Comparison Security Considerations") of [JWS] apply equally to the JWT Claims Set in the same manner that they do to the JOSE Header.
JWS规范中的所有安全注意事项也适用于JWT，使用加密时的JWE安全注意事项也适用于JWT。特别是，[JWS]的第10.12节（“JSON安全注意事项”）和第10.13节（“Unicode比较安全注意事项”）同样适用于JWT声明集，其方式与它们适用于JOSE头的方式相同。
The contents of a JWT cannot be relied upon in a trust decision unless its contents have been cryptographically secured and bound to the context necessary for the trust decision. In particular, the key(s) used to sign and/or encrypt the JWT will typically need to verifiably be under the control of the party identified as the issuer of the JWT.
JWT的内容在信托决策中不可依赖，除非其内容已通过加密保护并绑定到信托决策所需的上下文。具体而言，用于签名和/或加密JWT的密钥通常需要在被识别为JWT的发行者的一方的可验证控制下。
While syntactically the signing and encryption operations for Nested JWTs may be applied in any order, if both signing and encryption are necessary, normally producers should sign the message and then
虽然嵌套JWT的签名和加密操作在语法上可以按任何顺序应用，但如果签名和加密都是必要的，通常生产者应该对消息进行签名，然后
encrypt the result (thus encrypting the signature). This prevents attacks in which the signature is stripped, leaving just an encrypted message, as well as providing privacy for the signer. Furthermore, signatures over encrypted text are not considered valid in many jurisdictions.
加密结果（从而加密签名）。这可以防止签名被剥离的攻击，只留下加密的消息，并为签名者提供隐私。此外，在许多管辖区，加密文本上的签名被视为无效。
Note that potential concerns about security issues related to the order of signing and encryption operations are already addressed by the underlying JWS and JWE specifications; in particular, because JWE only supports the use of authenticated encryption algorithms, cryptographic concerns about the potential need to sign after encryption that apply in many contexts do not apply to this specification.
请注意，底层JWS和JWE规范已经解决了与签名和加密操作顺序相关的潜在安全问题；特别是，由于JWE只支持使用经过身份验证的加密算法，因此在许多上下文中适用的关于加密后可能需要签名的加密担忧不适用于本规范。
A JWT may contain privacy-sensitive information. When this is the case, measures MUST be taken to prevent disclosure of this information to unintended parties. One way to achieve this is to use an encrypted JWT and authenticate the recipient. Another way is to ensure that JWTs containing unencrypted privacy-sensitive information are only transmitted using protocols utilizing encryption that support endpoint authentication, such as Transport Layer Security (TLS). Omitting privacy-sensitive information from a JWT is the simplest way of minimizing privacy issues.
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>.
[ECMAScript]Ecma国际，“ECMAScript语言规范，5.1版”，Ecma标准262，2011年6月<http://www.ecma-international.org/ecma-262/5.1/ ECMA-262.pdf>。
[IANA.MediaTypes] IANA, "Media Types", <http://www.iana.org/assignments/media-types>.
[IANA.MediaTypes]IANA，“媒体类型”<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>.
[JWA]Jones，M.，“JSON网络算法（JWA）”，RFC 7518，DOI 10.17487/RFC7518，2015年5月<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>.
[JWE]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<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>.
[JWS]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络签名（JWS）”，RFC 7515，DOI 10.17487/RFC，2015年5月<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>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<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>.
[RFC2046]Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 2046，DOI 10.17487/RFC2046，1996年11月<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>.
[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., 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>.
[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., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <http://www.rfc-editor.org/info/rfc4949>.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，DOI 10.17487/RFC4949，2007年8月<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>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/versions/latest/>.
[CanvasApp] Facebook, "Canvas Applications", 2010, <http://developers.facebook.com/docs/authentication/ canvas>.
[CanvasApp]Facebook，“Canvas应用程序”，2010年<http://developers.facebook.com/docs/authentication/ 画布>。
[JSS] Bradley, J. and N. Sakimura (editor), "JSON Simple Sign", September 2010, <http://jsonenc.info/jss/1.0/>.
[JSS]Bradley，J.和N.Sakimura（编辑），“JSON简单符号”，2010年9月<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>.
[MagicSignatures]Panzer，J.，Ed.，Laurie，B.，和D.Balfanz，“魔法签名”，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., 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>.
[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 Issue 7", IEEE Std 1003.1, 2013 Edition, 2013, <http://pubs.opengroup.org/onlinepubs/9699919799/ basedefs/V1_chap04.html#tag_04_15>.
[POSIX.1]IEEE，“开放组基础规范第7期”，IEEE标准1003.12013年版，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>.
[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. 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>.
[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., 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>.
[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. 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>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<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>.
[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., 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>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<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>.
[SWT]Hardt，D.和Y.Goland，“简单网络令牌（SWT）”，版本0.9.5.11909年11月<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.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., "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>.
[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>.
This section contains examples of JWTs. For other example JWTs, see Section 6.1 of this document and Appendices A.1 - A.3 of [JWS].
本节包含JWT的示例。关于其他JWT示例，请参见本文件第6.1节和[JWS]附录A.1-A.3。
This example encrypts the same claims as used in Section 3.1 to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
本示例使用RSAES-PKCS1-v1_5和AES_128_CBC_HMAC_SHA_256向接收方加密第3.1节中使用的相同声明。
The following example JOSE Header declares that:
以下示例声明：
o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext and the JWE Authentication Tag.
o 使用RSAES-PKCS1-v1_5算法将内容加密密钥加密给收件人，以生成JWE加密密钥。o使用AES_128_CBC_HMAC_SHA_256算法对明文执行认证加密，以生成JWE密文和JWE认证标签。
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
{"alg":"RSA1_5","enc":"A128CBC-HS256"}
Other than using the octets of the UTF-8 representation of the JWT Claims Set from Section 3.1 as the plaintext value, the computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], including the keys used.
除了使用第3.1节中JWT权利要求集的UTF-8表示的八位字节作为明文值外，该JWT的计算与[JWE]附录A.2中JWE的计算相同，包括使用的键。
The final result in this example (with line breaks for display purposes only) is:
本例中的最终结果（换行符仅用于显示）为：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0. QR1Owv2ug2WyPBnbQrRARTeEk9kDO2w8qDcjiHnSJflSdv1iNqhWXaKH4MqAkQtM oNfABIPJaZm0HaA415sv3aeuBWnD8J-Ui7Ah6cWafs3ZwwFKDFUUsWHSK-IPKxLG TkND09XyjORj_CHAgOPJ-Sd8ONQRnJvWn_hXV1BNMHzUjPyYwEsRhDhzjAD26ima sOTsgruobpYGoQcXUwFDn7moXPRfDE8-NoQX7N7ZYMmpUDkR-Cx9obNGwJQ3nM52 YCitxoQVPzjbl7WBuB7AohdBoZOdZ24WlN1lVIeh8v1K4krB8xgKvRU8kgFrEn_a 1rZgN5TiysnmzTROF869lQ. AxY8DCtDaGlsbGljb3RoZQ. MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM HDjUEOKIwrtkHthpqEanSBNYHZgmNOV7sln1Eu9g3J8. fiK51VwhsxJ-siBMR-YFiA
EYJHBGCIOIJSU0EXXZUILCJLBMMOIJBMTI4Q0JDLUHTMJU2IN0。2.本研究的目的是研究未来未来的未来未来的未来未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的未来的1rZgN5TiysnmzTROF869lQ。AxY8DCtDaGlsbGljb3RoZQ。MKOle7UQrG6nSxTLX6Mqwt0orbHvAKeWnDYvpIAeZ72deHxz3roJDXQyhxx0wKaM HDJUEOKIWRTKHTPQEANSBNYHZGMNOV7SLN1EU9G3J8。图51VWHSXJ SIBYFIA
This example shows how a JWT can be used as the payload of a JWE or JWS to create a Nested JWT. In this case, the JWT Claims Set is first signed, and then encrypted.
这个例子展示了如何使用JWT作为JWE或JWS的有效负载来创建嵌套的JWT。在这种情况下，JWT声明集首先被签名，然后被加密。
The inner signed JWT is identical to the example in Appendix A.2 of [JWS]. Therefore, its computation is not repeated here. This example then encrypts this inner JWT to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.
The inner signed JWT is identical to the example in Appendix A.2 of [JWS]. Therefore, its computation is not repeated here. This example then encrypts this inner JWT to the recipient using RSAES-PKCS1-v1_5 and AES_128_CBC_HMAC_SHA_256.translate error, please retry
The following example JOSE Header declares that:
以下示例声明：
o The Content Encryption Key is encrypted to the recipient using the RSAES-PKCS1-v1_5 algorithm to produce the JWE Encrypted Key. o Authenticated encryption is performed on the plaintext using the AES_128_CBC_HMAC_SHA_256 algorithm to produce the JWE Ciphertext and the JWE Authentication Tag. o The plaintext is itself a JWT.
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"}
{"alg":"RSA1_5","enc":"A128CBC-HS256","cty":"JWT"}
Base64url encoding the octets of the UTF-8 representation of the JOSE Header yields this encoded JOSE Header value:
Base64url对JOSE头的UTF-8表示形式的八位字节进行编码，得到该编码的JOSE头值：
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
eyJhbGciOiJSU0ExXzUiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiY3R5IjoiSldUIn0
The computation of this JWT is identical to the computation of the JWE in Appendix A.2 of [JWE], other than that different JOSE Header, plaintext, JWE Initialization Vector, and Content Encryption Key values are used. (The RSA key used is the same.)
该JWT的计算与[JWE]附录A.2中JWE的计算相同，不同之处在于使用了不同的JOSE头、明文、JWE初始化向量和内容加密密钥值。（使用的RSA密钥相同。）
The plaintext used is the octets of the ASCII [RFC20] representation of the JWT at the end of Appendix A.2.1 of [JWS] (with all whitespace and line breaks removed), which is a sequence of 458 octets.
所使用的明文是[JWS]附录A.2.1末尾JWT ASCII[RFC20]表示的八位字节（删除所有空格和换行符），这是一个458位字节的序列。
The JWE Initialization Vector value used (using JSON array notation) is:
使用的JWE初始化向量值（使用JSON数组表示法）为：
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
[82, 101, 100, 109, 111, 110, 100, 32, 87, 65, 32, 57, 56, 48, 53, 50]
This example uses the Content Encryption Key represented by the base64url-encoded value below:
此示例使用以下base64url编码值表示的内容加密密钥：
GawgguFyGrWKav7AX4VKUg
GAWGUFYGRWKAV7AX4VKUG
The final result for this Nested JWT (with line breaks for display purposes only) is:
此嵌套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
EYJHBGCIOIJSU0EXXZUILCJLBMMIOIJBMTI4Q0JDLUHTMJU2IWII3R5IJOISLDU在0中。研究结果表明，一个新的研究成果是一个新的研究成果，一个新的研究成果是一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的研究成果，一个新的一个新的研究成果，一个新的研究成果，一个新的一个新的研究成果，一个新的一个新的一个新的研究成果，一个新的一个新的一个新的未来一个新的一个新的一个新的一个新的研究成果，新的一个新的一个新的一个新的一个新的一个新的一个新的研究项目，新的一个新的一个新的一个新的一个新的一个新的一个新的项目，新的一个新的一个新的一个新C9G5QCVDCHWSQ JGTO_z3Wfo5zsqwkxruxwA。UMVKBW9UZCBXQSA51mg。在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，中国，在中国，在中国，在中国，在中国，在中国，在中国，中国，在中国，在中国，中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，在中国，中国QPRP9GC6PXMOU-27ATs9XCvrZXUTK2902UZQPEEUJYJWWXSNSS-r1TJ1I-FMJ4XyAiGrfmo9hQPcNBYxPz3GQb2 8Y5CLSQfNgKSGt0A4isp1hBUXBHAndgtcslt7ZoQJaKe NJNGNLIWTWPJ EBJ8JDHEHDCCNRMIWAMU1N7SPKHILLSOPVCVDFHUN5WQU955VOBVBOA11U2WK6HYI9-e3w29bR0C2-PP2DW2DB-LN9LNYXEBUK9FK9LNK9LNKKKK9LZUZUOKZUOKZUOKZU2BZU2BZUZUZUZU2BZU2B6HZU2B6HZU2B6HZU2B6HZU2B6HZU2BZU2B6。AVO9iT5AV4CzvDJCdhSFlQ
Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] provides a standard for creating security tokens with greater expressivity and more security options than supported by JWTs. However, the cost of this flexibility and expressiveness is both size and complexity. SAML's use of XML [W3C.CR-xml11-20060816] and XML Digital Signature (DSIG) [RFC3275] contributes to the size of SAML Assertions; its use of XML and especially XML Canonicalization [W3C.REC-xml-c14n-20010315] contributes to their complexity.
安全断言标记语言（SAML）2.0[OASIS.SAML-core-2.0-os]为创建安全令牌提供了一个标准，该令牌具有比JWTs更高的表现力和更多的安全选项。然而，这种灵活性和表现力的代价是规模和复杂性。SAML对XML[W3C.CR-xml11-20060816]和XML数字签名（DSIG）[RFC3275]的使用增加了SAML断言的规模；它对XML的使用，特别是XML规范化[W3C.REC-XML-c14n-20010315]增加了它们的复杂性。
JWTs are intended to provide a simple security token format that is small enough to fit into HTTP headers and query arguments in URIs. It does this by supporting a much simpler token model than SAML and using the JSON [RFC7159] object encoding syntax. It also supports securing tokens using Message Authentication Codes (MACs) and digital signatures using a smaller (and less flexible) format than XML DSIG.
JWT旨在提供一种简单的安全令牌格式，该格式足够小，适合URI中的HTTP头和查询参数。它通过支持比SAML简单得多的令牌模型并使用JSON[RFC7159]对象编码语法来实现这一点。它还支持使用消息身份验证码（MAC）保护令牌，并使用比XML DSIG更小（且更不灵活）的格式保护数字签名。
Therefore, while JWTs can do some of the things SAML Assertions do, JWTs are not intended as a full replacement for SAML Assertions, but rather as a token format to be used when ease of implementation or compactness are considerations.
因此，尽管JWT可以做SAML断言所做的一些事情，但JWT并不打算完全替代SAML断言，而是作为一种令牌格式，在考虑实现的易用性或紧凑性时使用。
SAML Assertions are always statements made by an entity about a subject. JWTs are often used in the same manner, with the entity making the statements being represented by the "iss" (issuer) claim, and the subject being represented by the "sub" (subject) claim. However, with these claims being optional, other uses of the JWT format are also permitted.
SAML断言始终是实体对主题所做的声明。JWT通常以相同的方式使用，作出声明的实体由“iss”（发行人）声明表示，主体由“子”（主体）声明表示。然而，由于这些权利要求是可选的，因此也允许使用JWT格式的其他用途。
Appendix C. Relationship of JWTs to Simple Web Tokens (SWTs)
附录C.JWT与简单Web令牌（SWT）的关系
Both JWTs and SWTs [SWT], at their core, enable sets of claims to be communicated between applications. For SWTs, both the claim names and claim values are strings. For JWTs, while claim names are strings, claim values can be any JSON type. Both token types offer cryptographic protection of their content: SWTs with HMAC SHA-256 and JWTs with a choice of algorithms, including signature, MAC, and encryption algorithms.
JWT和SWT[SWT]的核心都支持在应用程序之间传递声明集。对于SWT，声明名称和声明值都是字符串。对于JWTs，虽然声明名称是字符串，但声明值可以是任何JSON类型。这两种令牌类型都为其内容提供加密保护：带有HMAC SHA-256的SWT和带有多种算法选择的JWTs，包括签名、MAC和加密算法。
Acknowledgements
致谢
The authors acknowledge that the design of JWTs was intentionally influenced by the design and simplicity of SWTs [SWT] and ideas for JSON tokens that Dick Hardt discussed within the OpenID community.
作者承认，JWTs的设计有意受到SWT[SWT]的设计和简单性以及Dick Hardt在OpenID社区中讨论的JSON令牌思想的影响。
Solutions for signing JSON content were previously explored by Magic Signatures [MagicSignatures], JSON Simple Sign [JSS], and Canvas Applications [CanvasApp], all of which influenced this document.
签名JSON内容的解决方案之前由Magic Signatures[MagicSignatures]、JSON Simple Sign[JSS]和CanvasApp[CanvasApp]探索，所有这些都影响了本文档。
This specification is the work of the OAuth working group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:
本规范是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.
德克·巴尔芬兹、理查德·巴恩斯、布莱恩·坎贝尔、艾莉莎·库珀、布伦诺·德梅德罗斯、斯蒂芬·法雷尔、雅伦·戈兰、迪克·哈特、乔·希尔德布兰德、杰夫·霍奇斯、埃德蒙·杰伊、沃伦·库马里、本·劳里、巴里·莱巴、特德·莱蒙、詹姆斯·马格尔、普拉蒂克·米什拉、凯瑟琳·莫里亚蒂、托尼·纳达林、阿克塞尔·内恩克、约翰·帕泽尔、艾曼纽尔·拉维特、大卫·赫顿、，Eric Rescorla、Jim Schaad、Paul Tarjan、Hannes Tschofenig、Sean Turner和Tom Yu。
Hannes Tschofenig and Derek Atkins chaired the OAuth working group and Sean Turner, Stephen Farrell, and Kathleen Moriarty served as Security Area Directors during the creation of this specification.
Hannes Tschofenig和Derek Atkins担任OAuth工作组主席，Sean Turner、Stephen Farrell和Kathleen Moriarty在创建本规范期间担任安全区域主管。
Authors' Addresses
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
John Bradley Ping Identity
约翰·布拉德利·平身份
EMail: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
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/
EMail: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/