[要約] RFC 7636は、"Proof Key for Code Exchange by OAuth Public Clients"（公開OAuthクライアントによるコード交換のための証明鍵）に関するもので、OAuth 2.0認証フローにおける公開クライアントのセキュリティを強化するために提案されました。このRFCは、認可コードの取得とトークンの交換フェーズにおいて、追加のコードチャレンジとコードベリファイアを使用することで、認証コードの傍受攻撃に対する保護を強化します。主に、モバイルアプリやフロントエンドアプリケーションなどの公開クライアントが対象です。関連するRFCには、OAuth 2.0を定義するRFC 6749などがあります。この仕様により、より安全なOAuth認証フローの実装が可能になります。
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").
Authorization Code Grantを利用するOAuth 2.0パブリッククライアントは、Authorization Codeインターセプト攻撃の影響を受けます。この仕様では、攻撃と、コード交換用のProof Key（PKCE、「pixy」と発音）を使用して脅威を軽減する手法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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 | |
| +----------------------------+ | +----------+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
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]の「client_id」と「client_secret」（プロビジョニングされている場合）にアクセスできます。すべてのOAuth 2.0ネイティブアプリクライアントインスタンスは、同じ「client_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_challenge_method」の値が「プレーン」の場合、この攻撃のみが軽減されます。
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。より高度な攻撃シナリオでは、攻撃者は認証エンドポイントへの（応答に加えて）要求を監視できます。ただし、攻撃者は中間者として行動することはできません。これは、OSのhttpログ情報のリークが原因でした。これを軽減するには、「code_challenge_method」値を「S256」または暗号で保護された「code_challenge_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 ---------| | |
+--------+ | +---------------+ |
+-------------------+
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.
この仕様では、図2に抽象的な形式で示すように、OAuth 2.0承認およびアクセストークンリクエストに追加のパラメーターが追加されます。
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_challenge」と呼ばれる）を導出します。これは、変換メソッドとともにOAuth 2.0承認リクエストで送信されますt_m」。
B. The Authorization Endpoint responds as usual but records "t(code_verifier)" and the transformation method.
B.承認エンドポイントは通常どおり応答しますが、「t（code_verifier）」と変換メソッドを記録します。
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）で生成された「code_verifier」シークレットを含めます。
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.認可サーバーは「code_verifier」を変換し、（B）の「t（code_verifier）」と比較します。それらが等しくない場合、アクセスは拒否されます。
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.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「は、「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.
STRINGは、0個以上のASCII [RFC20]文字のシーケンスを示します。
OCTETS denotes a sequence of zero or more octets.
OCTETSは、0個以上のオクテットのシーケンスを示します。
ASCII(STRING) denotes the octets of the ASCII [RFC20] representation of STRING where STRING is a sequence of zero or more ASCII characters.
ASCII（STRING）は、STRINGのASCII [RFC20]表現のオクテットを示します。ここで、STRINGは0個以上のASCII文字のシーケンスです。
BASE64URL-ENCODE(OCTETS) denotes the base64url encoding of OCTETS, per Appendix A, producing a STRING.
BASE64URL-ENCODE（OCTETS）は、付録Aに従って、OCTETSのbase64urlエンコーディングを示し、STRINGを生成します。
BASE64URL-DECODE(STRING) denotes the base64url decoding of STRING, per Appendix A, producing a sequence of octets.
BASE64URL-DECODE（STRING）は、付録Aに従って、STRINGのbase64urlデコードを示し、オクテットのシーケンスを生成します。
SHA256(OCTETS) denotes a SHA2 256-bit hash [RFC6234] of OCTETS.
SHA256（OCTETS）は、OCTETSのSHA2 256ビットハッシュ[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拡張バッカスナウアフォーム
Authz Authorization
Authz承認
PKCE Proof Key for Code Exchange
コード交換用のPKCEプルーフキー
MITM Man-in-the-middle
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] Authorization Requestに対して、次の方法でコードベリファイア「code_verifier」を作成します。
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 =予約されていない文字を使用した高エントロピー暗号ランダム文字列[A-Z] / [a-z] / [0-9] / "-" / "。" [RFC3986]のセクション2.3の/ "_" / "〜"。最小長は43文字、最大長は128文字です。
ABNF for "code_verifier" is as follows.
「code_verifier」のABNFは以下の通りです。
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.
注：コードベリファイアには、値を推測するのを非実用的にするのに十分なエントロピーが必要です（SHOULD）。適切な乱数発生器の出力を使用して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
プレーンなcode_challenge = 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」はサーバーに実装する必要がある（MTI）ため、「S256」を使用する必要があります。クライアントは、技術的な理由で「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.
「code_challenge」のABNFは以下の通りです。
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.
code_challengeが必要です。コードチャレンジ。
code_challenge_method OPTIONAL, defaults to "plain" if not present in the request. Code verifier transformation method is "S256" or "plain".
code_challenge_method OPTIONAL。リクエストに存在しない場合、デフォルトで「プレーン」になります。コードベリファイアの変換方法は「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_challenge」と「code_challenge_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_challenge」と「code_challenge_method」の値は、「code」自体に暗号化された形式で格納されますが、コードに関連付けられたサーバーに格納することもできます。サーバーは、他のエンティティが抽出できる形式でクライアントリクエストに "code_challenge"値を含めてはなりません（MUST NOT）。
The exact method that the server uses to associate the "code_challenge" with the issued "code" is out of scope for this specification.
サーバーが「code_challenge」と発行された「コード」を関連付けるために使用する正確な方法は、この仕様の範囲外です。
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）の証明キーを必要とし、クライアントがリクエストで "code_challenge"を送信しない場合、認証エンドポイントは、 "error"値を "invalid_request"に設定して認証エラー応答を返さなければなりません（MUST）。 。 「error_description」または「error_uri」の応答は、必要なコードチャレンジなど、エラーの性質を説明する必要があります（SHOULD）。
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をサポートするサーバーが要求された変換をサポートしない場合、認証エンドポイントは、「エラー」値が「invalid_request」に設定された認証エラー応答を返さなければなりません（MUST）。 「error_description」または「error_uri」の応答は、エラーの性質、たとえば、サポートされていない変換アルゴリズムを説明する必要があります（SHOULD）。
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
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_challenge_method」は、認証コードが発行されるときに認証コードにバインドされます。これは、トークンエンドポイントが「code_verifier」を検証するために使用する必要があるメソッドです。
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.
トークンエンドポイントでリクエストを受信すると、サーバーは、指定された「code_challenge_method」メソッドに従って最初に変換した後、受信した「code_verifier」からコードチャレンジを計算し、以前に関連付けられた「code_challenge」と比較することにより、リクエストを検証します。クライアント。
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の「code_challenge_method」が「S256」であった場合、受信した「code_verifier」はSHA-256によってハッシュされ、base64urlでエンコードされてから、「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_challenge_method」が「プレーン」だった場合は、直接比較されます。
code_verifier == code_challenge.
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で説明されている「invalid_grant」を示すエラー応答を返す必要があります。
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クライアントを受け入れる場合があります。承認リクエストで「code_verifier」がクライアントから受信されない場合、下位互換性をサポートするサーバーは、この拡張なしの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 Parameters"レジストリに以下のパラメーターを登録します。
o Parameter name: code_verifier o Parameter usage location: token request o Change controller: IESG o Specification document(s): RFC 7636 (this document)
o パラメーター名：code_verifier 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 パラメータ名：code_challenge 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 パラメータ名：code_challenge_method 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 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.
承認エンドポイントで使用する追加の「code_challenge_method」タイプは、1つ以上のDesignated Experts（DE）による要求のレビューを含む、Specification Requiredポリシー[RFC5226]を使用して登録されます。 DEは、oauth-ext-review @ ietf.orgメーリングリストで少なくとも2週間のリクエストのレビューがあり、そのリストに関するすべてのディスカッションがリクエストに応答する前に収束することを保証します。公開前に値の割り当てを可能にするために、指定された専門家は、受け入れ可能な仕様が公開されることに納得したら、登録を承認することができます。
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 code_challenge_methodのリクエスト：例」などの適切な件名を使用する必要があります。
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_verifierの値を公開しないでください。拒否には、要求を成功させる方法についての説明と、該当する場合は提案を含める必要があります。
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.
コードチャレンジメソッドパラメータ名：要求された名前（例： "example"）。この仕様の中心的な目標は、結果の表現をコンパクトにすることです。そのため、やむを得ない理由がない限り、名前は短く、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.
Specification Document（s）：パラメータを指定するドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できる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ビット以上のエントロピーを持つ「code_verifier」を作成する必要があります（SHOULD）。これは、適切な乱数ジェネレータで32オクテットのシーケンスを作成することによって実行できます。次に、オクテットシーケンスをbase64urlエンコードして、必要なエントロピーを持つ「code_challenge」として使用する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をサポートしないサーバーは不明な「code_verifier」を単に無視します。このため、「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_challenge」を傍受または傍受する盗聴者から保護します。これは、検証者なしではチャレンジを使用できないためです。 「プレーン」メソッドでは、デバイスまたはhttpリクエストで攻撃者が「code_challenge」を監視する可能性があります。この場合、コードチャレンジはコードベリファイアと同じであるため、「プレーン」メソッドは最初のリクエストの盗聴から保護しません。
The use of "S256" protects against disclosure of the "code_verifier" value to an attacker.
「S256」を使用すると、「code_verifier」値が攻撃者に開示されるのを防ぎます。
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.
このため、「プレーン」は使用すべきではなく（SHOULD NOT）、リクエストパスがすでに保護されているデプロイ済み実装との互換性のためにのみ存在します。 「プレーン」メソッドは、何らかの技術的な理由で「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.
コード検証にはブルートフォース攻撃を防ぐための十分なエントロピーが含まれているため、実装の複雑さを軽減するために、コードチャレンジの生成ではソルティングは使用されません。公開されている値をコードベリファイア（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.
最近のグラフィックスプロセッサでは、攻撃者がディスクから検索するよりも高速にハッシュをリアルタイムで計算できるようになりました。これにより、エントロピーの低いパスワードでもブルートフォース攻撃の複雑さが増すというソルトの価値が排除されます。
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、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年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、「Uniform Resource Identifier（URI）：Generic Syntax」、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。、「The 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、「RFCで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]クロッカー、D。、エド。および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、「US Secure Hash Algorithms（SHA and SHA-based HMAC and 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。、編、「The OAuth 2.0 Authorization Framework」、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] Lodderstedt、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-encoding関数に基づいて、パディングなしでbase64url-encoding関数を実装する方法について説明します。
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;
}
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
３ ２３６ ２５５ ２２４ １９３
A-z_4ME
z_4ME
Appendix B. Example for the S256 code_challenge_method
付録B. S256 code_challenge_methodの例
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]
「１１６、 ２４、 ２２３、 １８０、 １５１、 １５３、 ２２４、 ３７、 ７９、 ２５０、 ９６、 １２５、 ２１６、 １７３、 １８７、 １８６、 ２２、 ２１２、 ３７、 ７７、 １０５、 ２１４、 １９１、 ２４０、 ９１、 ８８、 ５、 ８８、 ８３、 １３２、 １４１、 １２１」
Encoding this octet sequence as base64url provides the value of the code_verifier:
このオクテットシーケンスをbase64urlとしてエンコードすると、code_verifierの値が提供されます。
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
The code_verifier is then hashed via the SHA256 hash function to produce:
次に、code_verifierが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]
「１９、 ２１１、 ３０、 １５０、 ２６、 ２６、 ２１６、 ２３６、 ４７、 ２２、 １７７、 １２、 ７６、 １５２、 ４６、 ８、 １１８、 １６８、 １２０、 １７３、 １０９、 ２４１、 ６８、 ８６、 １１０、 ２２５、 １３７、 ７４、 ２０３、 １１２、 ２４９、 １９５」
Encoding this octet sequence as base64url provides the value of the code_challenge:
このオクテットシーケンスをbase64urlとしてエンコードすると、code_challengeの値が提供されます。
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
The authorization request includes:
承認リクエストには次のものが含まれます。
code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM &code_challenge_method=S256
code_challenge = E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM＆code_challenge_method = S256
The authorization server then records the code_challenge and code_challenge_method along with the code that is granted to the client.
次に、許可サーバーはcode_challengeおよびcode_challenge_methodを、クライアントに付与されたコードとともに記録します。
In the request to the token_endpoint, the client includes the code received in the authorization response as well as the additional parameter:
token_endpointへのリクエストでは、クライアントは認証応答で受信したコードと追加のパラメーターを含めます。
code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_verifier = dBjftJeZ4CVP-mB92K27uhbUJU1p1r_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:
認可サーバーは、コード付与の情報を取得します。記録されたcode_challenge_methodがS256であることに基づいて、次にcode_verifierの値をハッシュしてbase64urlエンコードします。
BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
The calculated value is then compared with the value of "code_challenge":
次に、計算された値が「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.
2つの値が等しい場合、リクエストに他のエラーがない限り、認可サーバーはトークンを提供できます。値が等しくない場合、要求は拒否され、エラーが返されます。
Acknowledgements
謝辞
The initial draft version of this specification was created by the OpenID AB/Connect Working Group of the OpenID Foundation.
この仕様の最初のドラフトバージョンは、OpenID Foundationの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、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 James、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、グーグル
Authors' Addresses
著者のアドレス
Nat Sakimura (editor) Nomura Research Institute 1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg. Chiyoda-ku, Tokyo 100-0005 Japan
なｔ さきむら （えぢとｒ） のむら れせあｒｃｈ いんｓちつて １ー６ー５ まるのうち、 まるのうち きたぐち Ｂｌｄｇ。 ちよだーく、 ときょ １００ー０００５ じゃぱん
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
John Bradley Ping Identity Casilla 177、Sucursal Talagante Talagante、RMチリ
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 Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Phone: +1 650-253-0000
Email: naa@google.com
URI: http://google.com/