Internet Engineering Task Force (IETF) W. Mills
Request for Comments: 7628 Microsoft
Category: Standards Track T. Showalter
ISSN: 2070-1721
H. Tschofenig
ARM Ltd.
August 2015
Internet Engineering Task Force (IETF) W. Mills
Request for Comments: 7628 Microsoft
Category: Standards Track T. Showalter
ISSN: 2070-1721
H. Tschofenig
ARM Ltd.
August 2015
A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth
OAuth的一组简单身份验证和安全层（SASL）机制
Abstract
摘要
OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction or by allowing the third-party application to obtain access on its own behalf.
OAuth使第三方应用程序能够代表资源所有者通过协调批准交互或允许第三方应用程序代表自己获得对受保护资源的有限访问。
This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource server. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols.
本文档定义了应用程序客户端如何使用通过OAuth通过简单身份验证和安全层（SASL）获得的凭据访问资源服务器上受保护的资源。因此，它支持在OAuth框架内为非基于HTTP的应用程序协议定义的方案。
Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password.
客户端通常存储用户的长期凭证。然而，这确实会导致严重的安全漏洞，例如，当此类凭证泄漏时。在这些客户机中使用OAuth的一个显著好处是，密码被具有更高熵的共享秘密（即令牌）替换。令牌通常提供有限的访问权限，可以与用户的长期密码分开管理和撤销。
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/rfc7628.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7628.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6
3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7
3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8
3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8
3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9
3.2.2. Server Response to Failed Authentication . . . . . . 9
3.2.3. Completing an Error Message Sequence . . . . . . . . 10
3.3. OAuth Access Token Types using Keyed Message Digests . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14
4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Internationalization Considerations . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. OAuth SASL Mechanism Specifications . . . . . . . . . . . . . 6
3.1. Initial Client Response . . . . . . . . . . . . . . . . . 7
3.1.1. Reserved Key/Values . . . . . . . . . . . . . . . . . 8
3.2. Server's Response . . . . . . . . . . . . . . . . . . . . 8
3.2.1. OAuth Identifiers in the SASL Context . . . . . . . . 9
3.2.2. Server Response to Failed Authentication . . . . . . 9
3.2.3. Completing an Error Message Sequence . . . . . . . . 10
3.3. OAuth Access Token Types using Keyed Message Digests . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Successful Bearer Token Exchange . . . . . . . . . . . . 12
4.2. Successful OAuth 1.0a Token Exchange . . . . . . . . . . 13
4.3. Failed Exchange . . . . . . . . . . . . . . . . . . . . . 14
4.4. SMTP Example of a Failed Negotiation . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Internationalization Considerations . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. SASL Registration . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
OAuth 1.0a [RFC5849] and OAuth 2.0 [RFC6749] are protocol frameworks that enable a third-party application to obtain limited access to a protected resource, either by orchestrating an approval interaction on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.
OAuth 1.0a[RFC5849]和OAuth 2.0[RFC6749]是协议框架，通过协调代表资源所有者的批准交互或允许第三方应用程序代表自己获得访问权限，使第三方应用程序能够获得对受保护资源的有限访问。
The core OAuth 2.0 specification [RFC6749] specifies the interaction between the OAuth client and the authorization server; it does not define the interaction between the OAuth client and the resource server for the access to a protected resource using an access token. Instead, the OAuth client to resource server interaction is described in separate specifications, such as the bearer token specification [RFC6750]. OAuth 1.0a includes the protocol specification for the communication between the OAuth client and the resource server in [RFC5849].
核心OAuth 2.0规范[RFC6749]规定了OAuth客户端和授权服务器之间的交互；它没有定义OAuth客户端和资源服务器之间的交互，以便使用访问令牌访问受保护的资源。相反，OAuth客户机到资源服务器的交互在单独的规范中描述，例如承载令牌规范[RFC6750]。OAuth 1.0a在[RFC5849]中包含了OAuth客户端和资源服务器之间通信的协议规范。
The main use cases for OAuth 1.0a and OAuth 2.0 have so far focused on an HTTP-based [RFC7230] environment only. This document integrates OAuth 1.0a and OAuth 2.0 into non-HTTP-based applications using the integration into the Simple Authentication and Security Layer (SASL) [RFC4422]. Hence, this document takes advantage of the OAuth protocol and its deployment base to provide a way to use SASL to gain access to resources when using non-HTTP-based protocols, such as the Internet Message Access Protocol (IMAP) [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321]. This document gives examples of use in IMAP and SMTP.
到目前为止，OAuth 1.0a和OAuth 2.0的主要用例只关注基于HTTP的[RFC7230]环境。本文档使用与简单身份验证和安全层（SASL）的集成将OAuth 1.0a和OAuth 2.0集成到非基于HTTP的应用程序中[RFC4422]。因此，本文档利用OAuth协议及其部署基础，提供了一种在使用非基于HTTP的协议时使用SASL访问资源的方法，如Internet消息访问协议（IMAP）[RFC3501]和简单邮件传输协议（SMTP）[RFC5321]。本文档给出了在IMAP和SMTP中使用的示例。
To illustrate the impact of integrating this specification into an OAuth-enabled application environment, Figure 1 shows the abstract message flow of OAuth 2.0 [RFC6749]. As indicated in the figure, this document impacts the exchange of messages (E) and (F) since SASL is used for interaction between the client and the resource server instead of HTTP.
为了说明将此规范集成到支持OAuth的应用程序环境中的影响，图1显示了OAuth 2.0[RFC6749]的抽象消息流。如图所示，此文档影响消息（E）和（F）的交换，因为SASL用于客户端和资源服务器之间的交互，而不是HTTP。
----+
+--------+ +---------------+ |
| |--(A)-- Authorization Request --->| Resource | |
| | | Owner | |Plain
| |<-(B)------ Access Grant ---------| | |OAuth
| | +---------------+ |2.0
| | |
| | Client Credentials & +---------------+ |
| |--(C)------ Access Grant -------->| Authorization | |
| Client | | Server | |
| |<-(D)------ Access Token ---------| | |
| | (w/ Optional Refresh Token) +---------------+ |
| | ----+
| | ----+
| | +---------------+ |
| | | | |OAuth
| |--(E)------ Access Token -------->| Resource | |over
| | | Server | |SASL
| |<-(F)---- Protected Resource -----| | |
| | | | |
+--------+ +---------------+ |
----+
----+
+--------+ +---------------+ |
| |--(A)-- Authorization Request --->| Resource | |
| | | Owner | |Plain
| |<-(B)------ Access Grant ---------| | |OAuth
| | +---------------+ |2.0
| | |
| | Client Credentials & +---------------+ |
| |--(C)------ Access Grant -------->| Authorization | |
| Client | | Server | |
| |<-(D)------ Access Token ---------| | |
| | (w/ Optional Refresh Token) +---------------+ |
| | ----+
| | ----+
| | +---------------+ |
| | | | |OAuth
| |--(E)------ Access Token -------->| Resource | |over
| | | Server | |SASL
| |<-(F)---- Protected Resource -----| | |
| | | | |
+--------+ +---------------+ |
----+
Figure 1: OAuth 2.0 Protocol Flow
图1:OAuth2.0协议流
SASL is a framework for providing authentication and data security services in connection-oriented protocols via replaceable authentication mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing authentication mechanisms and allows old protocols to make use of new authentication mechanisms. The framework also provides a protocol for securing subsequent exchanges within a data security layer.
SASL是一个框架，用于通过可替换的身份验证机制在面向连接的协议中提供身份验证和数据安全服务。它提供了协议和机制之间的结构化接口。由此产生的框架允许新协议重用现有的身份验证机制，并允许旧协议使用新的身份验证机制。该框架还提供了一个协议，用于保护数据安全层内的后续交换。
When OAuth is integrated into SASL, the high-level steps are as follows:
当OAuth集成到SASL中时，高级步骤如下：
(A) The client requests authorization from the resource owner. The authorization request can be made directly to the resource owner (as shown) or indirectly via the authorization server as an intermediary.
（A） 客户端向资源所有者请求授权。授权请求可以直接向资源所有者发出（如图所示），也可以通过授权服务器作为中介间接发出。
(B) The client receives an authorization grant, which is a credential representing the resource owner's authorization, expressed using one of the grant types defined in [RFC6749] or [RFC5849] or using an extension grant type. The authorization grant type depends on the method used by the client to request
（B） 客户机接收授权授权，授权授权是表示资源所有者授权的凭证，使用[RFC6749]或[RFC5849]中定义的授权类型之一或使用扩展授权类型表示。授权授予类型取决于客户端用于请求的方法
authorization and the types supported by the authorization server.
授权和授权服务器支持的类型。
(C) The client requests an access token by authenticating with the authorization server and presenting the authorization grant.
（C） 客户端通过与授权服务器进行身份验证并提供授权授予来请求访问令牌。
(D) The authorization server authenticates the client and validates the authorization grant, and if valid, it issues an access token.
（D） 授权服务器对客户端进行身份验证，并验证授权授予，如果有效，则会发出访问令牌。
(E) The client requests the protected resource from the resource server and authenticates it by presenting the access token.
（E） 客户端从资源服务器请求受保护的资源，并通过提供访问令牌对其进行身份验证。
(F) The resource server validates the access token, and if valid, it indicates a successful authentication.
（F） 资源服务器验证访问令牌，如果有效，则表示身份验证成功。
Again, steps (E) and (F) are not defined in [RFC6749] (but are described in, for example, [RFC6750] for the OAuth bearer token instead) and are the main functionality specified within this document. Consequently, the message exchange shown in Figure 1 is the result of this specification. The client will generally need to determine the authentication endpoints (and perhaps the service endpoints) before the OAuth 2.0 protocol exchange messages in steps (A)-(D) are executed. The discovery of the resource owner, authorization server endpoints, and client registration are outside the scope of this specification. The client must discover the authorization endpoints using a discovery mechanism such as OpenID Connect Discovery (OIDCD) [OpenID.Discovery] or WebFinger using host-meta [RFC7033]. Once credentials are obtained, the client proceeds to steps (E) and (F) defined in this specification. Authorization endpoints MAY require client registration, and generic clients SHOULD support the Dynamic Client Registration protocol [RFC7591].
同样，步骤（E）和（F）未在[RFC6749]中定义（而是在[RFC6750]中针对OAuth承载令牌进行了描述），并且是本文档中指定的主要功能。因此，图1所示的消息交换是本规范的结果。在执行步骤（A）-（D）中的OAuth 2.0协议交换消息之前，客户端通常需要确定身份验证端点（可能还有服务端点）。资源所有者、授权服务器终结点和客户端注册的发现不在本规范的范围内。客户端必须使用发现机制（如OpenID Connect discovery（OIDCD）[OpenID.discovery]或使用主机元[RFC7033]的WebFinger）来发现授权端点。获得凭证后，客户机继续执行本规范中定义的步骤（E）和（F）。授权端点可能需要客户端注册，通用客户端应支持动态客户端注册协议[RFC7591]。
OAuth 1.0a follows a similar model but uses a different terminology and does not separate the resource server from the authorization server.
OAuth 1.0a遵循类似的模型，但使用不同的术语，并且没有将资源服务器与授权服务器分开。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The reader is assumed to be familiar with the terms used in the OAuth 2.0 specification [RFC6749] and SASL [RFC4422].
假定读者熟悉OAuth 2.0规范[RFC6749]和SASL[RFC4422]中使用的术语。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. Line breaks have been inserted for readability.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。为便于阅读，插入了换行符。
Note that the IMAP SASL specification requires base64 encoding, as specified in Section 4 of [RFC4648].
注意，IMAP SASL规范要求base64编码，如[RFC4648]第4节所述。
SASL is used as an authentication framework in a variety of application-layer protocols. This document defines the following SASL mechanisms for usage with OAuth:
SASL在各种应用层协议中用作身份验证框架。本文档定义了用于OAuth的以下SASL机制：
OAUTHBEARER: OAuth 2.0 bearer tokens, as described in [RFC6750]. RFC 6750 uses Transport Layer Security (TLS) [RFC5246] to secure the protocol interaction between the client and the resource server.
OAuthBearner:OAuth 2.0承载令牌，如[RFC6750]中所述。RFC 6750使用传输层安全性（TLS）[RFC5246]来保护客户端和资源服务器之间的协议交互。
OAUTH10A: OAuth 1.0a Message Authentication Code (MAC) tokens (using the HMAC-SHA1 keyed message digest), as described in Section 3.4.2 of [RFC5849].
OAUTH10A:OAuth 1.0a消息认证码（MAC）令牌（使用HMAC-SHA1密钥消息摘要），如[RFC5849]第3.4.2节所述。
New extensions may be defined to add additional OAuth Access Token Types. Such a new SASL OAuth mechanism can be added by registering the new name(s) with IANA in the SASL Mechanisms registry and citing this specification for the further definition.
可以定义新的扩展来添加额外的OAuth访问令牌类型。可以通过在SASL机制注册表中向IANA注册新名称并引用本规范进行进一步定义来添加这种新的SASL OAuth机制。
SASL mechanisms using this document as their definition do not provide a data security layer; that is, they cannot provide integrity or confidentiality protection for application messages after the initial authentication. If such protection is needed, TLS or some similar solution should be used. Additionally, for the two mechanisms specified in this document, TLS MUST be used for OAUTHBEARER to protect the bearer token; for OAUTH10A, the use of TLS is RECOMMENDED.
使用本文档作为定义的SASL机制不提供数据安全层；也就是说，在初始身份验证之后，它们不能为应用程序消息提供完整性或机密性保护。如果需要此类保护，应使用TLS或类似的解决方案。此外，对于本文档中指定的两种机制，OAuthBearner必须使用TLS来保护承载令牌；对于OAUTH10A，建议使用TLS。
These mechanisms are client initiated and in lockstep, with the server always replying to a client message. In the case where the client has and correctly uses a valid token, the flow is:
这些机制由客户机启动并处于锁定状态，服务器始终响应客户机消息。如果客户端拥有并正确使用有效令牌，则流为：
1. Client sends a valid and correct initial client response.
1. 客户端发送有效且正确的初始客户端响应。
2. Server responds with a successful authentication.
2. 服务器响应成功的身份验证。
In the case where authentication fails, the server sends an error result; the client MUST then send an additional message to the server in order to allow the server to finish the exchange. Some protocols and common SASL implementations do not support both sending a SASL
在认证失败的情况下，服务器发送错误结果；然后，客户端必须向服务器发送附加消息，以便服务器完成交换。某些协议和常见SASL实现不支持同时发送SASL
message and finalizing a SASL negotiation. The additional client message in the error case deals with this problem. This exchange is:
消息并完成SASL协商。错误案例中的附加客户端消息处理此问题。本交易所为：
1. Client sends an invalid initial client response.
1. 客户端发送无效的初始客户端响应。
2. Server responds with an error message.
2. 服务器响应一条错误消息。
3. Client sends a dummy client response.
3. 客户端发送一个虚拟客户端响应。
4. Server fails the authentication.
4. 服务器验证失败。
Client responses are a GS2 [RFC5801] header followed by zero or more key/value pairs, or it may be empty. The gs2-header rule is defined here as a placeholder for compatibility with GS2 if a GS2 mechanism is formally defined, but this document does not define one. The key/ value pairs take the place of the corresponding HTTP headers and values to convey the information necessary to complete an OAuth-style HTTP authorization. Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234] syntax is:
客户机响应是GS2[RFC5801]头，后跟零个或多个键/值对，也可以是空的。如果正式定义了gs2机制，则gs2标头规则在此处定义为与gs2兼容的占位符，但本文档未定义。键/值对取代相应的HTTP头和值，以传递完成OAuth样式HTTP授权所需的信息。服务器必须忽略未知的键/值对。ABNF[RFC5234]语法为：
kvsep = %x01
key = 1*(ALPHA)
value = *(VCHAR / SP / HTAB / CR / LF )
kvpair = key "=" value kvsep
;;gs2-header = See RFC 5801
client-resp = (gs2-header kvsep *kvpair kvsep) / kvsep
kvsep = %x01
key = 1*(ALPHA)
value = *(VCHAR / SP / HTAB / CR / LF )
kvpair = key "=" value kvsep
;;gs2-header = See RFC 5801
client-resp = (gs2-header kvsep *kvpair kvsep) / kvsep
The GS2 header MAY include the username associated with the resource being accessed, the "authzid". It is worth noting that application protocols are allowed to require an authzid, as are specific server implementations.
GS2报头可以包括与正在访问的资源相关联的用户名“authzid”。值得注意的是，允许应用程序协议需要authzid，具体的服务器实现也是如此。
The client response consisting of only a single kvsep is used only when authentication fails and is only valid in that context. If sent as the first message from the client, the server MAY simply fail the authentication without returning discovery information since there is no user or server name indication.
仅由单个kvsep组成的客户端响应仅在身份验证失败时使用，并且仅在该上下文中有效。如果作为来自客户端的第一条消息发送，服务器可能会在不返回发现信息的情况下使身份验证失败，因为没有用户名或服务器名指示。
The following keys and corresponding values are defined in the client response:
客户端响应中定义了以下键和相应的值：
auth (REQUIRED): The payload that would be in the HTTP Authorization header if this OAuth exchange was being carried out over HTTP.
auth（必需）：如果此OAuth交换是通过HTTP执行的，则HTTP授权头中的有效负载。
host: Contains the hostname to which the client connected. In an HTTP context, this is the value of the HTTP Host header.
主机：包含客户端连接到的主机名。在HTTP上下文中，这是HTTP主机头的值。
port: Contains the destination port that the client connected to, represented as a decimal positive integer string without leading zeros.
端口：包含客户端连接到的目标端口，表示为不带前导零的十进制正整数字符串。
For OAuth token types such as OAuth 1.0a that use keyed message digests, the client MUST send host and port number key/values, and the server MUST fail an authorization request requiring keyed message digests that are not accompanied by host and port values. In OAuth 1.0a, for example, the so-called "signature base string calculation" includes the reconstructed HTTP URL.
对于使用密钥消息摘要的OAuth令牌类型（如OAuth 1.0a），客户端必须发送主机和端口号密钥/值，服务器必须使要求密钥消息摘要的授权请求失败，该密钥消息摘要不附带主机和端口值。例如，在OAuth 1.0a中，所谓的“签名基字符串计算”包括重构的HTTP URL。
In these mechanisms, values for path, query string and post body are assigned default values. OAuth authorization schemes MAY define usage of these in the SASL context and extend this specification. For OAuth Access Token Types that include a keyed message digest of the request, the default values MUST be used unless explicit values are provided in the client response. The following key values are reserved for future use:
在这些机制中，path、查询字符串和post body的值被指定为默认值。OAuth授权方案可以在SASL上下文中定义这些方案的用法，并扩展此规范。对于包含请求的键控消息摘要的OAuth访问令牌类型，除非在客户端响应中提供了显式值，否则必须使用默认值。以下键值保留供将来使用：
mthd (RESERVED): HTTP method; the default value is "POST".
mthd（保留）：HTTP方法；默认值为“POST”。
path (RESERVED): HTTP path data; the default value is "/".
路径（保留）：HTTP路径数据；默认值为“/”。
post (RESERVED): HTTP post data; the default value is the empty string ("").
post（保留）：HTTP post数据；默认值为空字符串（“”）。
qs (RESERVED): The HTTP query string; the default value is the empty string ("").
qs（保留）：HTTP查询字符串；默认值为空字符串（“”）。
The server validates the response according to the specification for the OAuth Access Token Types used. If the OAuth Access Token Type utilizes a keyed message digest of the request parameters, then the client must provide a client response that satisfies the data requirements for the scheme in use.
服务器根据所使用的OAuth访问令牌类型的规范验证响应。如果OAuth访问令牌类型使用请求参数的键控消息摘要，则客户端必须提供满足所用方案的数据要求的客户端响应。
The server fully validates the client response before generating a server response; this will necessarily include the validation steps listed in the specification for the OAuth Access Token Type used. However, additional validation steps may be needed, depending on the particular application protocol making use of SASL. In particular, values included as kvpairs in the client response (such as host and
服务器在生成服务器响应之前完全验证客户端响应；这必然包括规范中列出的所用OAuth访问令牌类型的验证步骤。但是，根据使用SASL的特定应用程序协议，可能需要额外的验证步骤。特别是，在客户端响应中作为kvpairs包含的值（例如主机和
port) that correspond to values known to the application server by some other mechanism (such as an application protocol data unit or preconfigured values) MUST be validated to match between the initial client response and the other source(s) of such information. As a concrete example, when SASL is used over IMAP to an IMAP server for a single domain, the hostname can be available via configuration; this hostname must be validated to match the value sent in the 'host' kvpair.
必须验证与应用程序服务器通过某些其他机制（如应用程序协议数据单元或预配置值）已知的值相对应的端口，以使初始客户端响应与此类信息的其他源匹配。作为一个具体的例子，当SASL通过IMAP用于单个域的IMAP服务器时，主机名可以通过配置获得；必须验证此主机名以匹配在“主机”kvpair中发送的值。
The server responds to a successfully verified client message by completing the SASL negotiation. The authenticated identity reported by the SASL mechanism is the identity securely established for the client with the OAuth credential. The application, not the SASL mechanism, based on local access policy determines whether the identity reported by the mechanism is allowed access to the requested resource. Note that the semantics of the authzid are specified by the SASL framework [RFC4422].
服务器通过完成SASL协商来响应成功验证的客户端消息。SASL机制报告的经过身份验证的身份是使用OAuth凭据为客户端安全建立的身份。基于本地访问策略的应用程序（而不是SASL机制）确定是否允许机制报告的标识访问请求的资源。注意，authzid的语义由SASL框架[RFC4422]指定。
In the OAuth framework, the client may be authenticated by the authorization server, and the resource owner is authenticated to the authorization server. OAuth access tokens may contain information about the authentication of the resource owner and about the client and may therefore make this information accessible to the resource server.
在OAuth框架中，客户机可以通过授权服务器进行身份验证，而资源所有者可以通过授权服务器进行身份验证。OAuth访问令牌可能包含有关资源所有者身份验证和客户机的信息，因此可能使资源服务器可以访问这些信息。
If both identifiers are needed by an application the developer will need to provide a way to communicate that from the SASL mechanism back to the application.
如果一个应用程序需要这两个标识符，那么开发人员需要提供一种方法，将其从SASL机制传回应用程序。
For a failed authentication, the server returns an error result in JSON [RFC7159] format and fails the authentication. The error result consists of the following values:
对于失败的身份验证，服务器返回JSON[RFC7159]格式的错误结果，并使身份验证失败。错误结果由以下值组成：
status (REQUIRED): The authorization error code. Valid error codes are defined in the IANA "OAuth Extensions Error Registry" as specified in the OAuth 2.0 core specification.
状态（必需）：授权错误代码。按照OAuth 2.0核心规范的规定，IANA“OAuth扩展错误注册表”中定义了有效的错误代码。
scope (OPTIONAL): An OAuth scope that is valid to access the service. This may be omitted, which implies that unscoped tokens are required. If a scope is specified, then a single scope is preferred. At the time this document was written, there are several implementations that do not properly support space-separated lists of scopes, so the use of a space-separated list of scopes is NOT RECOMMENDED.
作用域（可选）：对访问服务有效的OAuth作用域。这可能会被忽略，这意味着需要非范围令牌。如果指定了范围，则首选单个范围。在编写本文档时，有几个实现不支持空间分隔的作用域列表，因此不建议使用空间分隔的作用域列表。
openid-configuration (OPTIONAL): The URL for a document following the OpenID Provider Configuration Information schema as described in OIDCD [OpenID.Discovery], Section 3 that is appropriate for the user. As specified in OIDCD, this will have the "https" URL scheme. This document MUST have all OAuth-related data elements populated. The server MAY return different URLs for users in different domains, and the client SHOULD NOT cache a single returned value and assume it applies for all users/domains that the server supports. The returned discovery document SHOULD have all data elements required by the OpenID Connect Discovery specification populated. In addition, the discovery document SHOULD contain the 'registration_endpoint' element to identify the endpoint to be used with the Dynamic Client Registration protocol [RFC7591] to obtain the minimum number of parameters necessary for the OAuth protocol exchange to function. Another comparable discovery or client registration mechanism MAY be used if available.
openid配置（可选）：遵循OIDCD[openid.Discovery]第3节中描述的适用于用户的openid提供程序配置信息模式的文档的URL。按照OIDCD中的规定，这将具有“https”URL方案。此文档必须填充所有与OAuth相关的数据元素。服务器可能会为不同域中的用户返回不同的URL，客户端不应缓存单个返回值，并假定它适用于服务器支持的所有用户/域。返回的发现文档应填充OpenID Connect发现规范所需的所有数据元素。此外，发现文档应包含“registration_endpoint”元素，以标识要与动态客户端注册协议[RFC7591]一起使用的端点，以获得OAuth协议交换运行所需的最小参数数。如果可用，可以使用另一种类似的发现或客户端注册机制。
The use of the 'offline_access' scope, as defined in [OpenID.Core], is RECOMMENDED to give clients the capability to explicitly request a refresh token.
建议使用[OpenID.Core]中定义的“offline_access”作用域，使客户端能够显式请求刷新令牌。
If the resource server provides a scope, then the client MUST always request scoped tokens from the token endpoint. If the resource server does not return a scope, the client SHOULD presume an unscoped token is required to access the resource.
如果资源服务器提供作用域，则客户端必须始终从令牌端点请求作用域令牌。如果资源服务器不返回作用域，则客户端应假定访问资源需要未作用域的令牌。
Since clients may interact with a number of application servers, such as email servers and Extensible Messaging and Presence Protocol (XMPP) [RFC6120] servers, they need to have a way to determine whether dynamic client registration has been performed already and whether an already available refresh token can be reused to obtain an access token for the desired resource server. This specification RECOMMENDS that a client uses the information in the 'iss' element defined in OpenID Connect Core [OpenID.Core] to make this determination.
由于客户端可能与许多应用服务器交互，例如电子邮件服务器和可扩展消息和状态协议（XMPP）[RFC6120]服务器，他们需要有一种方法来确定是否已经执行了动态客户端注册，以及是否可以重用已经可用的刷新令牌来获得所需资源服务器的访问令牌。本规范建议客户机使用OpenID Connect Core[OpenID.Core]中定义的“iss”元素中的信息进行此确定。
Section 3.6 of SASL [RFC4422] explicitly prohibits additional information in an unsuccessful authentication outcome. Therefore, the error message is sent in a normal message. The client MUST then send either an additional client response consisting of a single %x01 (control A) character to the server in order to allow the server to finish the exchange or a SASL abort message as generally defined in Section 3.5 of SASL [RFC4422]. A specific example of an abort message is the "BAD" response to an AUTHENTICATE in IMAP [RFC3501], Section 6.2.2.
SASL[RFC4422]第3.6节明确禁止在认证结果不成功时提供额外信息。因此，错误消息以正常消息的形式发送。然后，客户端必须向服务器发送由单个%x01（控制a）字符组成的附加客户端响应，以允许服务器完成交换，或者发送SASL中止消息，如SASL[RFC4422]第3.5节中的一般定义。中止消息的一个具体示例是对IMAP[RFC3501]第6.2.2节中认证的“错误”响应。
OAuth Access Token Types may use keyed message digests, and the client and the resource server may need to perform a cryptographic computation for integrity protection and data origin authentication.
OAuth访问令牌类型可以使用密钥消息摘要，客户端和资源服务器可能需要执行加密计算以实现完整性保护和数据源身份验证。
OAuth is designed for access to resources identified by URIs. SASL is designed for user authentication and has no facility for more fine-grained access control. In this specification, we require or define default values for the data elements from an HTTP request that allows the signature base string to be constructed properly. The default HTTP path is "/", and the default post body is empty. These atoms are defined as extension points so that no changes are needed if there is a revision of SASL that supports more specific resource authorization, e.g., IMAP access to a specific folder or FTP access limited to a specific directory.
OAuth是为访问URI标识的资源而设计的。SASL是为用户身份验证而设计的，没有更细粒度的访问控制功能。在本规范中，我们需要或定义HTTP请求中数据元素的默认值，以允许正确构造签名基字符串。默认HTTP路径为“/”，默认帖子正文为空。这些原子被定义为扩展点，因此，如果SASL的修订版支持更具体的资源授权，例如，对特定文件夹的IMAP访问或对特定目录的FTP访问，则无需进行更改。
Using the example in the OAuth 1.0a specification as a starting point, below is the authorization request in OAuth 1.0a style (with %x01 shown as ^A and line breaks added for readability), assuming it is on an IMAP server running on port 143:
以OAuth 1.0a规范中的示例为起点，下面是OAuth 1.0a样式的授权请求（其中%x01显示为^a，并添加了换行符以便于阅读），假设它位于端口143上运行的IMAP服务器上：
n,a=user@example.com,^A
host=example.com^A
port=143^A
auth=OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="Tm90IGEgcmVhbCBzaWduYXR1cmU"^A^A
n,a=user@example.com,^A
host=example.com^A
port=143^A
auth=OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="Tm90IGEgcmVhbCBzaWduYXR1cmU"^A^A
The signature base string would be constructed per the OAuth 1.0a specification [RFC5849] with the following things noted:
签名基字符串将根据OAuth 1.0a规范[RFC5849]构造，并注意以下事项：
o The method value is defaulted to POST.
o 方法值默认为POST。
o The scheme defaults to be "http", and any port number other than 80 is included.
o 方案默认为“http”，包括80以外的任何端口号。
o The path defaults to "/".
o 路径默认为“/”。
o The query string defaults to "".
o 查询字符串默认为“”。
In this example, the signature base string with line breaks added for readability would be:
在本例中，添加换行符以提高可读性的签名基字符串为：
POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4 8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_signature_method%3DHMAC-SH A1%26oauth_timestamp%3D137131201%26oauth_token%3Dkkk9d7dh3k39sjv7
POST&http%3A%2F%2Fexample.com:143%2F&oauth_consumer_key%3D9djdj82h4 8djs9d2%26oauth_nonce%3D7d8f3e4a%26oauth_签名_方法%3DHMAC-SH A1%26oauth_时间戳%3D137131201%26oauth_令牌%3DKKKKK9D7DH3K39SJV7
These examples illustrate exchanges between IMAP and SMTP clients and servers. All IMAP examples use SASL-IR [RFC4959] and send payload in the initial client response. The bearer token examples assume encrypted transport; if the underlying connection is not already TLS, then STARTTLS MUST be used as TLS is required in the bearer token specification.
这些示例演示了IMAP和SMTP客户端和服务器之间的交换。所有IMAP示例都使用SASL-IR[RFC4959]并在初始客户端响应中发送有效负载。承载令牌示例假定加密传输；如果基础连接还不是TLS，则必须使用STARTTLS，因为承载令牌规范中需要TLS。
Note to implementers: The SASL OAuth method names are case insensitive. One example uses "Bearer" but that could as easily be "bearer", "BEARER", or "BeArEr".
实现者注意：SASL OAuth方法名称不区分大小写。一个例子使用“承载人”，但也可以很容易地使用“承载人”、“承载人”或“承载人”。
This example shows a successful OAuth 2.0 bearer token exchange in IMAP. Note that line breaks are inserted for readability.
此示例显示了在IMAP中成功的OAuth 2.0承载令牌交换。请注意，插入换行符是为了可读性。
[Initial connection and TLS establishment...]
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhv
c3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyI
HZGOWRmdDRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQ
EB
S: t1 OK SASL authentication succeeded
[Initial connection and TLS establishment...]
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhv
c3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9QmVhcmVyI
HZGOWRmdDRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQ
EB
S: t1 OK SASL authentication succeeded
As required by IMAP [RFC3501], the payloads are base64 encoded. The decoded initial client response (with %x01 represented as ^A and long lines wrapped for readability) is:
根据IMAP[RFC3501]的要求，有效载荷采用base64编码。解码后的初始客户端响应（其中%x01表示为^A，并为可读性而包装了长行）为：
n,a=user@example.com,^Ahost=server.example.com^Aport=143^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
n,a=user@example.com,^Ahost=server.example.com^Aport=143^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
The same credential used in an SMTP exchange is shown below. Again, this example assumes that TLS is already established per the bearer token specification requirements.
SMTP交换中使用的相同凭据如下所示。同样，该示例假设已经根据承载令牌规范要求建立了TLS。
[connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584
S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250 PIPELINING
[Negotiate TLS...]
C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2Vy
dmVyLmV4YW1wbGUuY29tAXBvcnQ9NTg3AWF1dGg9QmVhcmVyIHZGOWRmd
DRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: 235 Authentication successful.
[connection continues...]
[connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584
S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES
S: 250-STARTTLS
S: 250 PIPELINING
[Negotiate TLS...]
C: t1 AUTH OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9c2Vy
dmVyLmV4YW1wbGUuY29tAXBvcnQ9NTg3AWF1dGg9QmVhcmVyIHZGOWRmd
DRxbVRjMk52YjNSbGNrQmhiSFJoZG1semRHRXVZMjl0Q2c9PQEB
S: 235 Authentication successful.
[connection continues...]
The decoded initial client response is:
解码的初始客户端响应是：
n,a=user@example.com,^Ahost=server.example.com^Aport=587^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
n,a=user@example.com,^Ahost=server.example.com^Aport=587^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg==^A^A
This IMAP example shows a successful OAuth 1.0a token exchange. Note that line breaks are inserted for readability. This example assumes that TLS is already established. Signature computation is discussed in Section 3.3.
此IMAP示例显示了成功的OAuth 1.0a令牌交换。请注意，插入换行符是为了可读性。本例假设TLS已经建立。第3.3节讨论了签名计算。
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER AUTH=OAUTH10A SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy
1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I
jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1
WVhSMWNtVSUzRCIBAQ==
S: t1 OK SASL authentication succeeded
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER AUTH=OAUTH10A SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTH10A bixhPXVzZXJAZXhhbXBsZS5jb20sAWhvc3Q9ZXhhb
XBsZS5jb20BcG9ydD0xNDMBYXV0aD1PQXV0aCByZWFsbT0iRXhhbXBsZSIsb2F1
dGhfY29uc3VtZXJfa2V5PSI5ZGpkajgyaDQ4ZGpzOWQyIixvYXV0aF90b2tlbj0
ia2trOWQ3ZGgzazM5c2p2NyIsb2F1dGhfc2lnbmF0dXJlX21ldGhvZD0iSE1BQy
1TSEExIixvYXV0aF90aW1lc3RhbXA9IjEzNzEzMTIwMSIsb2F1dGhfbm9uY2U9I
jdkOGYzZTRhIixvYXV0aF9zaWduYXR1cmU9IlRtOTBJR0VnY21WaGJDQnphV2R1
WVhSMWNtVSUzRCIBAQ==
S: t1 OK SASL authentication succeeded
As required by IMAP [RFC3501], the payloads are base64 encoded. The decoded initial client response (with %x01 represented as ^A and lines wrapped for readability) is:
根据IMAP[RFC3501]的要求，有效载荷采用base64编码。解码后的初始客户端响应（其中%x01表示为^A，为可读性而换行）为：
n,a=user@example.com,^A
host=example.com^A
port=143^A
auth=OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
n,a=user@example.com,^A
host=example.com^A
port=143^A
auth=OAuth realm="Example",
oauth_consumer_key="9djdj82h48djs9d2",
oauth_token="kkk9d7dh3k39sjv7",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131201",
oauth_nonce="7d8f3e4a",
oauth_signature="SSdtIGEgbGl0dGxlIHRlYSBwb3Qu"^A^A
This IMAP example shows a failed exchange because of the empty Authorization header, which is how a client can query for the needed scope. Note that line breaks are inserted for readability.
此IMAP示例显示了由于授权标头为空而导致的交换失败，这是客户端查询所需范围的方式。请注意，插入换行符是为了可读性。
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
C: AQ==
S: t1 NO SASL authentication failed
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
C: AQ==
S: t1 NO SASL authentication failed
The decoded initial client response is:
解码的初始客户端响应是：
n,a=user@example.com,^Ahost=server.example.com^A
port=143^Aauth=^A^A
n,a=user@example.com,^Ahost=server.example.com^A
port=143^Aauth=^A^A
The decoded server error response is:
解码的服务器错误响应为：
{
"status":"invalid_token",
"scope":"example_scope",
"openid-configuration":"https://example.com/.well-known/openid-config"
}
{
"status":"invalid_token",
"scope":"example_scope",
"openid-configuration":"https://example.com/.well-known/openid-config"
}
The client responds with the required dummy response; "AQ==" is the base64 encoding of the ASCII value 0x01. The same exchange using the IMAP-specific method of canceling an AUTHENTICATE command sends "*" and is shown below.
客户机以所需的虚拟响应进行响应；“AQ==”是ASCII值0x01的base64编码。使用IMAP特定方法取消验证命令的同一交换发送“*”，如下所示。
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
C: *
S: t1 NO SASL authentication failed
S: * OK IMAP4rev1 Server Ready
C: t0 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR IMAP4rev1
S: t0 OK Completed
C: t1 AUTHENTICATE OAUTHBEARER bixhPXVzZXJAZXhhbXBsZS5jb20sAW
hvc3Q9c2VydmVyLmV4YW1wbGUuY29tAXBvcnQ9MTQzAWF1dGg9AQE=
S: + eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NvcGUiOiJleGFtcGxl
X3Njb3BlIiwib3BlbmlkLWNvbmZpZ3VyYXRpb24iOiJodHRwczovL2V4
YW1wbGUuY29tLy53ZWxsLWtub3duL29wZW5pZC1jb25maWd1cmF0aW9u
In0=
C: *
S: t1 NO SASL authentication failed
This example shows an authorization failure in an SMTP exchange. TLS negotiation is not shown, but as noted above, it is required for the use of bearer tokens.
此示例显示SMTP exchange中的授权失败。未显示TLS协商，但如上所述，使用承载令牌需要TLS协商。
[connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584
S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES
S: 250 PIPELINING
[Negotiate TLS...]
C: AUTH OAUTHBEARER bix1c2VyPXNvbWV1c2VyQGV4YW1wbGUuY29tLAFhdXRoPUJlYXJl
ciB2RjlkZnQ0cW1UYzJOdmIzUmxja0JoZEhSaGRtbHpkR0V1WTI5dENnPT0BAQ==
S: 334 eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NoZW1lcyI6ImJlYXJlciBtYWMiL
CJzY29wZSI6Imh0dHBzOi8vbWFpbC5leGFtcGxlLmNvbS8ifQ==
C: AQ==
S: 535-5.7.1 Username and Password not accepted. Learn more at
S: 535 5.7.1 http://support.example.com/mail/oauth
[connection continues...]
[connection begins]
S: 220 mx.example.com ESMTP 12sm2095603fks.9
C: EHLO sender.example.com
S: 250-mx.example.com at your service,[172.31.135.47]
S: 250-SIZE 35651584
S: 250-8BITMIME
S: 250-AUTH LOGIN PLAIN OAUTHBEARER
S: 250-ENHANCEDSTATUSCODES
S: 250 PIPELINING
[Negotiate TLS...]
C: AUTH OAUTHBEARER bix1c2VyPXNvbWV1c2VyQGV4YW1wbGUuY29tLAFhdXRoPUJlYXJl
ciB2RjlkZnQ0cW1UYzJOdmIzUmxja0JoZEhSaGRtbHpkR0V1WTI5dENnPT0BAQ==
S: 334 eyJzdGF0dXMiOiJpbnZhbGlkX3Rva2VuIiwic2NoZW1lcyI6ImJlYXJlciBtYWMiL
CJzY29wZSI6Imh0dHBzOi8vbWFpbC5leGFtcGxlLmNvbS8ifQ==
C: AQ==
S: 535-5.7.1 Username and Password not accepted. Learn more at
S: 535 5.7.1 http://support.example.com/mail/oauth
[connection continues...]
The initial client response is:
客户的初始响应是：
n,user=someuser@example.com,^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhdHRhdmlzdGEuY29tCg==^A^A
n,user=someuser@example.com,^A
auth=Bearer vF9dft4qmTc2Nvb3RlckBhdHRhdmlzdGEuY29tCg==^A^A
The server returned an error message in the 334 SASL message; the client responds with the required dummy response, and the server finalizes the negotiation.
服务器在334 SASL消息中返回错误消息；客户端使用所需的虚拟响应进行响应，服务器完成协商。
{
"status":"invalid_token",
"schemes":"bearer mac",
"scope":"https://mail.example.com/"
}
{
"status":"invalid_token",
"schemes":"bearer mac",
"scope":"https://mail.example.com/"
}
OAuth 1.0a and OAuth 2.0 allow for a variety of deployment scenarios, and the security properties of these profiles vary. As shown in Figure 1, this specification is aimed to be integrated into a larger OAuth deployment. Application developers therefore need to understand their security requirements based on a threat assessment before selecting a specific SASL OAuth mechanism. For OAuth 2.0, a detailed security document [RFC6819] provides guidance to select those OAuth 2.0 components that help to mitigate threats for a given deployment. For OAuth 1.0a, Section 4 of [RFC5849] provides guidance specific to OAuth 1.0a.
OAuth 1.0a和OAuth 2.0允许各种部署场景，并且这些概要文件的安全属性各不相同。如图1所示，该规范旨在集成到更大的OAuth部署中。因此，在选择特定的SASL OAuth机制之前，应用程序开发人员需要根据威胁评估了解他们的安全需求。对于OAuth 2.0，详细的安全文档[RFC6819]提供了选择有助于缓解给定部署威胁的OAuth 2.0组件的指导。对于OAuth 1.0a，[RFC5849]的第4节提供了特定于OAuth 1.0a的指南。
This document specifies two SASL Mechanisms for OAuth and each comes with different security properties.
本文档为OAuth指定了两种SASL机制，每种机制都具有不同的安全属性。
OAUTHBEARER: This mechanism borrows from OAuth 2.0 bearer tokens [RFC6750]. It relies on the application using TLS to protect the OAuth 2.0 bearer token exchange; without TLS usage at the application layer, this method is completely insecure. Consequently, TLS MUST be provided by the application when choosing this authentication mechanism.
OAuthBearner：该机制借用OAuth 2.0承载令牌[RFC6750]。它依赖于使用TLS的应用程序来保护OAuth 2.0承载令牌交换；如果在应用层不使用TLS，这种方法是完全不安全的。因此，在选择此身份验证机制时，应用程序必须提供TLS。
OAUTH10A: This mechanism reuses OAuth 1.0a MAC tokens (using the HMAC-SHA1 keyed message digest), as described in Section 3.4.2 of [RFC5849]. To compute the keyed message digest in the same way as in RFC 5839, this specification conveys additional parameters between the client and the server. This SASL mechanism only supports client authentication. If server-side authentication is desirable, then it must be provided by the application underneath the SASL layer. The use of TLS is strongly RECOMMENDED.
OAUTH10A：该机制重用OAuth 1.0a MAC令牌（使用HMAC-SHA1键控消息摘要），如[RFC5849]第3.4.2节所述。为了以与RFC 5839中相同的方式计算键控消息摘要，此规范在客户端和服务器之间传递附加参数。此SASL机制仅支持客户端身份验证。如果需要服务器端身份验证，那么它必须由SASL层下面的应用程序提供。强烈建议使用TLS。
Additionally, the following aspects are worth pointing out:
此外，以下方面值得指出：
An access token is not equivalent to the user's long term password.
访问令牌不等同于用户的长期密码。
Care has to be taken when these OAuth credentials are used for actions like changing passwords (as it is possible with some protocols, e.g., XMPP [RFC6120]). The resource server should ensure that actions taken in the authenticated channel are appropriate to the strength of the presented credential.
当这些OAuth凭据用于更改密码等操作时，必须小心（因为某些协议可能会更改密码，例如XMPP[RFC6120]）。资源服务器应确保在经过身份验证的通道中采取的操作适合于所提供凭据的强度。
Lifetime of the application sessions.
应用程序会话的生存期。
It is possible that SASL will be used to authenticate a connection, and the life of that connection may outlast the life of the access token used to establish it. This is a common problem in application protocols where connections are long lived and not a problem with this mechanism, per se. Resource servers may unilaterally disconnect clients in accordance with the application protocol.
SASL可能用于验证连接，并且该连接的寿命可能超过用于建立连接的访问令牌的寿命。这是应用程序协议中的一个常见问题，在应用程序协议中，连接是长期存在的，而这种机制本身并不存在问题。资源服务器可以根据应用协议单方面断开客户端的连接。
Access tokens have a lifetime.
访问令牌具有生存期。
Reducing the lifetime of an access token provides security benefits, and OAuth 2.0 introduces refresh tokens to obtain new access tokens on the fly without any need for human interaction. Additionally, a previously obtained access token might be revoked or rendered invalid at any time. The client MAY request a new access token for each connection to a resource server, but it SHOULD cache and reuse valid credentials.
缩短访问令牌的生命周期提供了安全优势，OAuth 2.0引入了刷新令牌，以在不需要任何人工交互的情况下动态获取新的访问令牌。此外，以前获得的访问令牌可能随时被撤销或变得无效。客户端可以为每个到资源服务器的连接请求一个新的访问令牌，但它应该缓存和重用有效的凭据。
The identifier asserted by the OAuth authorization server about the resource owner inside the access token may be displayed to a human. For example, when SASL is used in the context of IMAP, the client may assert the resource owner's email address to the IMAP server for usage in an email-based application. The identifier may therefore contain internationalized characters, and an application needs to ensure that the mapping between the identifier provided by OAuth is suitable for use with the application-layer protocol SASL is incorporated into. An example of a SASL-compatible container is the JSON Web Token (JWT) [RFC7519], which provides a standardized format for exchanging authorization and identity information that supports internationalized characters.
OAuth授权服务器断言的关于访问令牌内的资源所有者的标识符可以显示给人。例如，当在IMAP上下文中使用SASL时，客户端可以向IMAP服务器声明资源所有者的电子邮件地址，以便在基于电子邮件的应用程序中使用。因此，标识符可能包含国际化字符，应用程序需要确保OAuth提供的标识符之间的映射适合与应用层协议SASL结合使用。与SASL兼容的容器的一个示例是JSON Web令牌（JWT）[RFC7519]，它提供了一种标准格式，用于交换支持国际化字符的授权和身份信息。
The IANA has registered the following entry in the SASL Mechanisms registry:
IANA已在SASL机制注册表中注册了以下条目：
SASL mechanism name: OAUTHBEARER
SASL机制名称：OAUTHBEARER
Security Considerations: See this document
安全注意事项：请参阅本文档
Published Specification: See this document
发布的规范：参见本文档
For further information: Contact the authors of this document.
有关更多信息：请与本文档的作者联系。
Intended usage: COMMON
预期用途：普通
Owner/Change controller: the IESG
所有者/变更控制人：IESG
Note: None
注：无
The IANA has registered the following entry in the SASL Mechanisms registry:
IANA已在SASL机制注册表中注册了以下条目：
SASL mechanism name: OAUTH10A
SASL机构名称：OAUTH10A
Security Considerations: See this document
安全注意事项：请参阅本文档
Published Specification: See this document
发布的规范：参见本文档
For further information: Contact the authors of this document.
有关更多信息：请与本文档的作者联系。
Intended usage: COMMON
预期用途：普通
Owner/Change controller: the IESG
所有者/变更控制人：IESG
Note: None
注：无
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core]北樱村、J.布拉德利、M.琼斯、B.德梅德罗斯和C.莫蒂莫尔，“OpenID连接核心1.0”，2014年11月<http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.
[OpenID.Discovery]北樱村、J.布拉德利、M.琼斯和E.杰伊，“OpenID连接发现1.0”，2014年11月<http://openid.net/specs/ openid-connect-discovery-1_0.html>。
[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>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.
[RFC4422]Melnikov，A.，Ed.和K.Zeilenga，Ed.，“简单身份验证和安全层（SASL）”，RFC 4422，DOI 10.17487/RFC4422，2006年6月<http://www.rfc-editor.org/info/rfc4422>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, July 2010, <http://www.rfc-editor.org/info/rfc5801>.
[RFC5801]Josefsson，S.和N.Williams，“在简单身份验证和安全层（SASL）中使用通用安全服务应用程序接口（GSS-API）机制：GS2机制系列”，RFC 5801，DOI 10.17487/RFC5801，2010年7月<http://www.rfc-editor.org/info/rfc5801>.
[RFC5849] Hammer-Lahav, E., Ed., "The OAuth 1.0 Protocol", RFC 5849, DOI 10.17487/RFC5849, April 2010, <http://www.rfc-editor.org/info/rfc5849>.
[RFC5849]Hammer Lahav，E.，编辑，“OAuth 1.0协议”，RFC 5849，DOI 10.17487/RFC5849，2010年4月<http://www.rfc-editor.org/info/rfc5849>.
[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>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]Jones，M.和D.Hardt，“OAuth 2.0授权框架：承载令牌使用”，RFC 6750，DOI 10.17487/RFC6750，2012年10月<http://www.rfc-editor.org/info/rfc6750>.
[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>.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <http://www.rfc-editor.org/info/rfc7591>.
[RFC7591]Richer，J.，Ed.，Jones，M.，Bradley，J.，Machulak，M.，和P.Hunt，“OAuth 2.0动态客户端注册协议”，RFC 7591，DOI 10.17487/RFC7591，2015年7月<http://www.rfc-editor.org/info/rfc7591>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <http://www.rfc-editor.org/info/rfc3501>.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 3501，DOI 10.17487/RFC3501，2003年3月<http://www.rfc-editor.org/info/rfc3501>.
[RFC4959] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", RFC 4959, DOI 10.17487/RFC4959, September 2007, <http://www.rfc-editor.org/info/rfc4959>.
[RFC4959]Siemborski，R.和A.Gulbrandsen，“简单身份验证和安全层（SASL）初始客户端响应的IMAP扩展”，RFC 4959，DOI 10.17487/RFC4959，2007年9月<http://www.rfc-editor.org/info/rfc4959>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://www.rfc-editor.org/info/rfc6120>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013, <http://www.rfc-editor.org/info/rfc6819>.
[RFC6819]Lodderstet，T.，Ed.，McGloin，M.，和P.Hunt，“OAuth 2.0威胁模型和安全考虑”，RFC 6819，DOI 10.17487/RFC6819，2013年1月<http://www.rfc-editor.org/info/rfc6819>.
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <http://www.rfc-editor.org/info/rfc7033>.
[RFC7033]Jones，P.，Salgueiro，G.，Jones，M.，和J.Smarr，“网络手指”，RFC 7033，DOI 10.17487/RFC70332013年9月<http://www.rfc-editor.org/info/rfc7033>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7519] 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>.
[RFC7519]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络令牌（JWT）”，RFC 7519，DOI 10.17487/RFC7519，2015年5月<http://www.rfc-editor.org/info/rfc7519>.
Acknowledgements
致谢
The authors would like to thank the members of the KITTEN working group and in addition and specifically: Simon Josefson, Torsten Lodderstadt, Ryan Troll, Alexey Melnikov, Jeffrey Hutzelman, Nico Williams, Matt Miller, and Benjamin Kaduk.
作者要特别感谢小猫工作组的成员：Simon Josefson、Torsten Lodderstad、Ryan Troll、Alexey Melnikov、Jeffrey Hutzelman、Nico Williams、Matt Miller和Benjamin Kaduk。
This document was produced under the chairmanship of Alexey Melnikov, Tom Yu, Shawn Emery, Josh Howlett, Sam Hartman, Matthew Miller, and Benjamin Kaduk. The supervising Area Director was Stephen Farrell.
本文件由Alexey Melnikov、Tom Yu、Shawn Emery、Josh Howlett、Sam Hartman、Matthew Miller和Benjamin Kaduk担任主席。监督区域主任是斯蒂芬·法雷尔。
Authors' Addresses
作者地址
William Mills Microsoft
威廉·米尔斯微软公司
Email: wmills_92105@yahoo.com
Email: wmills_92105@yahoo.com
Tim Showalter
蒂姆·肖沃尔特
Email: tjs@psaux.com
Email: tjs@psaux.com
Hannes Tschofenig ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ United Kingdom
Hannes Tschofenig ARM Ltd.英国剑桥CB1 9NJ富尔伯恩路110号
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at