Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 7521 Ping Identity
Category: Standards Track C. Mortimore
ISSN: 2070-1721 Salesforce
M. Jones
Y. Goland
Microsoft
May 2015
Internet Engineering Task Force (IETF) B. Campbell
Request for Comments: 7521 Ping Identity
Category: Standards Track C. Mortimore
ISSN: 2070-1721 Salesforce
M. Jones
Y. Goland
Microsoft
May 2015
Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants
OAuth 2.0客户端身份验证和授权授权的断言框架
Abstract
摘要
This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified.
本规范以新的客户端身份验证机制和新的授权授予类型的形式为OAuth 2.0的断言的使用提供了一个框架。指定用于在与令牌端点交互期间传输断言的机制；还规定了一般处理规则。
The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.
本规范的目的是为OAuth 2.0提供一个通用框架，以便使用断言与其他身份系统进行交互，并提供替代的客户端身份验证机制。
Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations.
请注意，此规范仅定义抽象消息流和处理规则。为了实现，需要配套的规范来提供相应的具体实例。
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/rfc7521.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7521.
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 ....................................................3
2. Notational Conventions ..........................................4
3. Framework .......................................................4
4. Transporting Assertions .........................................7
4.1. Using Assertions as Authorization Grants ...................7
4.1.1. Error Responses .....................................8
4.2. Using Assertions for Client Authentication .................9
4.2.1. Error Responses ....................................10
5. Assertion Content and Processing ...............................10
5.1. Assertion Metamodel .......................................10
5.2. General Assertion Format and Processing Rules .............12
6. Common Scenarios ...............................................12
6.1. Client Authentication .....................................13
6.2. Client Acting on Behalf of Itself .........................13
6.3. Client Acting on Behalf of a User .........................13
6.3.1. Client Acting on Behalf of an Anonymous User .......14
7. Interoperability Considerations ................................14
8. Security Considerations ........................................15
8.1. Forged Assertion ..........................................15
8.2. Stolen Assertion ..........................................15
8.3. Unauthorized Disclosure of Personal Information ...........16
8.4. Privacy Considerations ....................................17
9. IANA Considerations ............................................17
9.1. "assertion" Parameter Registration ........................17
9.2. "client_assertion" Parameter Registration .................18
9.3. "client_assertion_type" Parameter Registration ............18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
Acknowledgements ..................................................20
Authors' Addresses ................................................20
1. Introduction ....................................................3
2. Notational Conventions ..........................................4
3. Framework .......................................................4
4. Transporting Assertions .........................................7
4.1. Using Assertions as Authorization Grants ...................7
4.1.1. Error Responses .....................................8
4.2. Using Assertions for Client Authentication .................9
4.2.1. Error Responses ....................................10
5. Assertion Content and Processing ...............................10
5.1. Assertion Metamodel .......................................10
5.2. General Assertion Format and Processing Rules .............12
6. Common Scenarios ...............................................12
6.1. Client Authentication .....................................13
6.2. Client Acting on Behalf of Itself .........................13
6.3. Client Acting on Behalf of a User .........................13
6.3.1. Client Acting on Behalf of an Anonymous User .......14
7. Interoperability Considerations ................................14
8. Security Considerations ........................................15
8.1. Forged Assertion ..........................................15
8.2. Stolen Assertion ..........................................15
8.3. Unauthorized Disclosure of Personal Information ...........16
8.4. Privacy Considerations ....................................17
9. IANA Considerations ............................................17
9.1. "assertion" Parameter Registration ........................17
9.2. "client_assertion" Parameter Registration .................18
9.3. "client_assertion_type" Parameter Registration ............18
10. References ....................................................18
10.1. Normative References .....................................18
10.2. Informative References ...................................18
Acknowledgements ..................................................20
Authors' Addresses ................................................20
An assertion is a package of information that facilitates the sharing of identity and security information across security domains. Section 3 provides a more detailed description of the concept of an assertion for the purpose of this specification.
断言是一个信息包，有助于跨安全域共享身份和安全信息。为了本规范的目的，第3节对断言的概念进行了更详细的描述。
OAuth 2.0 [RFC6749] is an authorization framework that enables a third-party application to obtain limited access to a protected HTTP resource. In OAuth, those third-party applications are called clients; they access protected resources by presenting an access token to the HTTP resource. Access tokens are issued to clients by an authorization server with the (sometimes implicit) approval of the resource owner. These access tokens are typically obtained by exchanging an authorization grant, which represents the authorization granted by the resource owner (or by a privileged administrator). Several authorization grant types are defined to support a wide range of client types and user experiences. OAuth also provides an extensibility mechanism for defining additional grant types, which can serve as a bridge between OAuth and other protocol frameworks.
OAuth 2.0[RFC6749]是一个授权框架，它使第三方应用程序能够获得对受保护HTTP资源的有限访问。在OAuth中，这些第三方应用程序称为客户机；它们通过向HTTP资源提供访问令牌来访问受保护的资源。访问令牌由授权服务器在资源所有者（有时是隐式）批准的情况下颁发给客户端。这些访问令牌通常通过交换授权授予来获得，授权授予表示资源所有者（或特权管理员）授予的授权。定义了几种授权授予类型，以支持广泛的客户端类型和用户体验。OAuth还提供了一种扩展机制来定义额外的授权类型，它可以作为OAuth和其他协议框架之间的桥梁。
This specification provides a general framework for the use of assertions as authorization grants with OAuth 2.0. It also provides a framework for assertions to be used for client authentication. It provides generic mechanisms for transporting assertions during interactions with an authorization server's token endpoint as well as general rules for the content and processing of those assertions. The intent is to provide an alternative client authentication mechanism (one that doesn't send client secrets) and to facilitate the use of OAuth 2.0 in client-server integration scenarios, where the end user may not be present.
本规范提供了一个通用框架，用于在OAuth 2.0中将断言用作授权授予。它还为用于客户端身份验证的断言提供了一个框架。它提供了在与授权服务器的令牌端点交互期间传输断言的通用机制，以及这些断言的内容和处理的一般规则。其目的是提供一种替代的客户机身份验证机制（不发送客户机机密的机制），并在最终用户可能不在场的客户机-服务器集成场景中促进OAuth 2.0的使用。
This specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. For instance, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7522] defines a concrete instantiation for Security Assertion Markup Language (SAML) 2.0 Assertions and "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants" [RFC7523] defines a concrete instantiation for JWTs.
本规范仅定义抽象消息流和处理规则。为了实现，需要配套的规范来提供相应的具体实例。例如，“用于OAuth 2.0客户端身份验证和授权授予的安全断言标记语言（SAML）2.0配置文件”[RFC7522]定义了安全断言标记语言（SAML）2.0断言的具体实例和“用于OAuth 2.0客户端身份验证和授权授予的JSON Web令牌（JWT）配置文件”[RFC7523]定义JWTs的具体实例化。
Note: The use of assertions for client authentication is orthogonal to and separable from using assertions as an authorization grant. They can be used either in combination or separately. Client assertion authentication 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. Assertion authorization grants may be used with or without client authentication or identification. Whether or not client authentication is needed in conjunction with an assertion authorization grant, as well as the supported types of client authentication, are policy decisions at the discretion of the authorization server.
协议请求。断言授权授权可以与客户端身份验证或标识一起使用，也可以不与客户端身份验证或标识一起使用。授权服务器自行决定是否需要客户端身份验证与断言授权授权以及支持的客户端身份验证类型。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Throughout this document, values are quoted to indicate that they are to be taken literally. When using these values in protocol messages, the quotes must not be used as part of the value.
在本文件中，引用了数值，以表明它们是按字面意思理解的。在协议消息中使用这些值时，不得将引号用作值的一部分。
An assertion is a package of information that allows identity and security information to be shared across security domains. An assertion typically contains information about a subject or principal, information about the party that issued the assertion and when was it issued, and the conditions under which the assertion is to be considered valid, such as when and where it can be used.
断言是允许跨安全域共享身份和安全信息的信息包。断言通常包含关于主题或主体的信息、关于发出断言的一方的信息以及何时发出的信息，以及断言被视为有效的条件，例如何时何地可以使用断言。
The entity that creates and signs or integrity-protects the assertion is typically known as the "Issuer", and the entity that consumes the assertion and relies on its information is typically known as the "Relying Party". In the context of this document, the authorization server acts as a relying party.
创建并签署或完整性保护断言的实体通常称为“颁发者”，使用断言并依赖其信息的实体通常称为“依赖方”。在本文档的上下文中，授权服务器充当依赖方。
Assertions used in the protocol exchanges defined by this specification MUST always be integrity protected using a digital signature or Message Authentication Code (MAC) applied by the issuer, which authenticates the issuer and ensures integrity of the assertion content. In many cases, the assertion is issued by a third party, and it must be protected against tampering by the client that presents it. An assertion MAY additionally be encrypted, preventing unauthorized parties (such as the client) from inspecting the content.
本规范定义的协议交换中使用的断言必须始终使用发卡机构应用的数字签名或消息身份验证码（MAC）进行完整性保护，该数字签名或消息身份验证码对发卡机构进行身份验证，并确保断言内容的完整性。在许多情况下，断言是由第三方发布的，必须保护断言不被呈现断言的客户端篡改。还可以对断言进行加密，以防止未经授权的方（例如客户端）检查内容。
Although this document does not define the processes by which the client obtains the assertion (prior to sending it to the authorization server), there are two common patterns described below.
尽管本文档没有定义客户端获取断言（在将断言发送到授权服务器之前）的过程，但下面描述了两种常见模式。
In the first pattern, depicted in Figure 1, the client obtains an assertion from a third-party entity capable of issuing, renewing, transforming, and validating security tokens. Typically, such an entity is known as a "security token service" (STS) or just "token service", and a trust relationship (usually manifested in the exchange of some kind of key material) exists between the token service and the relying party. The token service is the assertion issuer; its role is to fulfill requests from clients, which present various credentials, and mint assertions as requested, fill them with appropriate information, and integrity-protect them with a signature or message authentication code. WS-Trust [OASIS.WS-Trust] is one available standard for requesting security tokens (assertions).
在图1所示的第一种模式中，客户机从能够发布、更新、转换和验证安全令牌的第三方实体获得断言。通常，这种实体被称为“安全令牌服务”（STS）或仅仅是“令牌服务”，并且令牌服务和依赖方之间存在信任关系（通常表现为某种密钥材料的交换）。令牌服务是断言颁发者；它的作用是满足客户机的请求，客户机提供各种凭证，并根据请求生成断言，用适当的信息填充它们，并用签名或消息身份验证代码保护它们的完整性。WS-Trust[OASIS.WS-Trust]是请求安全令牌（断言）的一个可用标准。
Relying
Party Client Token Service
| | |
| | 1) Request Assertion |
| |------------------------>|
| | |
| | 2) Assertion |
| |<------------------------|
| 3) Assertion | |
|<-------------------------| |
| | |
| 4) OK or Failure | |
|------------------------->| |
| | |
| | |
Relying
Party Client Token Service
| | |
| | 1) Request Assertion |
| |------------------------>|
| | |
| | 2) Assertion |
| |<------------------------|
| 3) Assertion | |
|<-------------------------| |
| | |
| 4) OK or Failure | |
|------------------------->| |
| | |
| | |
Figure 1: Assertion Created by Third Party
图1：由第三方创建的断言
In the second pattern, depicted in Figure 2, the client creates assertions locally. To apply the signatures or message authentication codes to assertions, it has to obtain key material: either symmetric keys or asymmetric key pairs. The mechanisms for obtaining this key material are beyond the scope of this specification.
在第二种模式中，如图2所示，客户机在本地创建断言。要将签名或消息身份验证代码应用于断言，它必须获得密钥材料：对称密钥或非对称密钥对。获取该关键材料的机制超出了本规范的范围。
Although assertions are usually used to convey identity and security information, self-issued assertions can also serve a different purpose. They can be used to demonstrate knowledge of some secret, such as a client secret, without actually communicating the secret directly in the transaction. In that case, additional information included in the assertion by the client itself will be of limited value to the relying party, and for this reason, only a bare minimum of information is typically included in such an assertion, such as information about issuing and usage conditions.
虽然断言通常用于传递身份和安全信息，但自发布的断言也可以用于不同的目的。它们可以用来证明对某些秘密的了解，例如客户秘密，而不需要在交易中直接传递秘密。在这种情况下，客户端本身的断言中包含的附加信息对依赖方的价值有限，因此，这种断言中通常只包含最低限度的信息，例如关于发布和使用条件的信息。
Relying
Party Client
| |
| | 1) Create
| | Assertion
| |--------------+
| | |
| | 2) Assertion |
| |<-------------+
| 3) Assertion |
|<-------------------------|
| |
| 4) OK or Failure |
|------------------------->|
| |
| |
Relying
Party Client
| |
| | 1) Create
| | Assertion
| |--------------+
| | |
| | 2) Assertion |
| |<-------------+
| 3) Assertion |
|<-------------------------|
| |
| 4) OK or Failure |
|------------------------->|
| |
| |
Figure 2: Self-Issued Assertion
图2：自发布断言
Deployments need to determine the appropriate variant to use based on the required level of security, the trust relationship between the entities, and other factors.
部署需要根据所需的安全级别、实体之间的信任关系和其他因素确定要使用的适当变体。
From the perspective of what must be done by the entity presenting the assertion, there are two general types of assertions:
从呈现断言的实体必须做什么的角度来看，断言有两种一般类型：
1. Bearer Assertions: Any entity in possession of a bearer assertion (the bearer) can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer assertions need to be protected from disclosure in storage and in transport. Secure communication channels are required between all entities to avoid leaking the assertion to unauthorized parties.
1. 承载断言：拥有承载断言的任何实体（承载者）都可以使用它来访问相关资源（无需证明拥有加密密钥）。为了防止误用，需要在存储和传输过程中保护承载断言不被泄露。所有实体之间都需要安全的通信通道，以避免将断言泄露给未经授权的各方。
2. Holder-of-Key Assertions: To access the associated resources, the entity presenting the assertion must demonstrate possession of additional cryptographic material. The token service thereby binds a key identifier to the assertion, and the client has to demonstrate to the relying party that it knows the key corresponding to that identifier when presenting the assertion.
2. 密钥断言持有者：要访问相关资源，呈现断言的实体必须证明拥有其他加密材料。令牌服务因此将密钥标识符绑定到断言，并且客户端必须向依赖方证明，当呈现断言时，它知道与该标识符对应的密钥。
The protocol parameters and processing rules defined in this document are intended to support a client presenting a bearer assertion to an authorization server. They are not directly suitable for use with holder-of-key assertions. While they could be used as a baseline for a holder-of-key assertion system, there would be a need for
本文档中定义的协议参数和处理规则旨在支持向授权服务器呈现承载断言的客户端。它们不直接适用于密钥持有者断言。虽然它们可以用作密钥持有者断言系统的基线，但需要
additional mechanisms (to support proof-of-possession of the secret key), and possibly changes to the security model (e.g., to relax the requirement for an Audience).
额外的机制（支持拥有秘密密钥的证明），以及可能对安全模型的更改（例如，放宽对受众的要求）。
This section defines HTTP parameters for transporting assertions during interactions with a token endpoint of an OAuth authorization server. Because requests to the token endpoint result in the transmission of clear-text credentials (in both the HTTP request and response), all requests to the token endpoint MUST use Transport Layer Security (TLS), as mandated in Section 3.2 of OAuth 2.0 [RFC6749].
本节定义了HTTP参数，用于在与OAuth授权服务器的令牌端点交互期间传输断言。由于对令牌端点的请求会导致明文凭证的传输（在HTTP请求和响应中），因此对令牌端点的所有请求都必须使用传输层安全性（TLS），这是OAuth 2.0[RFC6749]第3.2节规定的。
This section defines the use of assertions as authorization grants, based on the definition provided in Section 4.5 of OAuth 2.0 [RFC6749]. When using assertions as authorization grants, the client includes the assertion and related information using the following HTTP request parameters:
本节根据OAuth 2.0[RFC6749]第4.5节中提供的定义，定义断言作为授权授予的使用。当使用断言作为授权授予时，客户端使用以下HTTP请求参数包括断言和相关信息：
grant_type REQUIRED. The format of the assertion as defined by the authorization server. The value will be an absolute URI.
授权类型是必需的。由授权服务器定义的断言格式。该值将是一个绝对URI。
assertion REQUIRED. The assertion being used as an authorization grant. Specific serialization of the assertion is defined by profile documents.
需要断言。用作授权授予的断言。断言的特定序列化由概要文件文档定义。
scope OPTIONAL. The requested scope as described in Section 3.3 of OAuth 2.0 [RFC6749]. When exchanging assertions for access tokens, the authorization for the token has been previously granted through some out-of-band mechanism. As such, the requested scope MUST be equal to or less than the scope originally granted to the authorized accessor. The authorization server MUST limit the scope of the issued access token to be equal to or less than the scope originally granted to the authorized accessor.
范围可选。OAuth 2.0[RFC6749]第3.3节所述的要求范围。在交换访问令牌的断言时，令牌的授权以前是通过一些带外机制授予的。因此，请求的范围必须等于或小于最初授予授权访问者的范围。授权服务器必须将颁发的访问令牌的范围限制为等于或小于最初授予授权访问者的范围。
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 assertion being used as an authorization grant (with extra line breaks for display purposes only):
以下示例演示了用作授权授予的断言（带有额外的换行符，仅用于显示目的）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2-bearer& assertion=PHNhbWxwOl...[omitted for brevity]...ZT4
授权类型=urn%3Aietf%3Aparams%3Aoauth%3Agrant类型%3Asaml2承载和断言=PHNhbWxwOl…[为简洁起见省略]…ZT4
An assertion used in this context is generally a short-lived representation of the authorization grant, and authorization servers SHOULD NOT issue access tokens with a lifetime that exceeds the validity period of the assertion by a significant period. In practice, that will usually mean that refresh tokens are not issued in response to assertion grant requests, and access tokens will be issued with a reasonably short lifetime. Clients can refresh an expired access token by requesting a new one using the same assertion, if it is still valid, or with a new assertion.
在此上下文中使用的断言通常是授权授予的短期表示，授权服务器不应发出生命周期超过断言有效期一个显著周期的访问令牌。在实践中，这通常意味着刷新令牌不会响应断言授予请求而发出，而访问令牌的生命周期将相当短。如果过期的访问令牌仍然有效，客户端可以使用相同的断言请求新的访问令牌，或者使用新的断言来刷新该令牌。
An IETF URN for use as the "grant_type" value can be requested using the template in [RFC6755]. A URN of the form urn:ietf:params:oauth:grant-type:* is suggested.
可以使用[RFC6755]中的模板请求用作“授权类型”值的IETF URN。建议使用格式为URN:ietf:params:oauth:grant type:*的URN。
If an assertion is not valid or has expired, 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 assertion was considered invalid using the "error_description" or "error_uri" parameters.
如果断言无效或已过期，授权服务器将按照OAuth 2.0[RFC6749]中的定义构造错误响应。“error”参数的值必须是“invalid_grant”错误代码。授权服务器可以包括关于使用“error\u description”或“error\u uri”参数将断言视为无效的原因的附加信息。
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"
}
The following section defines the use of assertions as client credentials as an extension of Section 2.3 of OAuth 2.0 [RFC6749]. When using assertions as client credentials, the client includes the assertion and related information using the following HTTP request parameters:
下一节将断言作为客户端凭据的使用定义为OAuth 2.0[RFC6749]第2.3节的扩展。使用断言作为客户端凭据时，客户端使用以下HTTP请求参数包括断言和相关信息：
client_assertion_type REQUIRED. The format of the assertion as defined by the authorization server. The value will be an absolute URI.
需要客户端断言类型。由授权服务器定义的断言格式。该值将是一个绝对URI。
client_assertion REQUIRED. The assertion being used to authenticate the client. Specific serialization of the assertion is defined by profile documents.
需要客户端断言。用于对客户端进行身份验证的断言。断言的特定序列化由概要文件文档定义。
client_id OPTIONAL. The client identifier as described in Section 2.2 of OAuth 2.0 [RFC6749]. The "client_id" is unnecessary for client assertion authentication because the client is identified by the subject of the assertion. If present, the value of the "client_id" parameter MUST identify the same client as is identified by the client assertion.
客户端id可选。OAuth 2.0[RFC6749]第2.2节中所述的客户端标识符。客户端断言身份验证不需要“client_id”，因为客户端由断言的主题标识。如果存在，“client_id”参数的值必须标识客户端断言标识的同一客户端。
The following example demonstrates a client authenticating using an assertion during an access token request, as defined in Section 4.1.3 of OAuth 2.0 [RFC6749] (with extra line breaks for display purposes only):
以下示例演示了在访问令牌请求期间使用断言进行身份验证的客户端，如OAuth 2.0[RFC6749]第4.1.3节中所定义（仅出于显示目的使用额外的换行符）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code& code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhbW...[omitted for brevity]...ZT
grant_type=authorization_code&code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&client_assertion_type=urn%3AETF%3Params%3OAuth%3Client assertion type%3SAML2承载和client_assertion=PHNhbW…[为简洁起见省略]…ZT
Token endpoints can differentiate between assertion-based credentials and other client credential types by looking for the presence of the "client_assertion" and "client_assertion_type" parameters, which will only be present when using assertions for client authentication.
令牌端点可以通过查找是否存在“client_assertion”和“client_assertion_type”参数来区分基于断言的凭据和其他客户端凭据类型，这些参数仅在使用断言进行客户端身份验证时才存在。
An IETF URN for use as the "client_assertion_type" value may be requested using the template in [RFC6755]. A URN of the form urn:ietf:params:oauth:client-assertion-type:* is suggested.
可以使用[RFC6755]中的模板请求用作“客户端断言类型”值的IETF URN。建议使用格式为URN:ietf:params:oauth:client断言类型：*的URN。
If an assertion is invalid for any reason or if more than one client authentication mechanism is used, 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 client assertion was considered invalid using the "error_description" or "error_uri" parameters.
如果断言因任何原因无效，或者使用了多个客户端身份验证机制，则授权服务器将按照OAuth 2.0[RFC6749]中的定义构造错误响应。“error”参数的值必须是“invalid_client”错误代码。授权服务器可以包括关于使用“error\u description”或“error\u uri”参数将客户端断言视为无效的原因的附加信息。
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_client"
"error_description":"assertion has expired"
}
{
"error":"invalid_client"
"error_description":"assertion has expired"
}
This section provides a general content and processing model for the use of assertions in OAuth 2.0 [RFC6749].
本节为OAuth 2.0[RFC6749]中断言的使用提供了一个通用的内容和处理模型。
The following are entities and metadata involved in the issuance, exchange, and processing of assertions in OAuth 2.0. These are general terms, abstract from any particular assertion format. Mappings of these terms into specific representations are provided by profiles of this specification.
以下是OAuth 2.0中断言的发布、交换和处理所涉及的实体和元数据。这些是从任何特定断言格式中抽象出来的通用术语。本规范的概要文件提供了这些术语到特定表示的映射。
Issuer A unique identifier for the entity that issued the assertion. Generally, this is the entity that holds the key material used to sign or integrity-protect the assertion. Examples of issuers are OAuth clients (when assertions are self-issued) and third-party security token services. If the assertion is self-issued, the Issuer value is the client identifier. If the assertion was issued by a security token service (STS), the Issuer should identify the STS in a manner recognized by the authorization server. 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].
颁发者发出断言的实体的唯一标识符。通常，这是持有用于签名或保护断言完整性的关键材料的实体。发布者的示例是OAuth客户端（当断言是自发布的）和第三方安全令牌服务。如果断言是自发布的，则Issuer值是客户机标识符。如果断言是由安全令牌服务（STS）发出的，则发出者应以授权服务器识别的方式标识STS。在没有应用程序配置文件另有规定的情况下，合规应用程序必须使用RFC 3986[RFC3986]第6.2.1节中定义的简单字符串比较方法比较发卡机构值。
Subject A unique identifier for the principal that is the subject of the assertion.
Subject作为断言主题的主体的唯一标识符。
* When using assertions for client authentication, the Subject identifies the client to the authorization server using the value of the "client_id" of the OAuth client.
* 当使用断言进行客户端身份验证时，主题使用OAuth客户端的“client_id”值向授权服务器标识客户端。
* When using assertions as an authorization grant, the Subject identifies an authorized accessor for which the access token is being requested (typically, the resource owner or an authorized delegate).
* 当使用断言作为授权授予时，主题会标识请求访问令牌的授权访问者（通常是资源所有者或授权委托）。
Audience A value that identifies the party or parties intended to process the assertion. The URL of the token endpoint, as defined in Section 3.2 of OAuth 2.0 [RFC6749], can be used to indicate that the authorization server is a valid intended audience of the assertion. 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].
受众标识要处理断言的一方或多方的值。OAuth 2.0[RFC6749]第3.2节中定义的令牌端点的URL可用于指示授权服务器是断言的有效预期受众。在没有应用程序配置文件另有规定的情况下，符合要求的应用程序必须使用RFC 3986[RFC3986]第6.2.1节中定义的简单字符串比较方法来比较受众值。
Issued At The time at which the assertion was issued. While the serialization may differ by assertion format, it is REQUIRED that the time be expressed in UTC with no time zone component.
在发出断言时发出。虽然序列化可能因断言格式不同而有所不同，但要求时间以UTC表示，不带时区组件。
Expires At The time at which the assertion expires. While the serialization may differ by assertion format, it is REQUIRED that the time be expressed in UTC with no time zone component.
在断言过期时过期。虽然序列化可能因断言格式不同而有所不同，但要求时间以UTC表示，不带时区组件。
Assertion ID A nonce or unique identifier for the assertion. The Assertion ID may be used by implementations requiring message de-duplication for one-time use assertions. Any entity that assigns an identifier MUST ensure that there is negligible probability for that entity or any other entity to accidentally assign the same identifier to a different data object.
断言ID断言的临时标识符或唯一标识符。对于一次性使用断言，需要重复消息消除的实现可以使用断言ID。分配标识符的任何实体都必须确保该实体或任何其他实体意外地将相同标识符分配给不同数据对象的概率可以忽略不计。
The following are general format and processing rules for the use of assertions in OAuth:
以下是OAuth中使用断言的一般格式和处理规则：
o The assertion MUST contain an Issuer. The Issuer identifies the entity that issued the assertion as recognized by the authorization server. If an assertion is self-issued, the Issuer MUST be the value of the client's "client_id".
o 断言必须包含颁发者。颁发者将发出断言的实体标识为授权服务器所识别的实体。如果断言是自发布的，则发布者必须是客户端“client_id”的值。
o The assertion MUST contain a Subject. 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. When the client is acting on behalf of itself, the Subject MUST be the value of the client's "client_id".
o 断言必须包含一个主题。主题通常标识请求访问令牌的授权访问者（即，资源所有者或授权委托），但在某些情况下，可以是假名标识符或表示匿名用户的其他值。当客户代表自己行事时，主题必须是客户“客户id”的值。
o The assertion MUST contain an Audience that identifies the authorization server as the intended audience. The authorization server MUST reject any assertion that does not contain its own identity as the intended audience.
o 断言必须包含将授权服务器标识为预期受众的受众。授权服务器必须拒绝任何不包含其自身作为目标受众身份的断言。
o The assertion MUST contain an Expires At entity that limits the time window during which the assertion can be used. The authorization server MUST reject assertions that have expired (subject to allowable clock skew between systems). Note that the authorization server may reject assertions with an Expires At attribute value that is unreasonably far in the future.
o 断言必须包含一个Expires At实体，该实体限制可以使用断言的时间窗口。授权服务器必须拒绝已过期的断言（根据系统之间允许的时钟偏差）。请注意，授权服务器可能会拒绝具有Expires At属性值的断言，该属性值在将来不合理地远。
o The assertion MAY contain an Issued At entity containing the UTC time at which the assertion was issued.
o 断言可能包含一个发出时间实体，该实体包含断言发出的UTC时间。
o The authorization server MUST reject assertions with an invalid signature or MAC. The algorithm used to validate the signature or message authentication code and the mechanism for designating the secret used to generate the signature or message authentication code over the assertion are beyond the scope of this specification.
o 授权服务器必须拒绝带有无效签名或MAC的断言。用于验证签名或消息认证码的算法以及用于指定用于在断言上生成签名或消息认证码的秘密的机制超出了本规范的范围。
The following provides additional guidance, beyond the format and processing rules defined in Sections 4 and 5, on assertion use for a number of common use cases.
除了第4节和第5节中定义的格式和处理规则之外，以下内容还提供了关于一些常见用例的断言使用的额外指导。
A client uses an assertion to authenticate to the authorization server's token endpoint by using the "client_assertion_type" and "client_assertion" parameters as defined in Section 4.2. The Subject of the assertion identifies the client. If the assertion is self-issued by the client, the Issuer of the assertion also identifies the client.
客户端使用断言通过使用第4.2节中定义的“客户端断言类型”和“客户端断言”参数对授权服务器的令牌端点进行身份验证。断言的主题标识客户机。如果断言是由客户机自行发布的，则断言的发布者也会标识客户机。
The example in Section 4.2 shows a client authenticating using an assertion during an access token request.
第4.2节中的示例显示了在访问令牌请求期间使用断言进行身份验证的客户端。
When a client is accessing resources on behalf of itself, it does so in a manner analogous to the Client Credentials Grant defined in Section 4.4 of OAuth 2.0 [RFC6749]. This is a special case that combines both the authentication and authorization grant usage patterns. In this case, the interactions with the authorization server should be treated as using an assertion for Client Authentication according to Section 4.2, while using the "grant_type" parameter with the value "client_credentials" to indicate that the client is requesting an access token using only its client credentials.
当客户机代表自己访问资源时，其访问方式类似于OAuth 2.0[RFC6749]第4.4节中定义的客户机凭据授予。这是一个结合了身份验证和授权授予使用模式的特例。在这种情况下，与授权服务器的交互应视为根据第4.2节使用客户端身份验证断言，同时使用值为“Client_credentials”的“grant_type”参数指示客户端仅使用其客户端凭据请求访问令牌。
The following example demonstrates an assertion being used for a client credentials access token request, as defined in Section 4.4.2 of OAuth 2.0 [RFC6749] (with extra line breaks for display purposes only):
以下示例演示了用于客户端凭据访问令牌请求的断言，如OAuth 2.0[RFC6749]第4.4.2节中所定义（仅出于显示目的使用额外的换行符）：
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials& client_assertion_type=urn%3Aietf%3Aparams%3Aoauth %3Aclient-assertion-type%3Asaml2-bearer& client_assertion=PHNhbW...[omitted for brevity]...ZT
授权类型=客户端凭据和客户端断言类型=urn%3Aietf%3Aparams%3Aoauth%3Aclient断言类型%3Asaml2承载和客户端断言=PHNhbW…[为简洁起见省略]…ZT
When a client is accessing resources on behalf of a user, it does so by using the "grant_type" and "assertion" parameters as defined in Section 4.1. The Subject identifies an authorized accessor for which the access token is being requested (typically, the resource owner or an authorized delegate).
当客户端代表用户访问资源时，它通过使用第4.1节中定义的“grant_type”和“assertion”参数来访问资源。主题标识请求访问令牌的授权访问者（通常是资源所有者或授权委托）。
The example in Section 4.1 shows a client making an access token request using an assertion as an authorization grant.
第4.1节中的示例显示了使用断言作为授权授予发出访问令牌请求的客户端。
When a client is accessing resources on behalf of an anonymous user, a mutually agreed-upon Subject identifier indicating anonymity is used. The Subject value might be an opaque persistent or transient pseudonymous identifier for the user or be an agreed-upon static value indicating an anonymous user (e.g., "anonymous"). The authorization may be based upon additional criteria, such as additional attributes or claims provided in the assertion. For example, a client might present an assertion from a trusted issuer asserting that the bearer is over 18 via an included claim. In this case, no additional information about the user's identity is included, yet all the data needed to issue an access token is present.
当客户机代表匿名用户访问资源时，将使用双方一致同意的表示匿名性的主题标识符。主题值可以是用户的不透明持久性或暂时性笔名标识符，或者是指示匿名用户的商定静态值（例如，“匿名”）。授权可以基于附加标准，例如断言中提供的附加属性或声明。例如，客户机可能通过包含的声明提供来自可信发行人的断言，断言持票人超过18岁。在这种情况下，不包括关于用户身份的附加信息，但存在发出访问令牌所需的所有数据。
More information about anonymity, pseudonymity, and privacy considerations in general can be found in [RFC6973].
有关匿名性、假名和隐私注意事项的更多信息，请参见[RFC6973]。
This specification defines a framework for using assertions with OAuth 2.0. However, as an abstract framework in which the data formats used for representing many values are not defined, on its own, this specification is not sufficient to produce interoperable implementations.
本规范定义了一个用于在OAuth 2.0中使用断言的框架。但是，作为一个抽象框架，用于表示许多值的数据格式本身没有定义，因此该规范不足以生成可互操作的实现。
Two other specifications that profile this framework for specific assertions have been developed: [RFC7522] uses SAML 2.0 Assertions and [RFC7523] uses JSON Web Tokens (JWTs). These two instantiations of this framework specify additional details about the assertion encoding and processing rules for using those kinds of assertions with OAuth 2.0.
另外两个为特定断言分析此框架的规范已经开发出来：[RFC7522]使用SAML2.0断言，[RFC7523]使用JSON Web令牌（JWT）。该框架的这两个实例指定了有关在OAuth 2.0中使用这些断言的断言编码和处理规则的附加细节。
However, even when profiled for specific assertion types, agreements between system entities regarding identifiers, keys, and endpoints are required in order to achieve interoperable deployments. Specific items that require agreement are as follows: values for the Issuer and Audience identifiers, supported assertion and client authentication types, the location of the token endpoint, the key used to apply and verify the digital signature or MAC over the assertion, one-time use restrictions on assertions, maximum assertion lifetime allowed, and the specific Subject and attribute requirements of the assertion. The exchange of such information is explicitly out of the scope of this specification. Deployments for particular trust frameworks, circles of trust, or other uses cases will need to agree
但是，即使针对特定的断言类型进行分析，系统实体之间也需要就标识符、键和端点达成协议，以实现可互操作的部署。需要达成协议的具体项目如下：颁发者和受众标识符的值、支持的断言和客户端身份验证类型、令牌端点的位置、用于在断言上应用和验证数字签名或MAC的密钥、断言的一次性使用限制、允许的最大断言生存期、，以及主张的具体主体和属性要求。此类信息的交换明显超出本规范的范围。特定信任框架、信任圈或其他用例的部署需要达成一致
among the participants on the kinds of values to be used for some abstract fields defined by this specification. In some cases, additional profiles may be created that constrain or prescribe these values or specify how they are to be exchanged. The "OAuth 2.0 Dynamic Client Registration Core Protocol" [OAUTH-DYN-REG] is one such profile that enables OAuth Clients to register metadata about themselves at an authorization server.
参与者之间讨论了本规范定义的某些抽象字段要使用的值的种类。在某些情况下，可能会创建其他配置文件来约束或规定这些值，或指定如何交换这些值。“OAuth 2.0动态客户机注册核心协议”[OAuth-DYN-REG]就是这样一种配置文件，它使OAuth客户机能够在授权服务器上注册关于自己的元数据。
This section discusses security considerations that apply when using assertions with OAuth 2.0 as described in this document. As discussed in Section 3, there are two different ways to obtain assertions: either as self-issued or obtained from a third-party token service. While the actual interactions for obtaining an assertion are outside the scope of this document, the details are important from a security perspective. Section 3 discusses the high-level architectural aspects. Many of the security considerations discussed in this section are applicable to both the OAuth exchange as well as the client obtaining the assertion.
本节讨论在本文档中描述的OAuth 2.0中使用断言时应用的安全注意事项。如第3节所述，获取断言有两种不同的方式：自发布或从第三方令牌服务获取。虽然获取断言的实际交互不在本文档的范围内，但从安全角度来看，细节很重要。第3节讨论了高层架构方面。本节讨论的许多安全注意事项都适用于OAuth交换以及获取断言的客户端。
The remainder of this section focuses on the exchanges that concern presenting an assertion for client authentication and for the authorization grant.
本节的其余部分将重点介绍有关为客户端身份验证和授权授予提供断言的交换。
Threat: An adversary could forge or alter an assertion in order to obtain an access token (in the case of the authorization grant) or to impersonate a client (in the case of the client authentication mechanism).
威胁：对手可以伪造或更改断言，以获取访问令牌（在授权授予的情况下）或模拟客户端（在客户端身份验证机制的情况下）。
Countermeasures: To avoid this kind of attack, the entities must assure that proper mechanisms for protecting the integrity of the assertion are employed. This includes the issuer digitally signing the assertion or computing a MAC over the assertion.
对策：为了避免这种攻击，实体必须确保使用适当的机制来保护断言的完整性。这包括发卡机构对断言进行数字签名或通过断言计算MAC。
Threat: An adversary may be able obtain an assertion (e.g., by eavesdropping) and then reuse it (replay it) at a later point in time.
威胁：对手可能获得断言（例如，通过窃听），然后在稍后的时间点重新使用（重播）。
Countermeasures: The primary mitigation for this threat is the use of secure communication channels with server authentication for all network exchanges.
对策：此威胁的主要缓解措施是对所有网络交换机使用具有服务器身份验证的安全通信通道。
An assertion may also contain several elements to prevent replay attacks. There is, however, a clear trade-off between reusing an assertion for multiple exchanges and obtaining and creating new, fresh assertions.
断言还可能包含若干元素以防止重播攻击。然而，在多次交换中重用断言与获取和创建新的断言之间存在着明显的权衡。
Authorization servers and resource servers may use a combination of the Assertion ID and Issued At/Expires At attributes for replay protection. Previously processed assertions may be rejected based on the Assertion ID. The addition of the validity window relieves the authorization server from maintaining an infinite state table of processed Assertion IDs.
授权服务器和资源服务器可以使用断言ID和在/过期时发出的属性的组合来进行重播保护。以前处理过的断言可能会根据断言ID被拒绝。添加validity（有效性）窗口可以使授权服务器不再维护处理过的断言ID的无限状态表。
Threat: The ability for other entities to obtain information about an individual, such as authentication information, role in an organization, or other authorization-relevant information, raises privacy concerns.
威胁：其他实体获取个人信息的能力，如身份验证信息、组织中的角色或其他授权相关信息，会引起隐私问题。
Countermeasures: To address this threat, two cases need to be differentiated:
对策：为了应对这一威胁，需要区分两种情况：
First, a third party that did not participate in any of the exchange is prevented from eavesdropping on the content of the assertion by employing confidentiality protection of the exchange using TLS. This ensures that an eavesdropper on the wire is unable to obtain information. However, this does not prevent legitimate protocol entities from obtaining information that they are not allowed to possess from assertions. Some assertion formats allow for the assertion to be encrypted, preventing unauthorized parties from inspecting the content.
首先，通过使用TLS对交换进行保密保护，防止未参与任何交换的第三方窃听断言的内容。这就确保了窃听者无法获得信息。然而，这并不妨碍合法的协议实体从断言中获取不允许它们拥有的信息。某些断言格式允许对断言进行加密，从而防止未经授权的各方检查内容。
Second, an authorization server may obtain an assertion that was created by a third-party token service and that token service may have placed attributes into the assertion. To mitigate potential privacy problems, prior consent for the release of such attribute information from the resource owner should be obtained. OAuth itself does not directly provide such capabilities, but this consent approval may be obtained using other identity management protocols or user consent interactions; it may also be obtained in an out-of-band fashion.
第二，授权服务器可以获得由第三方令牌服务创建的断言，并且该令牌服务可能已将属性放入该断言中。为缓解潜在的隐私问题，应事先获得资源所有者对此类属性信息发布的同意。OAuth本身并不直接提供此类功能，但可以使用其他身份管理协议或用户同意交互来获得此同意批准；它也可以以带外方式获得。
For the cases where a third-party token service creates assertions to be used for client authentication, privacy concerns are typically lower, since many of these clients are Web servers rather than individual devices operated by humans. If the assertions are used for client authentication of devices or software that can be closely linked to end users, then privacy protection safeguards need to be taken into consideration.
对于第三方令牌服务创建用于客户端身份验证的断言的情况，隐私问题通常较低，因为这些客户端中有许多是Web服务器，而不是由人工操作的单个设备。如果断言用于与最终用户密切相关的设备或软件的客户端身份验证，则需要考虑隐私保护保障措施。
Further guidance on privacy friendly protocol design can be found in [RFC6973].
有关隐私友好协议设计的更多指导，请参见[RFC6973]。
An assertion may contain privacy-sensitive information and, to prevent disclosure of such information to unintended parties, should only be transmitted over encrypted channels, such as TLS. In cases where it is desirable to prevent disclosure of certain information to the client, the assertion (or portions of it) should be encrypted to the authorization server.
断言可能包含对隐私敏感的信息，为了防止向非预期方披露此类信息，只能通过加密通道（如TLS）传输。在需要防止向客户机披露某些信息的情况下，应将断言（或其部分）加密到授权服务器。
Deployments should determine the minimum amount of information necessary to complete the exchange and include only such information in the assertion. In some cases, the Subject identifier can be a value representing an anonymous or pseudonymous user, as described in Section 6.3.1.
部署应确定完成交换所需的最小信息量，并在断言中仅包含此类信息。在某些情况下，主题标识符可以是代表匿名或假名用户的值，如第6.3.1节所述。
This section registers three values, as listed in the subsections below, in the IANA "OAuth Parameters" registry established by RFC 6749 [RFC6749].
本节在由RFC 6749[RFC6749]建立的IANA“OAuth参数”注册表中注册三个值，如下小节所列。
o Name: assertion
o 名称：断言
o Parameter Usage Location: token request
o 参数使用位置：令牌请求
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 7521
o 规范文件：RFC 7521
o Name: client_assertion
o 名称：client_断言
o Parameter Usage Location: token request
o 参数使用位置：令牌请求
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 7521
o 规范文件：RFC 7521
o Name: client_assertion_type
o 名称：客户端\u断言\u类型
o Parameter Usage Location: token request
o 参数使用位置：令牌请求
o Change Controller: IESG
o 更改控制器：IESG
o Specification Document(s): RFC 7521
o 规范文件：RFC 7521
[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>.
[OASIS.WS-Trust] Nadalin, A., Ed., Goodner, M., Ed., Gudgin, M., Ed., Barbir, A., Ed., and H. Granqvist, Ed., "WS-Trust", February 2009, <http://docs.oasis-open.org/ws-sx/ ws-trust/v1.4/ws-trust.html>.
[OASIS.WS-Trust]Nadalin，A.，Ed.，Goodner，M.，Ed.，Gudgin，M.，Ed.，Barbir，A.，Ed.，和H.Granqvist，Ed.，“WS-Trust”，2009年2月<http://docs.oasis-open.org/ws-sx/ ws-trust/v1.4/ws-trust.html>。
[OAUTH-DYN-REG] Richer, J., Ed., 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.，Ed.，Jones，M.，Bradley，J.，Machulak，M.，和P.Hunt，“OAUTH 2.0动态客户端注册协议”，正在进行的工作，草案-ietf-OAUTH-DYN-REG-292015年5月。
[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>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[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>.
[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, <http://www.rfc-editor.org/info/rfc7523>.
[RFC7523]Jones，M.，Campbell，B.，和C.Mortimore，“OAuth 2.0客户端身份验证和授权授权的JSON Web令牌（JWT）配置文件”，RFC 7523，DOI 10.17487/RFC7523，2015年5月<http://www.rfc-editor.org/info/rfc7523>.
Acknowledgements
致谢
The authors wish to thank the following people who have influenced or contributed to this specification: Paul Madsen, Eric Sachs, Jian Cai, Tony Nadalin, Hannes Tschofenig, the authors of the OAuth WRAP specification, and the members of the OAuth working group.
作者希望感谢以下对本规范有影响或贡献的人：Paul Madsen、Eric Sachs、蔡健、Tony Nadalin、Hannes Tschofenig、OAuth WRAP规范的作者以及OAuth工作组的成员。
Authors' Addresses
作者地址
Brian Campbell Ping Identity
布莱恩·坎贝尔·平身份
EMail: brian.d.campbell@gmail.com
EMail: brian.d.campbell@gmail.com
Chuck Mortimore Salesforce.com
Chuck Mortimore Salesforce.com
EMail: cmortimore@salesforce.com
EMail: cmortimore@salesforce.com
Michael B. Jones Microsoft
迈克尔·琼斯微软公司
EMail: mbj@microsoft.com
URI: http://self-issued.info/
EMail: mbj@microsoft.com
URI: http://self-issued.info/
Yaron Y. Goland Microsoft
雅伦·Y·高兰德微软公司
EMail: yarong@microsoft.com
EMail: yarong@microsoft.com