Internet Engineering Task Force (IETF) N. Sakimura, Ed.
Request for Comments: 7636 Nomura Research Institute
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Agarwal
Google
September 2015
Internet Engineering Task Force (IETF) N. Sakimura, Ed.
Request for Comments: 7636 Nomura Research Institute
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
N. Agarwal
Google
September 2015
Proof Key for Code Exchange by OAuth Public Clients
OAuth公共客户端代码交换的验证密钥
Abstract
摘要
OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy").
使用授权码授权的OAuth 2.0公共客户端容易受到授权码截获攻击。本规范描述了攻击以及通过使用代码交换验证密钥（PKCE，发音为“pixy”）来缓解威胁的技术。
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/rfc7636.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7636.
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
1.1. Protocol Flow ..............................................5
2. Notational Conventions ..........................................6
3. Terminology .....................................................7
3.1. Abbreviations ..............................................7
4. Protocol ........................................................8
4.1. Client Creates a Code Verifier .............................8
4.2. Client Creates the Code Challenge ..........................8
4.3. Client Sends the Code Challenge with the
Authorization Request ......................................9
4.4. Server Returns the Code ....................................9
4.4.1. Error Response ......................................9
4.5. Client Sends the Authorization Code and the Code
Verifier to the Token Endpoint ............................10
4.6. Server Verifies code_verifier before Returning the
Tokens ....................................................10
5. Compatibility ..................................................11
6. IANA Considerations ............................................11
6.1. OAuth Parameters Registry .................................11
6.2. PKCE Code Challenge Method Registry .......................11
6.2.1. Registration Template ..............................12
6.2.2. Initial Registry Contents ..........................13
7. Security Considerations ........................................13
7.1. Entropy of the code_verifier ..............................13
7.2. Protection against Eavesdroppers ..........................13
7.3. Salting the code_challenge ................................14
7.4. OAuth Security Considerations .............................14
7.5. TLS Security Considerations ...............................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Appendix A. Notes on Implementing Base64url Encoding without
Padding .............................................17
Appendix B. Example for the S256 code_challenge_method ...........17
Acknowledgements ..................................................19
Authors' Addresses ................................................20
1. Introduction ....................................................3
1.1. Protocol Flow ..............................................5
2. Notational Conventions ..........................................6
3. Terminology .....................................................7
3.1. Abbreviations ..............................................7
4. Protocol ........................................................8
4.1. Client Creates a Code Verifier .............................8
4.2. Client Creates the Code Challenge ..........................8
4.3. Client Sends the Code Challenge with the
Authorization Request ......................................9
4.4. Server Returns the Code ....................................9
4.4.1. Error Response ......................................9
4.5. Client Sends the Authorization Code and the Code
Verifier to the Token Endpoint ............................10
4.6. Server Verifies code_verifier before Returning the
Tokens ....................................................10
5. Compatibility ..................................................11
6. IANA Considerations ............................................11
6.1. OAuth Parameters Registry .................................11
6.2. PKCE Code Challenge Method Registry .......................11
6.2.1. Registration Template ..............................12
6.2.2. Initial Registry Contents ..........................13
7. Security Considerations ........................................13
7.1. Entropy of the code_verifier ..............................13
7.2. Protection against Eavesdroppers ..........................13
7.3. Salting the code_challenge ................................14
7.4. OAuth Security Considerations .............................14
7.5. TLS Security Considerations ...............................15
8. References .....................................................15
8.1. Normative References ......................................15
8.2. Informative References ....................................16
Appendix A. Notes on Implementing Base64url Encoding without
Padding .............................................17
Appendix B. Example for the S256 code_challenge_method ...........17
Acknowledgements ..................................................19
Authors' Addresses ................................................20
OAuth 2.0 [RFC6749] public clients are susceptible to the authorization code interception attack.
OAuth 2.0[RFC6749]公共客户端容易受到授权码拦截攻击。
In this attack, the attacker intercepts the authorization code returned from the authorization endpoint within a communication path not protected by Transport Layer Security (TLS), such as inter-application communication within the client's operating system.
在此攻击中，攻击者在不受传输层安全性（TLS）保护的通信路径内截获从授权端点返回的授权代码，例如客户端操作系统内的应用程序间通信。
Once the attacker has gained access to the authorization code, it can use it to obtain the access token.
一旦攻击者获得了对授权代码的访问权，就可以使用它来获取访问令牌。
Figure 1 shows the attack graphically. In step (1), the native application running on the end device, such as a smartphone, issues an OAuth 2.0 Authorization Request via the browser/operating system. The Redirection Endpoint URI in this case typically uses a custom URI scheme. Step (1) happens through a secure API that cannot be intercepted, though it may potentially be observed in advanced attack scenarios. The request then gets forwarded to the OAuth 2.0 authorization server in step (2). Because OAuth requires the use of TLS, this communication is protected by TLS and cannot be intercepted. The authorization server returns the authorization code in step (3). In step (4), the Authorization Code is returned to the requester via the Redirection Endpoint URI that was provided in step (1).
图1以图形方式显示了攻击。在步骤（1）中，终端设备（如智能手机）上运行的本机应用程序通过浏览器/操作系统发出OAuth 2.0授权请求。在这种情况下，重定向端点URI通常使用自定义URI方案。第（1）步是通过一个无法被拦截的安全API进行的，尽管在高级攻击场景中可能会观察到它。然后在步骤（2）中将请求转发到OAuth 2.0授权服务器。因为OAuth需要使用TLS，所以该通信受TLS保护，不能被拦截。授权服务器在步骤（3）中返回授权代码。在步骤（4）中，授权代码通过在步骤（1）中提供的重定向端点URI返回给请求者。
Note that it is possible for a malicious app to register itself as a handler for the custom scheme in addition to the legitimate OAuth 2.0 app. Once it does so, the malicious app is now able to intercept the authorization code in step (4). This allows the attacker to request and obtain an access token in steps (5) and (6), respectively.
请注意，除了合法的OAuth 2.0应用程序之外，恶意应用程序还可能将自己注册为自定义方案的处理程序。一旦这样做了，恶意应用程序现在就能够在步骤（4）中拦截授权代码。这允许攻击者分别在步骤（5）和（6）中请求和获取访问令牌。
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| End Device (e.g., Smartphone) |
| |
| +-------------+ +----------+ | (6) Access Token +----------+
| |Legitimate | | Malicious|<--------------------| |
| |OAuth 2.0 App| | App |-------------------->| |
| +-------------+ +----------+ | (5) Authorization | |
| | ^ ^ | Grant | |
| | \ | | | |
| | \ (4) | | | |
| (1) | \ Authz| | | |
| Authz| \ Code | | | Authz |
| Request| \ | | | Server |
| | \ | | | |
| | \ | | | |
| v \ | | | |
| +----------------------------+ | | |
| | | | (3) Authz Code | |
| | Operating System/ |<--------------------| |
| | Browser |-------------------->| |
| | | | (2) Authz Request | |
| +----------------------------+ | +----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| End Device (e.g., Smartphone) |
| |
| +-------------+ +----------+ | (6) Access Token +----------+
| |Legitimate | | Malicious|<--------------------| |
| |OAuth 2.0 App| | App |-------------------->| |
| +-------------+ +----------+ | (5) Authorization | |
| | ^ ^ | Grant | |
| | \ | | | |
| | \ (4) | | | |
| (1) | \ Authz| | | |
| Authz| \ Code | | | Authz |
| Request| \ | | | Server |
| | \ | | | |
| | \ | | | |
| v \ | | | |
| +----------------------------+ | | |
| | | | (3) Authz Code | |
| | Operating System/ |<--------------------| |
| | Browser |-------------------->| |
| | | | (2) Authz Request | |
| +----------------------------+ | +----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
Figure 1: Authorization Code Interception Attack
图1：授权码拦截攻击
A number of pre-conditions need to hold for this attack to work:
要使此攻击起作用，需要具备一些先决条件：
1. The attacker manages to register a malicious application on the client device and registers a custom URI scheme that is also used by another application. The operating systems must allow a custom URI scheme to be registered by multiple applications.
1. 攻击者设法在客户端设备上注册恶意应用程序，并注册另一应用程序也使用的自定义URI方案。操作系统必须允许多个应用程序注册自定义URI方案。
2. The OAuth 2.0 authorization code grant is used.
2. 使用OAuth 2.0授权码授权。
3. The attacker has access to the OAuth 2.0 [RFC6749] "client_id" and "client_secret" (if provisioned). All OAuth 2.0 native app client-instances use the same "client_id". Secrets provisioned in client binary applications cannot be considered confidential.
3. 攻击者可以访问OAuth 2.0[RFC6749]“客户端id”和“客户端机密”（如果已设置）。所有OAuth 2.0本机应用程序客户端实例都使用相同的“客户端id”。客户端二进制应用程序中提供的机密不能视为机密。
4. Either one of the following condition is met:
4. 满足以下任一条件：
4a. The attacker (via the installed application) is able to observe only the responses from the authorization endpoint. When "code_challenge_method" value is "plain", only this attack is mitigated.
4a。攻击者（通过安装的应用程序）只能观察来自授权端点的响应。当“code\u challenge\u method”值为“plain”时，只有此攻击得到缓解。
4b. A more sophisticated attack scenario allows the attacker to observe requests (in addition to responses) to the authorization endpoint. The attacker is, however, not able to act as a man in the middle. This was caused by leaking http log information in the OS. To mitigate this, "code_challenge_method" value must be set either to "S256" or a value defined by a cryptographically secure "code_challenge_method" extension.
4b。更复杂的攻击场景允许攻击者观察对授权端点的请求（以及响应）。然而，攻击者不能充当中间人。这是由操作系统中的http日志信息泄漏引起的。为了缓解这种情况，必须将“code\u challenge\u method”值设置为“S256”或由加密安全的“code\u challenge\u method”扩展定义的值。
While this is a long list of pre-conditions, the described attack has been observed in the wild and has to be considered in OAuth 2.0 deployments. While the OAuth 2.0 threat model (Section 4.4.1 of [RFC6819]) describes mitigation techniques, they are, unfortunately, not applicable since they rely on a per-client instance secret or a per-client instance redirect URI.
虽然这是一长串的先决条件，但所描述的攻击已经在野外观察到，并且必须在OAuth 2.0部署中加以考虑。虽然OAuth 2.0威胁模型（RFC6819的第4.4.1节）描述了缓解技术，但不幸的是，它们不适用，因为它们依赖于每个客户端实例的机密或每个客户端实例的重定向URI。
To mitigate this attack, this extension utilizes a dynamically created cryptographically random key called "code verifier". A unique code verifier is created for every authorization request, and its transformed value, called "code challenge", is sent to the authorization server to obtain the authorization code. The authorization code obtained is then sent to the token endpoint with the "code verifier", and the server compares it with the previously received request code so that it can perform the proof of possession of the "code verifier" by the client. This works as the mitigation since the attacker would not know this one-time key, since it is sent over TLS and cannot be intercepted.
为了减轻这种攻击，此扩展使用动态创建的加密随机密钥，称为“代码验证器”。为每个授权请求创建一个唯一的代码验证器，并将其转换后的值（称为“代码质询”）发送到授权服务器以获取授权代码。然后将获得的授权码与“代码验证器”一起发送到令牌端点，并且服务器将其与先前接收到的请求码进行比较，以便它能够执行客户端对“代码验证器”的占有证明。这是一种缓解措施，因为攻击者不知道此一次性密钥，因为它是通过TLS发送的，无法被拦截。
+-------------------+
| Authz Server |
+--------+ | +---------------+ |
| |--(A)- Authorization Request ---->| | |
| | + t(code_verifier), t_m | | Authorization | |
| | | | Endpoint | |
| |<-(B)---- Authorization Code -----| | |
| | | +---------------+ |
| Client | | |
| | | +---------------+ |
| |--(C)-- Access Token Request ---->| | |
| | + code_verifier | | Token | |
| | | | Endpoint | |
| |<-(D)------ Access Token ---------| | |
+--------+ | +---------------+ |
+-------------------+
+-------------------+
| Authz Server |
+--------+ | +---------------+ |
| |--(A)- Authorization Request ---->| | |
| | + t(code_verifier), t_m | | Authorization | |
| | | | Endpoint | |
| |<-(B)---- Authorization Code -----| | |
| | | +---------------+ |
| Client | | |
| | | +---------------+ |
| |--(C)-- Access Token Request ---->| | |
| | + code_verifier | | Token | |
| | | | Endpoint | |
| |<-(D)------ Access Token ---------| | |
+--------+ | +---------------+ |
+-------------------+
Figure 2: Abstract Protocol Flow
图2：抽象协议流
This specification adds additional parameters to the OAuth 2.0 Authorization and Access Token Requests, shown in abstract form in Figure 2.
该规范为OAuth 2.0授权和访问令牌请求添加了额外的参数，如图2所示。
A. The client creates and records a secret named the "code_verifier" and derives a transformed version "t(code_verifier)" (referred to as the "code_challenge"), which is sent in the OAuth 2.0 Authorization Request along with the transformation method "t_m".
A.客户机创建并记录一个名为“code_verifier”的秘密，并派生一个转换版本“t（code_verifier）”（称为“code_Challenger”），它与转换方法“t_m”一起在OAuth 2.0授权请求中发送。
B. The Authorization Endpoint responds as usual but records "t(code_verifier)" and the transformation method.
B.授权端点像往常一样响应，但记录“t（代码\验证器）”和转换方法。
C. The client then sends the authorization code in the Access Token Request as usual but includes the "code_verifier" secret generated at (A).
C.然后，客户端像往常一样在访问令牌请求中发送授权码，但包括在（A）处生成的“代码验证器”秘密。
D. The authorization server transforms "code_verifier" and compares it to "t(code_verifier)" from (B). Access is denied if they are not equal.
D.授权服务器转换“代码验证器”，并将其与（B）中的“t（代码验证器）”进行比较。如果它们不相等，访问将被拒绝。
An attacker who intercepts the authorization code at (B) is unable to redeem it for an access token, as they are not in possession of the "code_verifier" secret.
在（B）处截获授权码的攻击者无法将其兑换为访问令牌，因为他们不拥有“code_verifier”机密。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. If these words are used without being spelled in uppercase, then they are to be interpreted with their natural language meanings.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照“RFC中用于表示要求水平的关键词”[RFC2119]中的描述进行解释。如果使用这些单词时未使用大写字母，则应按照其自然语言含义进行解释。
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234].
本规范使用[RFC5234]的增广巴科斯诺尔形式（ABNF）符号。
STRING denotes a sequence of zero or more ASCII [RFC20] characters.
字符串表示零个或多个ASCII[RFC20]字符的序列。
OCTETS denotes a sequence of zero or more octets.
八位字节表示零个或多个八位字节的序列。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING where STRING is a sequence of zero or more ASCII characters.
ASCII（字符串）表示字符串的ASCII[RFC20]表示的八位字节，其中字符串是零个或多个ASCII字符的序列。
BASE64URL-ENCODE(OCTETS) denotes the base64url encoding of OCTETS, per Appendix A, producing a STRING.
BASE64URL-ENCODE（八位字节）表示八位字节的BASE64URL编码，根据附录A，生成字符串。
BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Appendix A, producing a sequence of octets.
BASE64URL-DECODE（字符串）表示根据附录A对字符串进行的BASE64URL解码，产生八位字节序列。
SHA256(OCTETS) denotes a SHA2 256-bit hash [RFC6234] of OCTETS.
SHA256（八位字节）表示八位字节的SHA256位哈希[RFC6234]。
In addition to the terms defined in OAuth 2.0 [RFC6749], this specification defines the following terms:
除了OAuth 2.0[RFC6749]中定义的术语外，本规范还定义了以下术语：
code verifier A cryptographically random string that is used to correlate the authorization request to the token request.
代码验证器用于将授权请求与令牌请求关联的加密随机字符串。
code challenge A challenge derived from the code verifier that is sent in the authorization request, to be verified against later.
代码质询源于在授权请求中发送的代码验证器的质询，稍后将根据其进行验证。
code challenge method A method that was used to derive code challenge.
代码质询方法用于派生代码质询的方法。
Base64url Encoding Base64 encoding using the URL- and filename-safe character set defined in Section 5 of [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2 of [RFC4648]) and without the inclusion of any line breaks, whitespace, or other additional characters. (See Appendix A for notes on implementing base64url encoding without padding.)
Base64url编码使用[RFC4648]第5节中定义的URL和文件名安全字符集进行Base64编码，省略所有尾随“=”字符（如[RFC4648]第3.2节所允许），且不包含任何换行符、空白或其他附加字符。（有关实现无填充的base64url编码的说明，请参见附录A。）
ABNF Augmented Backus-Naur Form
ABNF增广Backus-Naur型
Authz Authorization
授权
PKCE Proof Key for Code Exchange
用于代码交换的PKCE验证密钥
MITM Man-in-the-middle
中间人
MTI Mandatory To Implement
强制实施MTI
The client first creates a code verifier, "code_verifier", for each OAuth 2.0 [RFC6749] Authorization Request, in the following manner:
客户机首先以以下方式为每个OAuth 2.0[RFC6749]授权请求创建代码验证器“代码验证器”：
code_verifier = high-entropy cryptographic random STRING using the
unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
from Section 2.3 of [RFC3986], with a minimum length of 43 characters
and a maximum length of 128 characters.
code_verifier = high-entropy cryptographic random STRING using the
unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
from Section 2.3 of [RFC3986], with a minimum length of 43 characters
and a maximum length of 128 characters.
ABNF for "code_verifier" is as follows.
“代码校验器”的ABNF如下所示。
code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
NOTE: The code verifier SHOULD have enough entropy to make it impractical to guess the value. It is RECOMMENDED that the output of a suitable random number generator be used to create a 32-octet sequence. The octet sequence is then base64url-encoded to produce a 43-octet URL safe string to use as the code verifier.
注意：代码验证器应该有足够的熵使猜测值变得不切实际。建议使用合适的随机数生成器的输出创建32个八位组序列。然后对八位字节序列进行base64url编码，以生成一个43位八位字节URL安全字符串，用作代码验证器。
The client then creates a code challenge derived from the code verifier by using one of the following transformations on the code verifier:
然后，客户端通过在代码验证器上使用以下转换之一，创建从代码验证器派生的代码质询：
plain code_challenge = code_verifier
普通代码\u挑战=代码\u验证器
S256
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
S256
code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
If the client is capable of using "S256", it MUST use "S256", as "S256" is Mandatory To Implement (MTI) on the server. Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and know via out-of-band configuration that the server supports "plain".
如果客户机能够使用“S256”，则必须使用“S256”，因为“S256”必须在服务器上实施（MTI）。只有由于某些技术原因无法支持“S256”，并且通过带外配置知道服务器支持“普通”时，才允许客户端使用“普通”。
The plain transformation is for compatibility with existing deployments and for constrained environments that can't use the S256 transformation.
普通转换是为了与现有部署和无法使用S256转换的受限环境兼容。
ABNF for "code_challenge" is as follows.
“代码挑战”的ABNF如下所示。
code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39
The client sends the code challenge as part of the OAuth 2.0 Authorization Request (Section 4.1.1 of [RFC6749]) using the following additional parameters:
客户机使用以下附加参数发送代码质询，作为OAuth 2.0授权请求的一部分（RFC6749第4.1.1节）：
code_challenge REQUIRED. Code challenge.
需要代码\u挑战。代码挑战。
code_challenge_method OPTIONAL, defaults to "plain" if not present in the request. Code verifier transformation method is "S256" or "plain".
代码\挑战\方法可选，如果请求中不存在，则默认为“普通”。代码验证器转换方法为“S256”或“普通”。
When the server issues the authorization code in the authorization response, it MUST associate the "code_challenge" and "code_challenge_method" values with the authorization code so it can be verified later.
当服务器在授权响应中发出授权代码时，它必须将“code\u challenge”和“code\u challenge\u method”值与授权代码相关联，以便稍后对其进行验证。
Typically, the "code_challenge" and "code_challenge_method" values are stored in encrypted form in the "code" itself but could alternatively be stored on the server associated with the code. The server MUST NOT include the "code_challenge" value in client requests in a form that other entities can extract.
通常，“code\u challenge”和“code\u challenge\u method”值以加密形式存储在“code”本身中，但也可以存储在与该代码相关联的服务器上。服务器不得以其他实体可以提取的形式在客户端请求中包含“code_challenge”值。
The exact method that the server uses to associate the "code_challenge" with the issued "code" is out of scope for this specification.
服务器用于将“代码挑战”与发布的“代码”关联的确切方法不在本规范的范围内。
If the server requires Proof Key for Code Exchange (PKCE) by OAuth public clients and the client does not send the "code_challenge" in the request, the authorization endpoint MUST return the authorization error response with the "error" value set to "invalid_request". The "error_description" or the response of "error_uri" SHOULD explain the nature of error, e.g., code challenge required.
如果服务器要求OAuth公共客户端为代码交换（PKCE）提供验证密钥，并且客户端未在请求中发送“代码_质询”，则授权端点必须返回授权错误响应，且“错误”值设置为“无效_请求”。“错误描述”或“错误uri”的响应应解释错误的性质，例如，需要代码质询。
If the server supporting PKCE does not support the requested transformation, the authorization endpoint MUST return the authorization error response with "error" value set to "invalid_request". The "error_description" or the response of "error_uri" SHOULD explain the nature of error, e.g., transform algorithm not supported.
如果支持PKCE的服务器不支持请求的转换，则授权端点必须返回“error”值设置为“invalid_request”的授权错误响应。“错误描述”或“错误uri”的响应应解释错误的性质，例如，不支持转换算法。
4.5. Client Sends the Authorization Code and the Code Verifier to the Token Endpoint
4.5. 客户端将授权代码和代码验证器发送到令牌端点
Upon receipt of the Authorization Code, the client sends the Access Token Request to the token endpoint. In addition to the parameters defined in the OAuth 2.0 Access Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:
在收到授权码后，客户端将访问令牌请求发送到令牌端点。除了OAuth 2.0访问令牌请求（RFC6749的第4.1.3节）中定义的参数外，它还发送以下参数：
code_verifier REQUIRED. Code verifier
需要代码验证程序。代码验证器
The "code_challenge_method" is bound to the Authorization Code when the Authorization Code is issued. That is the method that the token endpoint MUST use to verify the "code_verifier".
颁发授权码时，“code\u challenge\u method”绑定到授权码。这是令牌端点必须用来验证“代码验证器”的方法。
Upon receipt of the request at the token endpoint, the server verifies it by calculating the code challenge from the received "code_verifier" and comparing it with the previously associated "code_challenge", after first transforming it according to the "code_challenge_method" method specified by the client.
在令牌端点处接收到请求后，服务器通过计算来自接收到的“代码\u验证器”的代码质询并将其与之前关联的“代码\u质询”进行比较来验证该请求，然后首先根据客户端指定的“代码\u质询\u方法”对其进行转换。
If the "code_challenge_method" from Section 4.3 was "S256", the received "code_verifier" is hashed by SHA-256, base64url-encoded, and then compared to the "code_challenge", i.e.:
如果第4.3节中的“代码挑战”方法为“S256”，则收到的“代码验证程序”由SHA-256散列，base64url编码，然后与“代码挑战”进行比较，即：
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
If the "code_challenge_method" from Section 4.3 was "plain", they are compared directly, i.e.:
如果第4.3节中的“代码挑战法”为“普通法”，则直接对其进行比较，即：
code_verifier == code_challenge.
代码\验证程序==代码\挑战。
If the values are equal, the token endpoint MUST continue processing as normal (as defined by OAuth 2.0 [RFC6749]). If the values are not equal, an error response indicating "invalid_grant" as described in Section 5.2 of [RFC6749] MUST be returned.
如果值相等，则令牌端点必须继续正常处理（由OAuth 2.0[RFC6749]定义）。如果值不相等，则必须返回错误响应，如[RFC6749]第5.2节所述，指示“无效的授权”。
Server implementations of this specification MAY accept OAuth2.0 clients that do not implement this extension. If the "code_verifier" is not received from the client in the Authorization Request, servers supporting backwards compatibility revert to the OAuth 2.0 [RFC6749] protocol without this extension.
此规范的服务器实现可能接受未实现此扩展的OAuth2.0客户端。如果在授权请求中没有从客户端接收到“代码验证器”，则支持向后兼容性的服务器将恢复到OAuth 2.0[RFC6749]协议，而不使用此扩展。
As the OAuth 2.0 [RFC6749] server responses are unchanged by this specification, client implementations of this specification do not need to know if the server has implemented this specification or not and SHOULD send the additional parameters as defined in Section 4 to all servers.
由于OAuth 2.0[RFC6749]服务器响应不受本规范的影响，因此本规范的客户端实现不需要知道服务器是否实现了本规范，并且应将第4节中定义的附加参数发送给所有服务器。
IANA has made the following registrations per this document.
IANA已根据本文件进行了以下注册。
This specification registers the following parameters in the IANA "OAuth Parameters" registry defined in OAuth 2.0 [RFC6749].
本规范在OAuth 2.0[RFC6749]中定义的IANA“OAuth参数”注册表中注册以下参数。
o Parameter name: code_verifier o Parameter usage location: token request o Change controller: IESG o Specification document(s): RFC 7636 (this document)
o 参数名称：代码验证器o参数使用位置：令牌请求o更改控制器：IESG o规范文件：RFC 7636（本文件）
o Parameter name: code_challenge o Parameter usage location: authorization request o Change controller: IESG o Specification document(s): RFC 7636 (this document)
o 参数名称：代码挑战o参数使用位置：授权请求o变更控制器：IESG o规范文件：RFC 7636（本文件）
o Parameter name: code_challenge_method o Parameter usage location: authorization request o Change controller: IESG o Specification document(s): RFC 7636 (this document)
o 参数名称：代码\u挑战\u方法o参数使用位置：授权请求o变更控制器：IESG o规范文件：RFC 7636（本文件）
This specification establishes the "PKCE Code Challenge Methods" registry. The new registry should be a sub-registry of the "OAuth Parameters" registry.
本规范建立了“PKCE代码质询方法”注册表。新注册表应该是“OAuth参数”注册表的子注册表。
Additional "code_challenge_method" types for use with the authorization endpoint are registered using the Specification Required policy [RFC5226], which includes review of the request by one or more Designated Experts (DEs). The DEs will ensure that there
使用规范要求策略[RFC5226]注册用于授权端点的其他“代码挑战方法”类型，该策略包括由一个或多个指定专家（DE）审查请求。DEs将确保
is at least a two-week review of the request on the oauth-ext-review@ietf.org mailing list and that any discussion on that list converges before they respond to the request. To allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that an acceptable specification will be published.
至少在oauth ext上对请求进行两周的审查-review@ietf.org邮件列表和该列表上的任何讨论在响应请求之前会聚在一起。为了允许在发布前分配值，指定专家可在其确信将发布可接受规范后批准注册。
Registration requests and discussion on the oauth-ext-review@ietf.org mailing list should use an appropriate subject, such as "Request for PKCE code_challenge_method: example").
关于oauth ext的注册请求和讨论-review@ietf.org邮件列表应使用适当的主题，如“请求PKCE代码\挑战\方法：示例”）。
The Designated Expert(s) should consider the discussion on the mailing list, as well as the overall security properties of the challenge method when evaluating registration requests. New methods should not disclose the value of the code_verifier in the request to the Authorization endpoint. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.
指定专家应考虑邮件列表的讨论，以及评估注册请求时的挑战方法的总体安全属性。新方法不应向授权端点披露请求中代码验证程序的值。拒绝应包括解释，以及（如适用）关于如何使请求成功的建议。
Code Challenge Method Parameter Name: The name requested (e.g., "example"). Because a core goal of this specification is for the resulting representations to be compact, it is RECOMMENDED that the name be short -- not to exceed 8 characters without a compelling reason to do so. This name is case-sensitive. Names may not match other registered names in a case-insensitive manner unless the Designated Expert(s) states that there is a compelling reason to allow an exception in this particular case.
代码质询方法参数名称：请求的名称（例如，“示例”）。由于本规范的一个核心目标是使生成的表示形式紧凑，因此建议名称简短——如果没有令人信服的理由，名称不能超过8个字符。此名称区分大小写。名称不得以不区分大小写的方式与其他注册名称匹配，除非指定的专家声明有令人信服的理由允许在此特定情况下出现例外。
Change Controller: For Standards Track RFCs, state "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, and home page URI) may also be included.
更改控制器：对于标准跟踪RFC，请注明“IESG”。对于其他人，请提供责任方的名称。还可以包括其他详细信息（例如，邮政地址、电子邮件地址和主页URI）。
Specification Document(s): Reference to the document(s) that specifies the parameter, preferably including URI(s) that can be used to retrieve copies of the document(s). An indication of the relevant sections may also be included but is not required.
规范文档：对指定参数的文档的引用，最好包括可用于检索文档副本的URI。也可以包括相关章节的指示，但不需要。
Per this document, IANA has registered the Code Challenge Method Parameter Names defined in Section 4.2 in this registry.
根据本文件，IANA已在此注册表中注册了第4.2节中定义的代码质询方法参数名称。
o Code Challenge Method Parameter Name: plain o Change Controller: IESG o Specification Document(s): Section 4.2 of RFC 7636 (this document)
o 代码质疑方法参数名称：普通o变更控制器：IESG o规范文件：RFC 7636第4.2节（本文件）
o Code Challenge Method Parameter Name: S256 o Change Controller: IESG o Specification Document(s): Section 4.2 of RFC 7636 (this document)
o 代码质疑方法参数名称：S256 o变更控制器：IESG o规范文件：RFC 7636（本文件）第4.2节
The security model relies on the fact that the code verifier is not learned or guessed by the attacker. It is vitally important to adhere to this principle. As such, the code verifier has to be created in such a manner that it is cryptographically random and has high entropy that it is not practical for the attacker to guess.
安全模型依赖于这样一个事实：代码验证器没有被攻击者学习或猜测。坚持这一原则至关重要。因此，代码验证器的创建方式必须确保其在加密方面是随机的，并且具有高熵，因此攻击者无法猜测。
The client SHOULD create a "code_verifier" with a minimum of 256 bits of entropy. This can be done by having a suitable random number generator create a 32-octet sequence. The octet sequence can then be base64url-encoded to produce a 43-octet URL safe string to use as a "code_challenge" that has the required entropy.
客户端应创建一个“代码验证程序”，其最小熵为256位。这可以通过使用合适的随机数生成器创建32个八位组序列来实现。然后可以对八位字节序列进行base64url编码，以生成43个八位字节URL安全字符串，用作具有所需熵的“代码挑战”。
Clients MUST NOT downgrade to "plain" after trying the "S256" method. Servers that support PKCE are required to support "S256", and servers that do not support PKCE will simply ignore the unknown "code_verifier". Because of this, an error when "S256" is presented can only mean that the server is faulty or that a MITM attacker is trying a downgrade attack.
在尝试“S256”方法后，客户端不得降级到“普通”。支持PKCE的服务器需要支持“S256”，不支持PKCE的服务器将忽略未知的“代码验证器”。因此，出现“S256”时的错误只能表示服务器有故障或MITM攻击者正在尝试降级攻击。
The "S256" method protects against eavesdroppers observing or intercepting the "code_challenge", because the challenge cannot be used without the verifier. With the "plain" method, there is a chance that "code_challenge" will be observed by the attacker on the device or in the http request. Since the code challenge is the same as the code verifier in this case, the "plain" method does not protect against the eavesdropping of the initial request.
“S256”方法可防止窃听者观察或拦截“code_质询”，因为没有验证器无法使用质询。使用“普通”方法，攻击者有可能在设备上或http请求中观察到“代码挑战”。由于在这种情况下，代码质询与代码验证器相同，“普通”方法不能防止初始请求被窃听。
The use of "S256" protects against disclosure of the "code_verifier" value to an attacker.
使用“S256”可防止“代码验证器”值泄露给攻击者。
Because of this, "plain" SHOULD NOT be used and exists only for compatibility with deployed implementations where the request path is already protected. The "plain" method SHOULD NOT be used in new implementations, unless they cannot support "S256" for some technical reason.
因此，不应使用“plain”，它的存在只是为了与请求路径已受保护的已部署实现兼容。在新的实现中不应使用“普通”方法，除非它们由于某些技术原因无法支持“S256”。
The "S256" code challenge method or other cryptographically secure code challenge method extension SHOULD be used. The "plain" code challenge method relies on the operating system and transport security not to disclose the request to an attacker.
应使用“S256”代码质询方法或其他加密安全代码质询方法扩展。“普通”代码质询方法依赖于操作系统和传输安全性，不会将请求泄露给攻击者。
If the code challenge method is "plain" and the code challenge is to be returned inside authorization "code" to achieve a stateless server, it MUST be encrypted in such a manner that only the server can decrypt and extract it.
如果代码质询方法是“普通”的，并且代码质询将在授权“代码”内返回以实现无状态服务器，则必须以只有服务器才能解密和提取的方式对其进行加密。
To reduce implementation complexity, salting is not used in the production of the code challenge, as the code verifier contains sufficient entropy to prevent brute-force attacks. Concatenating a publicly known value to a code verifier (containing 256 bits of entropy) and then hashing it with SHA256 to produce a code challenge would not increase the number of attempts necessary to brute force a valid value for code verifier.
为了降低实现复杂性，在生成代码质询时不使用salt，因为代码验证器包含足够的熵来防止暴力攻击。将一个已知的值连接到一个代码验证器（包含256位的熵），然后用SHA256对其进行散列以产生一个代码质询，这不会增加强制代码验证器使用有效值所需的尝试次数。
While the "S256" transformation is like hashing a password, there are important differences. Passwords tend to be relatively low-entropy words that can be hashed offline and the hash looked up in a dictionary. By concatenating a unique though public value to each password prior to hashing, the dictionary space that an attacker needs to search is greatly expanded.
虽然“S256”转换类似于对密码进行哈希运算，但有一些重要的区别。密码往往是相对低熵的单词，可以脱机散列，并在字典中查找散列。通过在散列之前将一个唯一但公开的值连接到每个密码，攻击者需要搜索的字典空间大大扩展。
Modern graphics processors now allow attackers to calculate hashes in real time faster than they could be looked up from a disk. This eliminates the value of the salt in increasing the complexity of a brute-force attack for even low-entropy passwords.
现代图形处理器现在允许攻击者以比从磁盘上查找哈希更快的速度实时计算哈希。这就消除了salt在增加暴力攻击的复杂性方面的价值，即使是低熵密码。
All the OAuth security analysis presented in [RFC6819] applies, so readers SHOULD carefully follow it.
[RFC6819]中介绍的所有OAuth安全性分析都适用，因此读者应该仔细阅读。
Current security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195]. This supersedes the TLS version recommendations in OAuth 2.0 [RFC6749].
当前的安全注意事项可在“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”中找到[BCP195]。这将取代OAuth 2.0[RFC6749]中的TLS版本建议。
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <http://www.rfc-editor.org/info/bcp195>.
[BCP195]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 75252015年5月<http://www.rfc-editor.org/info/bcp195>.
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, RFC 20, DOI 10.17487/RFC0020, October 1969, <http://www.rfc-editor.org/info/rfc20>.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，STD 80，RFC 20，DOI 10.17487/RFC0020，1969年10月<http://www.rfc-editor.org/info/rfc20>.
[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>.
[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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[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>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <http://www.rfc-editor.org/info/rfc6234>.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，DOI 10.17487/RFC6234，2011年5月<http://www.rfc-editor.org/info/rfc6234>.
[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>.
[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>.
This appendix describes how to implement a base64url-encoding function without padding, based upon the standard base64-encoding function that uses padding.
本附录描述了如何基于使用填充的标准base64编码函数，在不使用填充的情况下实现base64url编码函数。
To be concrete, example C# code implementing these functions is shown below. Similar code could be used in other languages.
具体来说，实现这些函数的示例C#代码如下所示。类似的代码可以在其他语言中使用。
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
static string base64urlencode(byte [] arg)
{
string s = Convert.ToBase64String(arg); // Regular base64 encoder
s = s.Split('=')[0]; // Remove any trailing '='s
s = s.Replace('+', '-'); // 62nd char of encoding
s = s.Replace('/', '_'); // 63rd char of encoding
return s;
}
An example correspondence between unencoded and encoded values follows. The octet sequence below encodes into the string below, which when decoded, reproduces the octet sequence.
下面是未编码值和编码值之间的对应关系示例。下面的八位字节序列编码到下面的字符串中，该字符串在解码时再现八位字节序列。
3 236 255 224 193
3 236 255 224 193
A-z_4ME
A-z_4ME
Appendix B. Example for the S256 code_challenge_method
附录B.S256代码挑战法示例
The client uses output of a suitable random number generator to create a 32-octet sequence. The octets representing the value in this example (using JSON array notation) are:
客户端使用合适的随机数生成器的输出来创建32个八位组序列。本例中表示值的八位字节（使用JSON数组表示法）为：
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
[116, 24, 223, 180, 151, 153, 224, 37, 79, 250, 96, 125, 216, 173, 187, 186, 22, 212, 37, 77, 105, 214, 191, 240, 91, 88, 5, 88, 83, 132, 141, 121]
Encoding this octet sequence as base64url provides the value of the code_verifier:
将此八位字节序列编码为base64url将提供代码验证程序的值：
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
The code_verifier is then hashed via the SHA256 hash function to produce:
然后，通过SHA256散列函数对代码验证程序进行散列，以生成：
[19, 211, 30, 150, 26, 26, 216, 236, 47, 22, 177, 12, 76, 152, 46, 8, 118, 168, 120, 173, 109, 241, 68, 86, 110, 225, 137, 74, 203, 112, 249, 195]
[19, 211, 30, 150, 26, 26, 216, 236, 47, 22, 177, 12, 76, 152, 46, 8, 118, 168, 120, 173, 109, 241, 68, 86, 110, 225, 137, 74, 203, 112, 249, 195]
Encoding this octet sequence as base64url provides the value of the code_challenge:
将此八位字节序列编码为base64url将提供代码\u质询的值：
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw厘米
The authorization request includes:
授权请求包括：
code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM &code_challenge_method=S256
代码挑战=E9MELHAO2OWVFREMTJGUCHAOEK8URWBUGJSSTW cM和代码挑战方法=S256
The authorization server then records the code_challenge and code_challenge_method along with the code that is granted to the client.
然后，授权服务器将记录“代码挑战”和“代码挑战”方法以及授予客户端的代码。
In the request to the token_endpoint, the client includes the code received in the authorization response as well as the additional parameter:
在对令牌_端点的请求中，客户端包括在授权响应中接收的代码以及附加参数：
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
代码验证器=dBjftJeZ4CVP-mB92K27uhbUJU1p1r\U wW1gFWFOEjXk
The authorization server retrieves the information for the code grant. Based on the recorded code_challenge_method being S256, it then hashes and base64url-encodes the value of code_verifier:
授权服务器检索代码授权的信息。基于记录的代码挑战方法S256，它然后散列并base64url编码代码验证器的值：
BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
The calculated value is then compared with the value of "code_challenge":
然后将计算值与“代码挑战”的值进行比较：
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
If the two values are equal, then the authorization server can provide the tokens as long as there are no other errors in the request. If the values are not equal, then the request must be rejected, and an error returned.
如果这两个值相等，那么只要请求中没有其他错误，授权服务器就可以提供令牌。如果值不相等，则必须拒绝请求，并返回错误。
Acknowledgements
致谢
The initial draft version of this specification was created by the OpenID AB/Connect Working Group of the OpenID Foundation.
本规范的初始草稿版本是由OpenID基金会的OpenID Ab/Connect工作组创建的。
This specification is the work of the OAuth Working Group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that shaped and formed the final specification:
本规范是OAuth工作组的工作，该工作组包括数十名积极和专注的参与者。特别是，以下个人提供了形成最终规范的想法、反馈和措辞：
Anthony Nadalin, Microsoft Axel Nenker, Deutsche Telekom Breno de Medeiros, Google Brian Campbell, Ping Identity Chuck Mortimore, Salesforce Dirk Balfanz, Google Eduardo Gueiros, Jive Communications Hannes Tschonfenig, ARM James Manger, Telstra Justin Richer, MIT Kerberos Josh Mandel, Boston Children's Hospital Lewis Adam, Motorola Solutions Madjid Nakhjiri, Samsung Michael B. Jones, Microsoft Paul Madsen, Ping Identity Phil Hunt, Oracle Prateek Mishra, Oracle Ryo Ito, mixi Scott Tomilson, Ping Identity Sergey Beryozkin Takamichi Saito Torsten Lodderstedt, Deutsche Telekom William Denniss, Google
Anthony Nadalin、微软Axel Nenker、德国电信Breno de Medeiros、谷歌Brian Campbell、Ping Identity Chuck Mortimore、Salesforce Dirk Balfanz、谷歌Eduardo Gueiros、Jive Communications Hannes Tschonfenig、ARM James Manger、电信公司Justin Richer、麻省理工学院Kerberos Josh Mandel、波士顿儿童医院Lewis Adam、，摩托罗拉解决方案公司Madjid Nakhjiri、三星迈克尔B.琼斯、微软保罗·马德森、Ping Identity Phil Hunt、甲骨文Pratek Mishra、甲骨文Ryo Ito、mixi Scott Tomilson、Ping Identity Sergey Beryozkin Takamichi Saito Torsten Lodderstedt、德国电信威廉·丹尼斯、谷歌
Authors' Addresses
作者地址
Nat Sakimura (editor) Nomura Research Institute 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. Chiyoda-ku, Tokyo 100-0005 Japan
日本东京千代田区丸内北口丸内大厦丸内1-6-5号野村研究所Nat Sakimura（编辑）100-0005
Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
John Bradley Ping Identity Casilla 177, Sucursal Talagante Talagante, RM Chile
约翰·布拉德利·平身份证卡西拉177，Sucursal Talagante Talagante，RM智利
Phone: +44 20 8133 3718
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Phone: +44 20 8133 3718
Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/
Naveen Agarwal Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States
Naveen Agarwal谷歌1600圆形剧场公园路山景，加利福尼亚州94043
Phone: +1 650-253-0000
Email: naa@google.com
URI: http://google.com/
Phone: +1 650-253-0000
Email: naa@google.com
URI: http://google.com/