Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7523 Microsoft
Category: Standards Track B. Campbell
ISSN: 2070-1721 Ping Identity
C. Mortimore
Salesforce
May 2015
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 7523 Microsoft
Category: Standards Track B. Campbell
ISSN: 2070-1721 Ping Identity
C. Mortimore
Salesforce
May 2015
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
OAuth 2.0客户端身份验证和授权授权的JSON Web令牌（JWT）配置文件
Abstract
摘要
This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication.
本规范定义使用JSON Web令牌（JWT）承载令牌作为请求OAuth 2.0访问令牌以及客户端身份验证的手段。
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/rfc7523.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7523.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4
2.1. Using JWTs as Authorization Grants . . . . . . . . . . . 4
2.2. Using JWTs for Client Authentication . . . . . . . . . . 5
3. JWT Format and Processing Requirements . . . . . . . . . . . 5
3.1. Authorization Grant Processing . . . . . . . . . . . . . 7
3.2. Client Authentication Processing . . . . . . . . . . . . 8
4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8
5. Interoperability Considerations . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:jwt-bearer . . . . . . . 10
8.2. Sub-Namespace Registration of
urn:ietf:params:oauth:client-assertion-type:jwt-bearer . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP Parameter Bindings for Transporting Assertions . . . . . 4
2.1. Using JWTs as Authorization Grants . . . . . . . . . . . 4
2.2. Using JWTs for Client Authentication . . . . . . . . . . 5
3. JWT Format and Processing Requirements . . . . . . . . . . . 5
3.1. Authorization Grant Processing . . . . . . . . . . . . . 7
3.2. Client Authentication Processing . . . . . . . . . . . . 8
4. Authorization Grant Example . . . . . . . . . . . . . . . . . 8
5. Interoperability Considerations . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:jwt-bearer . . . . . . . 10
8.2. Sub-Namespace Registration of
urn:ietf:params:oauth:client-assertion-type:jwt-bearer . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
JSON Web Token (JWT) [JWT] is a JSON-based [RFC7159] security token encoding that enables identity and security information to be shared across security domains. A security token is generally issued by an Identity Provider and consumed by a Relying Party that relies on its content to identify the token's subject for security-related purposes.
JSON Web令牌（JWT）[JWT]是一种基于JSON的[RFC7159]安全令牌编码，允许跨安全域共享身份和安全信息。安全令牌通常由身份提供者颁发，并由依赖方使用，该依赖方依赖其内容识别令牌的主体以用于安全相关目的。
The OAuth 2.0 Authorization Framework [RFC6749] provides a method for making authenticated HTTP requests to a resource using an access token. Access tokens are issued to third-party clients by an authorization server (AS) with the (sometimes implicit) approval of the resource owner. In OAuth, an authorization grant is an abstract term used to describe intermediate credentials that represent the resource owner authorization. An authorization grant is used by the client to obtain an access token. Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also allows for the definition of new extension grant types to support additional clients or to provide a bridge between OAuth and other trust frameworks. Finally, OAuth allows the
OAuth 2.0授权框架[RFC6749]提供了一种使用访问令牌向资源发出经过身份验证的HTTP请求的方法。访问令牌由授权服务器（AS）在资源所有者（有时是隐含的）批准下颁发给第三方客户端。在OAuth中，授权授予是一个抽象术语，用于描述表示资源所有者授权的中间凭证。客户端使用授权授予来获取访问令牌。定义了几种授权授予类型，以支持广泛的客户端类型和用户体验。OAuth还允许定义新的扩展授权类型，以支持其他客户端或在OAuth和其他信任框架之间提供桥梁。最后，OAuth允许
definition of additional authentication mechanisms to be used by clients when interacting with the authorization server.
定义客户端在与授权服务器交互时使用的其他身份验证机制。
"Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521] is an abstract extension to OAuth 2.0 that provides a general framework for the use of assertions (a.k.a. security tokens) as client credentials and/or authorization grants with OAuth 2.0. This specification profiles the OAuth Assertion Framework [RFC7521] to define an extension grant type that uses a JWT Bearer Token to request an OAuth 2.0 access token as well as for use as client credentials. The format and processing rules for the JWT defined in this specification are intentionally similar, though not identical, to those in the closely related specification "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522]. The differences arise where the structure and semantics of JWTs differ from SAML Assertions. JWTs, for example, have no direct equivalent to the <SubjectConfirmation> or <AuthnStatement> elements of SAML Assertions.
“OAuth 2.0客户端身份验证和授权授权的断言框架”[RFC7521]是OAuth 2.0的抽象扩展，它提供了一个通用框架，用于将断言（也称为安全令牌）用作客户端凭据和/或OAuth 2.0的授权授权。本规范概述了OAuth断言框架[RFC7521]，以定义扩展授权类型，该类型使用JWT承载令牌来请求OAuth 2.0访问令牌以及用作客户端凭据。本规范中定义的JWT的格式和处理规则有意与密切相关的规范“OAuth 2.0客户端身份验证和授权授权的安全断言标记语言（SAML）2.0概要文件”[RFC7522]中的格式和处理规则相似，但不完全相同。当JWT的结构和语义与SAML断言不同时，就会产生差异。例如，JWT没有直接等价于SAML断言的<SubjectConfirmation>或<AuthnStatement>元素。
This document defines how a JWT Bearer Token can be used to request an access token when a client wishes to utilize an existing trust relationship, expressed through the semantics of the JWT, without a direct user-approval step at the authorization server. It also defines how a JWT can be used as a client authentication mechanism. The use of a security token for client authentication is orthogonal to and separable from using a security token as an authorization grant. They can be used either in combination or separately. Client authentication using a JWT is nothing more than an alternative way for a client to authenticate to the token endpoint and must be used in conjunction with some grant type to form a complete and meaningful protocol request. JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.
本文档定义了当客户端希望利用通过JWT语义表示的现有信任关系时，如何使用JWT承载令牌来请求访问令牌，而无需授权服务器上的直接用户批准步骤。它还定义了如何将JWT用作客户端身份验证机制。用于客户端身份验证的安全令牌的使用与将安全令牌用作授权授权是正交的，并且是可分离的。它们可以组合使用，也可以单独使用。使用JWT的客户端身份验证只不过是客户端向令牌端点进行身份验证的一种替代方法，必须与某些授予类型结合使用，以形成完整且有意义的协议请求。JWT授权授权可与客户身份验证或标识一起使用，也可不与客户身份验证或标识一起使用。授权服务器自行决定是否需要与JWT授权授权一起使用客户端身份验证，以及支持的客户端身份验证类型。
The process by which the client obtains the JWT, prior to exchanging it with the authorization server or using it for client authentication, is out of scope.
客户端在与授权服务器交换JWT或将其用于客户端身份验证之前获取JWT的过程超出范围。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
除非另有说明，否则所有协议参数名称和值都区分大小写。
All terms are as defined in the following specifications: "The OAuth 2.0 Authorization Framework" [RFC6749], the OAuth Assertion Framework [RFC7521], and "JSON Web Token (JWT)" [JWT].
所有术语均在以下规范中定义：“OAuth 2.0授权框架”[RFC6749]、OAuth断言框架[RFC7521]和“JSON Web令牌（JWT）”[JWT]。
The OAuth Assertion Framework [RFC7521] defines generic HTTP parameters for transporting assertions (a.k.a. security tokens) during interactions with a token endpoint. This section defines specific parameters and treatments of those parameters for use with JWT Bearer Tokens.
OAuth断言框架[RFC7521]定义了通用HTTP参数，用于在与令牌端点交互期间传输断言（也称为安全令牌）。本节定义了用于JWT承载令牌的特定参数和这些参数的处理方法。
To use a Bearer JWT as an authorization grant, the client uses an access token request as defined in Section 4 of the OAuth Assertion Framework [RFC7521] with the following specific parameter values and encodings.
为了使用承载JWT作为授权授权，客户端使用OAuth断言框架[RFC7521]第4节中定义的访问令牌请求，并使用以下特定参数值和编码。
The value of the "grant_type" is "urn:ietf:params:oauth:grant-type:jwt-bearer".
“grant_type”的值是“urn:ietf:params:oauth:grant type:jwt-bearer”。
The value of the "assertion" parameter MUST contain a single JWT.
“assertion”参数的值必须包含一个JWT。
The "scope" parameter may be used, as defined in the OAuth Assertion Framework [RFC7521], to indicate the requested scope.
如OAuth断言框架[RFC7521]中定义的，“scope”参数可用于指示请求的范围。
Authentication of the client is optional, as described in Section 3.2.1 of OAuth 2.0 [RFC6749] and consequently, the "client_id" is only needed when a form of client authentication that relies on the parameter is used.
客户端身份验证是可选的，如OAuth 2.0[RFC6749]第3.2.1节所述，因此，只有在使用依赖于参数的客户端身份验证形式时，才需要“客户端id”。
The following example demonstrates an access token request with a JWT as an authorization grant (with extra line breaks for display purposes only):
以下示例演示了使用JWT作为授权授予的访问令牌请求（额外的换行符仅用于显示目的）：
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0. eyJpc3Mi[...omitted for brevity...]. J9l-ZhwP[...omitted for brevity...]
授权类型=urn%3Aietf%3Aparams%3Aoauth%3Agrant类型%3Ajwt承载和断言=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0。eyJpc3Mi[…为简洁起见省略…]。J9l ZhwP[…为简洁起见省略…]
To use a JWT Bearer Token for client authentication, the client uses the following parameter values and encodings.
要使用JWT承载令牌进行客户端身份验证，客户端将使用以下参数值和编码。
The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:jwt-bearer".
“客户端断言类型”的值是“urn:ietf:params:oauth:client断言类型：jwt bearer”。
The value of the "client_assertion" parameter contains a single JWT. It MUST NOT contain more than one JWT.
“client_assertion”参数的值包含一个JWT。它不能包含多个JWT。
The following example demonstrates client authentication using a JWT during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):
以下示例演示了在访问令牌请求中显示授权码授权期间使用JWT进行客户端身份验证（额外的换行符仅用于显示目的）：
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code& code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A client-assertion-type%3Ajwt-bearer& client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0. eyJpc3Mi[...omitted for brevity...]. cC4hiUPo[...omitted for brevity...]
授权类型=授权代码和代码=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4和客户端断言类型=urn%3IETF%3Params%3OAuth%3A客户端断言类型%3Ajwt承载和客户端断言=EYJHBGCIOIJZI1NIISIPZI6IJYIN0。eyJpc3Mi[…为简洁起见省略…]。cC4hiUPo[…为简洁起见省略…]
In order to issue an access token response as described in OAuth 2.0 [RFC6749] or to rely on a JWT for client authentication, the authorization server MUST validate the JWT according to the criteria below. Application of additional restrictions and policy are at the discretion of the authorization server.
为了发出OAuth 2.0[RFC6749]中所述的访问令牌响应或依赖JWT进行客户端身份验证，授权服务器必须根据以下标准验证JWT。其他限制和策略的应用由授权服务器自行决定。
1. The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986].
1. 联合工作组必须包含“iss”（发行人）声明，该声明包含发布联合工作组的实体的唯一标识符。在没有应用程序配置文件另有规定的情况下，合规应用程序必须使用RFC 3986[RFC3986]第6.2.1节中定义的简单字符串比较方法比较发卡机构值。
2. The JWT MUST contain a "sub" (subject) claim identifying the principal that is the subject of the JWT. Two cases need to be differentiated:
2. 联合工作组必须包含一个“子”（主体）索赔，确定联合工作组的主体。需要区分两种情况：
A. For the authorization grant, the subject typically identifies an authorized accessor for which the access token is being requested (i.e., the resource owner or an authorized delegate), but in some cases, may be a pseudonymous identifier or other value denoting an anonymous user.
A.对于授权授予，主体通常标识请求访问令牌的授权访问者（即，资源所有者或授权代表），但在某些情况下，可以是假名标识符或表示匿名用户的其他值。
B. For client authentication, the subject MUST be the "client_id" of the OAuth client.
B.对于客户端身份验证，主题必须是OAuth客户端的“客户端id”。
3. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The token endpoint URL of the authorization server MAY be used as a value for an "aud" element to identify the authorization server as an intended audience of the JWT. The authorization server MUST reject any JWT that does not contain its own identity as the intended audience. In the absence of an application profile specifying otherwise, compliant applications MUST compare the audience values using the Simple String Comparison method defined in Section 6.2.1 of RFC 3986 [RFC3986]. As noted in Section 5, the precise strings to be used as the audience for a given authorization server must be configured out of band by the authorization server and the issuer of the JWT.
3. JWT必须包含一个“aud”（受众）声明，该声明包含一个将授权服务器标识为预期受众的值。授权服务器的令牌端点URL可用作“aud”元素的值，以将授权服务器标识为JWT的预期受众。授权服务器必须拒绝任何不包含其作为目标受众的身份的JWT。在没有应用程序配置文件另有规定的情况下，符合要求的应用程序必须使用RFC 3986[RFC3986]第6.2.1节中定义的简单字符串比较方法来比较受众值。如第5节所述，要用作给定授权服务器的访问群体的精确字符串必须由授权服务器和JWT的颁发者在带外进行配置。
4. The JWT MUST contain an "exp" (expiration time) claim that limits the time window during which the JWT can be used. The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future.
4. JWT必须包含一个“exp”（过期时间）声明，该声明限制了JWT可以使用的时间窗口。授权服务器必须拒绝任何过期时间已过的JWT，这取决于系统之间允许的时钟偏差。请注意，授权服务器可能会拒绝具有“exp”声明值的JWT，该声明值在将来不合理地远。
5. The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.
5. JWT可能包含一个“nbf”（非之前）声明，该声明标识了令牌不能被接受处理的时间。
6. The JWT MAY contain an "iat" (issued at) claim that identifies the time at which the JWT was issued. Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past.
6. 联合工作组可能包含一项“iat”（于发布）索赔，该索赔确定了联合工作组发布的时间。请注意，授权服务器可能会拒绝具有“iat”声明值的JWT，该声明值在过去是不合理的。
7. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token. The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant.
7. JWT可以包含为令牌提供唯一标识符的“jti”（JWT ID）声明。授权服务器可以通过在JWT根据适用的“exp”瞬间被视为有效的时间长度内维护所使用的“jti”值的集合来确保JWT不会被重放。
8. The JWT MAY contain other claims.
8. JWT可能包含其他权利要求。
9. The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer. The authorization server MUST reject JWTs with an invalid signature or MAC.
9. JWT必须经过数字签名，或由发卡机构应用消息认证码（MAC）。授权服务器必须拒绝具有无效签名或MAC的JWT。
10. The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" [JWT].
10. 根据“JSON Web令牌（JWT）”[JWT]，授权服务器必须拒绝在所有其他方面无效的JWT。
JWT authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with a JWT authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server. However, if client credentials are present in the request, the authorization server MUST validate them.
JWT授权授权可与客户身份验证或标识一起使用，也可不与客户身份验证或标识一起使用。授权服务器自行决定是否需要与JWT授权授权一起使用客户端身份验证，以及支持的客户端身份验证类型。但是，如果请求中存在客户端凭据，则授权服务器必须验证它们。
If the JWT is not valid, or the current time is not within the token's valid time window for use, the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_grant" error code. The authorization server MAY include additional information regarding the reasons the JWT was considered invalid using the "error_description" or "error_uri" parameters.
如果JWT无效，或者当前时间不在令牌的有效时间窗口内，则授权服务器将按照OAuth 2.0[RFC6749]中的定义构造错误响应。“error”参数的值必须是“invalid_grant”错误代码。授权服务器可以包括关于使用“error\u description”或“error\u uri”参数将JWT视为无效的原因的附加信息。
For example:
例如：
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_grant",
"error_description":"Audience validation failed"
}
{
"error":"invalid_grant",
"error_description":"Audience validation failed"
}
If the client JWT is not valid, the authorization server constructs an error response as defined in OAuth 2.0 [RFC6749]. The value of the "error" parameter MUST be the "invalid_client" error code. The authorization server MAY include additional information regarding the reasons the JWT was considered invalid using the "error_description" or "error_uri" parameters.
如果客户端JWT无效，授权服务器将按照OAuth 2.0[RFC6749]中的定义构造错误响应。“error”参数的值必须是“invalid_client”错误代码。授权服务器可以包括关于使用“error\u description”或“error\u uri”参数将JWT视为无效的原因的附加信息。
The following examples illustrate what a conforming JWT and an access token request would look like.
以下示例说明了一致性JWT和访问令牌请求的外观。
The example shows a JWT issued and signed by the system entity identified as "https://jwt-idp.example.com". The subject of the JWT is identified by email address as "mike@example.com". The intended audience of the JWT is "https://jwt-rp.example.net", which is an identifier with which the authorization server identifies itself. The JWT is sent as part of an access token request to the authorization server's token endpoint at "https://authz.example.net/ token.oauth2".
该示例显示了由系统实体签发和签署的JWT，标识为“https://jwt-idp.example.com". JWT的主题通过电子邮件地址标识为“mike@example.com". JWT的目标受众是“https://jwt-rp.example.net“，这是授权服务器用来标识自身的标识符。JWT作为访问令牌请求的一部分发送到授权服务器的令牌端点，地址为“https://authz.example.net/ token.oauth2”。
Below is an example JSON object that could be encoded to produce the JWT Claims Set for a JWT:
下面是一个JSON对象示例，可以对其进行编码以生成JWT的JWT声明集：
{"iss":"https://jwt-idp.example.com",
"sub":"mailto:mike@example.com",
"aud":"https://jwt-rp.example.net",
"nbf":1300815780,
"exp":1300819380,
"http://claims.example.com/member":true}
{"iss":"https://jwt-idp.example.com",
"sub":"mailto:mike@example.com",
"aud":"https://jwt-rp.example.net",
"nbf":1300815780,
"exp":1300819380,
"http://claims.example.com/member":true}
The following example JSON object, used as the header of a JWT, declares that the JWT is signed with the Elliptic Curve Digital Signature Algorithm (ECDSA) P-256 SHA-256 using a key identified by the "kid" value "16".
以下示例JSON对象用作JWT的头，声明JWT使用椭圆曲线数字签名算法（ECDSA）P-256 SHA-256，使用“kid”值“16”标识的密钥进行签名。
{"alg":"ES256","kid":"16"}
{"alg":"ES256","kid":"16"}
To present the JWT with the claims and header shown in the previous example as part of an access token request, for example, the client might make the following HTTPS request (with extra line breaks for display purposes only):
例如，为了向JWT提供上一示例中所示的声明和标头作为访问令牌请求的一部分，客户端可能会发出以下HTTPS请求（带有额外的换行符，仅用于显示目的）：
POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded
POST /token.oauth2 HTTP/1.1
Host: authz.example.net
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0. eyJpc3Mi[...omitted for brevity...]. J9l-ZhwP[...omitted for brevity...]
授权类型=urn%3Aietf%3Aparams%3Aoauth%3Agrant类型%3Ajwt承载和断言=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0。eyJpc3Mi[…为简洁起见省略…]。J9l ZhwP[…为简洁起见省略…]
Agreement between system entities regarding identifiers, keys, and endpoints is required in order to achieve interoperable deployments of this profile. Specific items that require agreement are as follows: values for the issuer and audience identifiers, the location of the token endpoint, the key used to apply and verify the digital signature or MAC over the JWT, one-time use restrictions on the JWT, maximum JWT lifetime allowed, and the specific subject and claim requirements of the JWT. The exchange of such information is explicitly out of scope for this specification. In some cases, additional profiles may be created that constrain or prescribe these values or specify how they are to be exchanged. Examples of such profiles include the OAuth 2.0 Dynamic Client Registration Core Protocol [OAUTH-DYN-REG], OpenID Connect Dynamic Client Registration 1.0 [OpenID.Registration], and OpenID Connect Discovery 1.0 [OpenID.Discovery].
为了实现此概要文件的互操作部署，系统实体之间需要就标识符、密钥和端点达成一致。需要达成协议的具体项目如下：发行人和受众标识符的值、令牌端点的位置、用于在JWT上应用和验证数字签名或MAC的密钥、JWT的一次性使用限制、允许的最大JWT寿命以及JWT的特定主题和索赔要求。此类信息的交换显然超出了本规范的范围。在某些情况下，可能会创建其他配置文件来约束或规定这些值，或指定如何交换这些值。此类概要文件的示例包括OAuth 2.0动态客户端注册核心协议[OAuth-DYN-REG]、OpenID Connect动态客户端注册1.0[OpenID.Registration]和OpenID Connect Discovery 1.0[OpenID.Discovery]。
The "RS256" algorithm, from [JWA], is a mandatory-to-implement JSON Web Signature algorithm for this profile.
来自[JWA]的“RS256”算法是实现此配置文件的JSON Web签名算法的必备算法。
The security considerations described within the following specifications are all applicable to this document: "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7521], "The OAuth 2.0 Authorization Framework" [RFC6749], and "JSON Web Token (JWT)" [JWT].
以下规范中描述的安全注意事项均适用于本文档：“OAuth 2.0客户端身份验证和授权授权的断言框架”[RFC7521]、“OAuth 2.0授权框架”[RFC6749]和“JSON Web令牌（JWT）”[JWT]。
The specification does not mandate replay protection for the JWT usage for either the authorization grant or for client authentication. It is an optional feature, which implementations may employ at their own discretion.
对于授权授予或客户端身份验证，该规范不强制JWT使用的重播保护。这是一个可选特性，实现可以自行决定使用它。
A JWT may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the JWT should be encrypted to the authorization server.
JWT可能包含隐私敏感信息，并且为了防止向非预期方披露此类信息，只能通过加密通道（如传输层安全性（TLS））进行传输。在需要防止向客户机披露某些信息的情况下，JWT应加密到授权服务器。
Deployments should determine the minimum amount of information necessary to complete the exchange and include only such claims in the JWT. In some cases, the "sub" (subject) claim can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1 of the OAuth Assertion Framework [RFC7521].
部署应确定完成交换所需的最低信息量，并在JWT中仅包括此类声明。在某些情况下，“sub”（subject）声明可以是表示匿名或假名用户的值，如OAuth断言框架[RFC7521]第6.3.1节所述。
8.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:jwt-bearer
8.1. Sub-Namespace Registration of
urn:ietf:params:oauth:grant-type:jwt-bearer
This section registers the value "grant-type:jwt-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].
本节在由“OAuth的IETF URN子命名空间”[RFC6755]建立的IANA“OAuth URI”注册表中注册值“grant type:jwt bearer”。
o URN: urn:ietf:params:oauth:grant-type:jwt-bearer o Common Name: JWT Bearer Token Grant Type Profile for OAuth 2.0 o Change Controller: IESG o Specification Document: RFC 7523
o URN:URN:ietf:params:oauth:grant-type:jwt-bearer-o通用名称：jwt-bearer-Token-grant-type-Profile for-oauth 2.0更改控制器：IESG-o规范文档：RFC 7523
8.2. Sub-Namespace Registration of
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
8.2. Sub-Namespace Registration of
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
This section registers the value "client-assertion-type:jwt-bearer" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [RFC6755].
本节在由“OAuth的IETF URN子命名空间”[RFC6755]建立的IANA“OAuth URI”注册表中注册值“客户端断言类型：jwt承载器”。
o URN: urn:ietf:params:oauth:client-assertion-type:jwt-bearer o Common Name: JWT Bearer Token Profile for OAuth 2.0 Client Authentication o Change Controller: IESG o Specification Document: RFC 7523
o URN:URN:ietf:params:oauth:client断言类型：jwt bearer o Common Name:jwt bearer-Token-Profile for oauth 2.0客户端身份验证o变更控制器：IESG o规范文档：RFC 7523
[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>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[JWT]Jones，M.，Bradley，J.，和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<http://www.rfc-editor.org/info/rfc7519>.
[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>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749]Hardt，D.，Ed.“OAuth 2.0授权框架”，RFC 6749，DOI 10.17487/RFC6749，2012年10月<http://www.rfc-editor.org/info/rfc6749>.
[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>.
[RFC7521] Campbell, B., Mortimore, C., Jones, M., and Y. Goland, "Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521, May 2015, <http://www.rfc-editor.org/info/rfc7521>.
[RFC7521]Campbell，B.，Mortimore，C.，Jones，M.，和Y.Goland，“OAuth 2.0客户端身份验证和授权授权的断言框架”，RFC 7521，DOI 10.17487/RFC7521，2015年5月<http://www.rfc-editor.org/info/rfc7521>.
[OAUTH-DYN-REG] Richer, J., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", Work in Progress, draft-ietf-oauth-dyn-reg-29, May 2015.
[OAUTH-DYN-REG]Richer，J.，Jones，M.，Bradley，J.，Machulak，M.，和P.Hunt，“OAUTH 2.0动态客户端注册协议”，正在进行的工作，草案-ietf-OAUTH-DYN-REG-292015年5月。
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.
[OpenID.Discovery]北樱村、J.布拉德利、M.琼斯和E.杰伊，“OpenID连接发现1.0合并勘误表集1”，2014年11月<http://openid.net/specs/ openid-connect-discovery-1_0.html>。
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 1", November 2014, <http://openid.net/specs/ openid-connect-registration-1_0.html>.
[OpenID.注册]Sakimura，N.，Bradley，J.，和M.Jones，“OpenID Connect动态客户端注册1.0合并勘误表集1”，2014年11月<http://openid.net/specs/ openid-connect-registration-1_0.html>。
[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>.
[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015, <http://www.rfc-editor.org/info/rfc7522>.
[RFC7522]Campbell，B.，Mortimore，C.，和M.Jones，“OAuth 2.0客户端身份验证和授权授予的安全断言标记语言（SAML）2.0配置文件”，RFC 7522，DOI 10.17487/RFC7522，2015年5月<http://www.rfc-editor.org/info/rfc7522>.
Acknowledgements
致谢
This profile was derived from "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522], which has the same authors as this document.
此配置文件源自“OAuth 2.0客户端身份验证和授权授予的安全断言标记语言（SAML）2.0配置文件”[RFC7522]，其作者与本文档相同。
Authors' Addresses
作者地址
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Brian Campbell Ping Identity
布莱恩·坎贝尔·平身份
EMail: brian.d.campbell@gmail.com
EMail: brian.d.campbell@gmail.com
Chuck Mortimore Salesforce
查克·莫蒂莫尔销售团队
EMail: cmortimore@salesforce.com
EMail: cmortimore@salesforce.com