OAuth 2.1 認可フレームワーク

1.3.1. 認可コード

認可コードは、アクセストークンを取得するために使用される 一時的なクレデンシャルです。 クライアントがリソース所有者から直接認可を要求する代わりに、 クライアントはリソース所有者を（そのユーザーエージェントを介して） 認可サーバーへ誘導し、認可サーバーは認可コードとともに リソース所有者をクライアントへ戻します。 その後、クライアントは認可コードをアクセストークンと交換できます。¶

認可コードとともにリソース所有者をクライアントへ戻す前に、 認可サーバーはリソース所有者を認証し、リソース所有者の同意を 求めたり、その他の方法でクライアントのリクエストについて通知したりできます。 リソース所有者は認可サーバーでのみ認証するため、 リソース所有者のクレデンシャルはクライアントと共有されることがなく、 クライアントは多要素認証や委任アカウントなどの追加の認証手順を 知る必要がありません。¶

認可コードは、クライアントを認証できることや、 アクセストークンをリソース所有者のユーザーエージェントを経由させずに クライアントへ直接送信し、リソース所有者を含む他者へ 露出する可能性を避けられることなど、いくつかの重要な セキュリティ上の利点を提供します。¶

1.3.2. リフレッシュトークン

リフレッシュトークンは、アクセストークンを取得するために使用される クレデンシャルです。リフレッシュトークンは、認可サーバーによって クライアントに発行される場合があり、現在のアクセストークンが 無効になったり失効したりしたときに新しいアクセストークンを取得するため、 または同一もしくはより狭いスコープを持つ追加のアクセストークンを 取得するために使用されます（アクセストークンは、リソース所有者によって 認可されたものよりも短い有効期間や少ない権限を持つ場合があります）。 リフレッシュトークンの発行は認可サーバーの裁量による任意のものであり、 クライアントの特性、リクエストの特性、認可サーバー内のポリシー、 またはその他の基準に基づいて発行される場合があります。認可サーバーが リフレッシュトークンを発行する場合、それはアクセストークンの発行時 （つまり Figure 2 の手順 (2)）に 含まれます。リフレッシュトークンの有効期間も 認可サーバーの裁量によります。¶

リフレッシュトークンは、リソース所有者によってクライアントに 付与された認可を表す文字列です。この文字列はクライアントにとって 不透明であるとみなされます。リフレッシュトークンは、認可情報を取得するための 識別子である場合もあれば、この情報を文字列自体にエンコードする場合もあります。 アクセストークンとは異なり、リフレッシュトークンは認可サーバーでのみ 使用されることを意図しており、リソースサーバーへ送信されることはありません。¶

+--------+                                           +---------------+
|        |--(1)------- Authorization Grant --------->|               |
|        |                                           |               |
|        |<-(2)----------- Access Token -------------|               |
|        |               & Refresh Token             |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)- Protected Resource --| Resource |   | Authorization |
| Client |                            |  Server  |   |     Server    |
|        |--(5)---- Access Token ---->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)- Invalid Token Error -|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)----------- Refresh Token ----------->|               |
|        |                                           |               |
|        |<-(8)----------- Access Token -------------|               |
+--------+           & Optional Refresh Token        +---------------+

Figure 2 に示されるフローは、次の手順を含みます:¶

1. クライアントは認可サーバーで認証し、 認可グラントを提示することにより、アクセストークンを要求します。¶

2. 認可サーバーはクライアントを認証し、 認可グラントを検証し、有効であればアクセストークンと 任意でリフレッシュトークンを発行します。¶

3. クライアントはアクセストークンを提示することにより、 リソースサーバーへ保護されたリソースリクエストを行います。¶

4. リソースサーバーはアクセストークンを検証し、 有効であればリクエストに応答します。¶

5. 手順 (3) と (4) はアクセストークンが失効するまで繰り返されます。 クライアントがアクセストークンの失効を知っている場合は手順 (7) へ進み、 そうでなければ別の保護されたリソースリクエストを行います。¶

6. アクセストークンが無効であるため、リソースサーバーは 無効なトークンエラーを返します。¶

7. クライアントはリフレッシュトークンを提示し、 クレデンシャルが発行されている場合はクライアント認証を提供して、 新しいアクセストークンを要求します。クライアント認証要件は、 クライアント種別と認可サーバーのポリシーに基づきます。¶

8. 認可サーバーはクライアントを認証し、 リフレッシュトークンを検証し、有効であれば新しいアクセストークン （および任意で新しいリフレッシュトークン）を発行します。¶

リフレッシュトークンの有効期間をクライアントへ伝える必要はないことに 注意してください。クライアントはその有効期間を知っても、 何か別のことができるわけではないためです。さらに、認可サーバーは 動的な有効期間を使用することを選択する場合があります（たとえば、 リフレッシュトークンが少なくとも 7 日に 1 回使用される限り、 その有効期限を延長するなど）。または、ユーザーがアプリケーションの アクセスを取り消した場合など、任意の理由で予定された失効日より前に リフレッシュトークンを取り消す場合もあります。これは、クライアントがすでに 任意の時点でリフレッシュトークンが失効する場合を処理しなければならないことを 意味します。¶

リフレッシュトークンがなぜ、いつ失効するかに関係なく、 クライアントが新しいトークンを取得するための道筋は 1 つだけであり、 それは最初から新しい OAuth フローを開始することです。そのため、 リフレッシュトークンの失効をクライアントに伝えるためのプロパティは 定義されていません。¶

1.3.3. クライアントクレデンシャル

クライアントクレデンシャルまたはその他の形式のクライアント認証 （たとえば、[RFC7523] およびその更新 [I-D.ietf-oauth-rfc7523bis] で説明されているような、 JWT に署名するために使用される秘密鍵）は、認可スコープが クライアントの制御下にある保護されたリソース、または認可サーバーと 事前に取り決められた保護されたリソースに限定されている場合に、 認可グラントとして使用できます。クライアントクレデンシャルは、 認可サーバーと事前に取り決められた認可に基づいて、クライアントが 保護されたリソースへのアクセスを要求する場合に使用されます。¶

1.4.1. アクセストークンのスコープ

アクセストークンは、アクセスを付与するユーザーが持つ権限よりも 少ない権限でクライアントに発行されることを意図しています。 これは限定された "scope" アクセストークンとして知られています。 認可サーバーとリソースサーバーは、このスコープメカニズムを使用して、 特定のクライアントが持てるリソースの種類やアクセスレベルを 制限できます。¶

たとえば、クライアントはユーザーのリソースに対する "read" アクセスだけを 必要とし、リソースを更新する必要はない場合があります。そのため、 クライアントは認可サーバーによって定義された読み取り専用スコープを要求し、 リソースの更新には使用できないアクセストークンを取得できます。 これには、認可サーバー、リソースサーバー、およびクライアントの間の 調整が必要です。認可サーバーはクライアントに特定のスコープを 要求する能力を提供し、それらのスコープをクライアントに発行される アクセストークンに関連付けます。リソースサーバーは、限定スコープの アクセストークンが提示されたときにスコープを強制する責任を負います。¶

OAuth はスコープ値を定義しません。代わりに、スコープは 認可サーバー、または OAuth の拡張やプロファイルによって定義されます。 スコープを定義するそのような拡張の 1 つに [OpenID.Connect] があり、これは ユーザーのプロファイル情報への細粒度アクセスを提供するスコープの集合を 定義します。既知の拡張のスコープと衝突するカスタムスコープを 定義することは避けることが推奨されます。¶

限定スコープのアクセストークンを要求するために、クライアントは 使用されるグラント種別に応じて、認可エンドポイントまたはトークンエンドポイントで scope リクエストパラメーターを使用します。次に、認可サーバーは scope レスポンスパラメーターを使用して、発行されたアクセストークンのスコープを クライアントに通知します。¶

scope パラメーターの値は、大文字小文字を区別する文字列の 空白区切りリストとして表現されます。文字列は認可サーバーによって 定義されます。値に複数の空白区切り文字列が含まれる場合、 それらの順序は重要ではなく、各文字列は要求されたスコープに 追加のアクセス範囲を加えます。¶

    scope       = scope-token *( SP scope-token )
    scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

認可サーバーは、認可サーバーのポリシーまたはリソース所有者の指示に 基づいて、クライアントが要求したスコープを完全に、または部分的に 無視してもよいです (MAY)。発行されたアクセストークンのスコープが クライアントによって要求されたものと異なる場合、認可サーバーは 実際に付与されたスコープをクライアントに通知するため、トークンレスポンス （Section 3.2.3）に scope レスポンスパラメーターを含めなければなりません (MUST)。¶

クライアントが認可を要求する際に scope パラメーターを省略した場合、 認可サーバーは事前定義されたデフォルト値を使用してリクエストを 処理するか、無効なスコープを示してリクエストを失敗させなければなりません (MUST)。 認可サーバーは、そのスコープ要件とデフォルト値（定義されている場合）を 文書化するべきです (SHOULD)。¶

1.4.2. Bearer Token

Bearer Token は、トークンを保持する任意の当事者（"bearer"）が、 それを保持する他の当事者と同じ方法でそのトークンを使用できるという 性質を持つセキュリティトークンです。Bearer Token の使用は、 bearer が暗号鍵材料の所持（proof-of-possession）を証明することを 要求しません。¶

Bearer Token は、DPoP [RFC9449] や mTLS [RFC8705] などの proof-of-possession 仕様によって拡張され、 proof-of-possession 特性を提供できます。¶

アクセストークンの開示から保護するため、クライアントとリソースサーバー間の 通信相互作用は、Section 1.5 で説明される 機密性および完全性保護を利用しなければなりません (MUST)。¶

bearer token の特定の構造や形式に関する要件はありません。 bearer token が認可情報への参照である場合、そのような参照は、 十分に長い暗号学的にランダムな文字列を使用するなどして、攻撃者が 推測できないものでなければなりません (MUST)。bearer token がトークン自体に 認可情報を含めるためにエンコーディングメカニズムを使用する場合、 アクセストークンは、トークンが変更されることを防ぐのに十分な 完全性保護を使用しなければなりません (MUST)。アクセストークンの エンコードおよび署名メカニズムの一例は、JSON Web Token Profile for Access Tokens [RFC9068] に記述されています。¶

1.4.3. 送信者制約付きアクセストークン

送信者制約付きアクセストークンは、アクセストークンの使用を 特定の送信者に結び付けます。この送信者は、受信者 （たとえばリソースサーバー）でそのアクセストークンが受け入れられるための 前提条件として、特定の秘密の知識を示す義務があります。¶

認可サーバーおよびリソースサーバーは、OAuth Demonstration of Proof of Possession (DPoP) [RFC9449] または Mutual TLS for OAuth 2.0 [RFC8705] などの、アクセストークンを送信者制約付きにする メカニズムを使用するべきです (SHOULD)。 盗難または漏えいしたアクセストークンの悪用を防ぐには、 [RFC9700] の Section 4.10.1 を参照してください。¶

クライアントとリソースサーバーの間でエンドツーエンド TLS を使用することが 推奨されます (RECOMMENDED)。TLS トラフィックを中間者で終端する必要がある場合は、 さらなるセキュリティ上の助言について [RFC9700] の Section 4.13 を参照してください。¶

2.3.1. 登録 要件

認可サーバーは、クライアントに完全な redirect URI （パスコンポーネントを含む）を登録することを要求しなければなりません (MUST)。 認可サーバーは、登録済みのものと完全に一致しない redirect URI を 指定する認可リクエストを拒否しなければなりません (MUST)。ただし、 ループバックリダイレクトは例外であり、ポート URI コンポーネントを除き 完全一致が必要です。詳細については Section 4.1.1 を参照してください。¶

認可サーバーは、クライアントが複数の redirect URI を登録することを 許可してもよいです (MAY)。¶

登録は、認可サーバーでクライアント情報を設定する手動手順などの 帯域外で発生する場合もあれば、Pushed Authorization Requests [RFC9126] における初期 POST のように 実行時に発生する場合もあります。¶

私的使用 URI スキームベースの redirect URI について、 認可サーバーは、クライアントが逆ドメイン名ベースのスキームを使用するという Section 8.4.3 の要件を強制するべきです (SHOULD)。 少なくとも、ピリオド文字（.）を含まない私的使用 URI スキームは 拒否されるべきです (SHOULD)。¶

衝突耐性の性質に加えて、これは 2 つのアプリが同じ 私的使用 URI スキームを主張する紛争（片方のアプリが悪意を持っている場合）において、 所有権を証明する助けとなります。たとえば、2 つのアプリが com.example.app を主張した場合、 example.com の所有者はアプリストア運営者に対し、 偽造アプリの削除を申し立てることができます。汎用 URI スキームが 使用された場合、そのような申し立てを証明することはより困難です。¶

クライアントは、クエリパラメーターから取得した任意の URI へ ユーザーのブラウザを転送する URL（"open redirector"）を公開してはなりません (MUST NOT)。 これは Section 7.12 で説明されています。 Open redirector は、認可コードおよびアクセストークンの流出を可能にし得ます。¶

クライアントは、リクエストごとに redirect URI を変えるのではなく、 必要に応じてリクエストごとのカスタマイズを実現するために state リクエストパラメーターを使用してもよいです (MAY)。¶

redirect URI の登録を要求しない場合、攻撃者は Section 7.12 で説明されるように、 認可エンドポイントを open redirector として使用できます。¶

2.3.2. 複数の Redirect URI

クライアントに複数の redirect URI が登録されている場合、 クライアントは認可リクエストに redirect_uri リクエストパラメーター （Section 4.1.1）を使用して redirect URI を 含めなければなりません (MUST)。 クライアントに単一の redirect URI のみが登録されている場合、 redirect_uri リクエストパラメーターは任意です。¶

2.3.3. CSRF 攻撃の防止

クライアントは Cross-Site Request Forgery (CSRF) 攻撃を防がなければ なりません (MUST)。この文脈で CSRF とは、認可サーバーからではなく、 悪意ある第三者から発生したリダイレクトエンドポイントへのリクエストを指します （詳細については [RFC6819] の Section 4.4.1.8 を参照）。 認可サーバーが code_challenge パラメーターをサポートしていることを 確認したクライアントは、そのメカニズムによって提供される CSRF 保護に 依存してもよいです (MAY)。OpenID Connect フローでは、 nonce パラメーターを検証することで CSRF 保護が提供されます。 それ以外の場合、ユーザーエージェントに安全に結び付けられた state パラメーター内の一回限り使用の CSRF トークンを、 CSRF 保護のために使用しなければなりません (MUST) （Section 7.9 を参照）。¶

2.3.4. Mix-Up 攻撃の防止

OAuth クライアントが 1 つの認可サーバーとのみ相互作用できる場合、 mix-up 防御は不要です。しかし、OAuth クライアントが 2 つ以上の認可サーバーと 相互作用するシナリオでは、クライアントは mix-up 攻撃を防がなければなりません (MUST)。 mix-up 攻撃を防ぐために、クライアントは、それぞれのリクエストを送信した 発行者からのリダイレクトレスポンスのみを、かつこの認可リクエストが 開始された同じユーザーエージェントからのものとしてのみ処理しなければなりません (MUST)。¶

mix-up 攻撃に対する 2 つの異なる防御の詳細な説明については Section 7.14 を参照してください。¶

2.3.5. 無効なエンドポイント

認可リクエストが、欠落、無効、または不一致の redirect URI のために 検証に失敗した場合、認可サーバーはリソース所有者にエラーを 通知するべきであり (SHOULD)、ユーザーエージェントを無効な redirect URI へ 自動的にリダイレクトしてはなりません (MUST NOT)。¶

2.3.6. エンドポイントの内容

クライアントのエンドポイントへのリダイレクトリクエストは、通常、 ユーザーエージェントによって処理される HTML 文書レスポンスになります。 HTML レスポンスがリダイレクトリクエストの結果として直接提供される場合、 HTML 文書に含まれる任意のスクリプトは、redirect URI とそれに含まれる 生成物（たとえば認可コード）への完全なアクセス権で実行されます。 さらに、認可コードを含むリクエスト URL は、ページに読み込まれる 埋め込み画像、スタイルシート、およびその他の要素へ HTTP Referer ヘッダーで 送信される場合があります。¶

クライアントは、redirect URI エンドポイントレスポンスに 第三者スクリプト（たとえば、第三者アナリティクス、ソーシャルプラグイン、 広告ネットワーク）を含めるべきではありません (SHOULD NOT)。代わりに、 URI から生成物を抽出し、生成物を（URI 内でもそれ以外でも）露出しない 別のエンドポイントへユーザーエージェントを再度リダイレクトするべきです (SHOULD)。 第三者スクリプトが含まれる場合、クライアントは、URI からクレデンシャルを 抽出して削除するために使用される自身のスクリプトが最初に実行されることを 保証しなければなりません (MUST)。¶

2.4.1. クライアントシークレット

クライアントシークレットを所持する confidential client をサポートするため、 認可サーバーは、クライアントがリクエストボディコンテンツ内で 次のパラメーターを使用してクライアントクレデンシャルを含めることを サポートしなければなりません (MUST):¶

"client_id":

REQUIRED。Section 2.2 で説明される登録プロセス中に クライアントへ発行されたクライアント識別子。¶

"client_secret":

REQUIRED。クライアントシークレット。¶

パラメーターはリクエストコンテンツ内でのみ送信でき、 リクエスト URI に含めてはなりません (MUST NOT)。¶

これは [RFC7591] の Section 2 で定義される client_secret_post としても知られています。¶

たとえば、コンテンツパラメーターを使用してアクセストークンを更新する リクエスト（Section 4.3） （表示目的のためだけに追加の改行を含む）:¶

POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw

認可サーバーは、クライアントシークレットを発行されたクライアントを 認証するために、HTTP Basic 認証スキームをサポートしてもよいです (MAY)。¶

[RFC9110] の Section 11 で定義される HTTP Basic 認証スキームを使用して 認可サーバーで認証する場合、クライアント識別子は Appendix B に従い application/x-www-form-urlencoded エンコーディングアルゴリズムを使用して エンコードされ、そのエンコード値がユーザー名として使用されます。 クライアントシークレットは同じアルゴリズムを使用してエンコードされ、 パスワードとして使用されます。¶

これは [RFC7591] の Section 2 で定義される client_secret_basic としても知られています。¶

例（表示目的のためだけに追加の改行を含む）:¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

注記: クライアント識別子とシークレットを最初にフォームエンコードし、 その後エンコードされた値を HTTP Basic 認証のユーザー名および パスワードとして使用するこの方法は、過去に多くの相互運用性の問題を 引き起こしてきました。一部の実装はエンコード手順を見落としたり、 特定の文字だけをエンコードすることを決めたり、クレデンシャル検証時に エンコード要件を無視したりしたため、クライアントは個々の認可サーバーに クレデンシャルを提示する方法を特別扱いしなければならなくなりました。 リクエストボディコンテンツにクレデンシャルを含めることは、 エンコーディングの問題を避け、より相互運用性の高い実装につながります。¶

クライアントシークレット認証方式はパスワードを伴うため、 認可サーバーはそれを利用する任意のエンドポイントを ブルートフォース攻撃から保護しなければなりません (MUST)。¶

2.4.2. その他の 認証方式

認可サーバーは、そのセキュリティ要件に一致する任意の適切な 認証スキームをサポートしてもよいです (MAY)。その他の認証方式を 使用する場合、認可サーバーはクライアント識別子（登録レコード）と 認証スキームとの間の対応付けを定義しなければなりません (MUST)。¶

mTLS [RFC8705] や Private Key JWT（[RFC7523]、 [I-D.ietf-oauth-rfc7523bis]）などの 追加の認証方式は、 "OAuth Token Endpoint Authentication Methods" レジストリで定義されており、 トークンエンドポイント保護という特定の用途を超えた汎用的な クライアント認証方式として有用な場合があります。¶

3.2.1. クライアント 認証

confidential client は、トークンエンドポイントへリクエストを行う際に、 Section 2.4 で説明されるように 認可サーバーで認証しなければなりません (MUST)。¶

クライアント認証は次の目的で使用されます:¶

• リフレッシュトークンおよび認可コードを、 それらが発行されたクライアントに結び付けることを強制するため。 クライアント認証は、認可コードが安全でないチャネル上で リダイレクトエンドポイントへ送信される場合に、追加のセキュリティレイヤーを 加えます。¶

• 侵害されたクライアントから回復するために、 クライアントを無効化するか、そのクレデンシャルを変更し、 攻撃者が盗まれたリフレッシュトークンを悪用することを防ぎます。 クライアントクレデンシャルの単一セットを変更することは、 リフレッシュトークンの全体セットを取り消すよりも大幅に高速です。¶

• 定期的なクレデンシャルローテーションを必要とする 認証管理のベストプラクティスを実装するため。リフレッシュトークンの 全体セットのローテーションは困難な場合がありますが、クライアント クレデンシャルの単一セットのローテーションは大幅に容易です。¶

3.2.2. トークンエンドポイント リクエスト

クライアントは、HTTP リクエストコンテンツ内で UTF-8 の 文字エンコーディングを用い、Appendix C.2 に従った フォームエンコードシリアル化形式を使用して、次のパラメーターを送信することにより トークンエンドポイントへリクエストを行います:¶

"grant_type":

REQUIRED。特定のトークンリクエストでクライアントが使用する グラント種別の識別子。 この仕様は値 authorization_code、 refresh_token、および client_credentials を定義します。 グラント種別は、トークンリクエストでさらに必要またはサポートされる パラメーターを決定します。それらのグラント種別の詳細は以下で定義されます。¶

"client_id":

OPTIONAL。パラメーターに依存する形式の クライアント認証が使用される場合、または grant_type が public client の識別を必要とする場合、クライアント識別子が必要です。¶

confidential client は、Section 3.2.1 で説明されるように、 認可サーバーで認証しなければなりません (MUST)。¶

たとえば、クライアントは次の HTTPS リクエストを行います （表示目的のためだけに追加の改行を含む）:¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

認可サーバーは次を行わなければなりません (MUST):¶

• confidential client（またはその他の認証要件を持つクライアント）に対して クライアント認証を要求すること、¶

• クライアント認証が含まれる場合、クライアントを認証すること¶

さらにグラント種別固有の処理規則が適用され、それぞれの グラント種別とともに指定されます。¶

3.2.3. トークンエンドポイント レスポンス

アクセストークンリクエストが有効で認可されている場合、 認可サーバーはアクセストークンと任意のリフレッシュトークンを発行します。¶

クライアント認証が失敗したか無効である場合、認可サーバーは Section 3.2.4 で説明されるエラーレスポンスを返します。¶

認可サーバーは、Appendix C.3 に従って HTTP レスポンスを作成し、 [RFC8259] で定義される application/json メディア型を使用し、次のパラメーターと HTTP 200 (OK) ステータスコードを用いて、アクセストークンと任意の リフレッシュトークンを発行します:¶

"access_token":

REQUIRED。認可サーバーによって発行されたアクセストークン。¶

"token_type":

REQUIRED。Section 1.4 で説明される、 発行されたアクセストークンの種別。値は大文字小文字を区別しません。¶

"expires_in":

RECOMMENDED。アクセストークンの有効期間を秒単位で表す JSON 数値。たとえば、値 3600 は、レスポンスが生成された時点から 1 時間後にアクセストークンが失効することを示します。 省略された場合、認可サーバーは他の手段で有効期間を提供するか、 デフォルト値を文書化するべきです (SHOULD)。認可サーバーは アクセストークンを早期に失効させる可能性があり、クライアントは 提供された有効期間中アクセストークンが有効であることを期待しては ならないことに注意してください (MUST NOT)。¶

"scope":

クライアントによって要求されたスコープと同一である場合は RECOMMENDED。 それ以外の場合は REQUIRED。Section 1.4.1 で説明されるアクセストークンのスコープ。¶

"refresh_token":

OPTIONAL。対応するトークンリクエストで渡されたグラントに基づいて 新しいアクセストークンを取得するために使用できるリフレッシュトークン。¶

認可サーバーは、リスク評価および自らのポリシーに基づいて、 特定のクライアントにリフレッシュトークンを発行するかどうかを 決定するべきです (SHOULD)。認可サーバーがリフレッシュトークンを 発行しないと決定した場合、クライアントは、たとえば新しい認可コード リクエストを開始するなど、OAuth フローを最初からやり直すことで 新しいアクセストークンを取得してもよいです (MAY)。そのような場合、 認可サーバーはユーザー体験を最適化するために Cookie や永続グラントを 利用する場合があります。¶

リフレッシュトークンが発行される場合、それらのリフレッシュトークンは リソース所有者によって同意されたスコープおよびリソースサーバーに 結び付けられなければなりません (MUST)。 これは、正当なクライアントによる権限昇格を防ぎ、 リフレッシュトークン漏えいの影響を低減するためです。¶

パラメーターは、Appendix C.3 で説明されるように JavaScript Object Notation (JSON) 構造へシリアル化されます。¶

認可サーバーは、トークン、クレデンシャル、またはその他の機密情報を 含む任意のレスポンスにおいて、値 no-store を持つ HTTP Cache-Control レスポンスヘッダーフィールド（[RFC9111] の Section 5.2 を参照）を含めなければなりません (MUST)。¶

例:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
  "example_parameter": "example_value"
}

クライアントは、レスポンス内の認識されない値名を無視しなければ なりません (MUST)。認可サーバーから受け取るトークンおよびその他の 値のサイズは未定義のままです。クライアントは値のサイズについて 仮定することを避けるべきです。認可サーバーは、自らが発行する 任意の値のサイズを文書化するべきです (SHOULD)。¶

3.2.4. トークンエンドポイント エラーレスポンス

認可サーバーは、HTTP 400 (Bad Request) ステータスコード （別段の指定がある場合を除く）で応答し、レスポンスに次の パラメーターを含めます:¶

"error":

REQUIRED。次の中からの単一の ASCII [USASCII] エラーコード:¶

"invalid_request":

リクエストに必須パラメーターが欠落している、 （グラント種別以外の）サポートされていないパラメーター値を 含んでいる、パラメーターを繰り返している、複数のクレデンシャルを 含んでいる、クライアントを認証するために複数のメカニズムを 利用している、認可リクエストで code_challenge が 送信されていないにもかかわらず code_verifier を含んでいる、 またはその他の形式不正である。¶

"invalid_client":

クライアント認証に失敗した （たとえば、未知のクライアント、クライアント認証が含まれていない、 またはサポートされていない認証方式）。認可サーバーは、 サポートされる HTTP 認証スキームを示すために HTTP 401 (Unauthorized) ステータスコードを返してもよいです (MAY)。 クライアントが Authorization リクエストヘッダーフィールドを介して 認証を試みた場合、認可サーバーは HTTP 401 (Unauthorized) ステータスコードで応答し、クライアントが使用した認証スキームに 一致する WWW-Authenticate レスポンスヘッダーフィールドを 含めなければなりません (MUST)。¶

"invalid_grant":

提供された認可グラント （たとえば、認可コード、リソース所有者クレデンシャル）または リフレッシュトークンが無効、失効済み、取り消し済みである、 認可リクエストで使用された redirect URI と一致しない、 または別のクライアントに発行されたものである。¶

"unauthorized_client":

認証されたクライアントは、この 認可グラント種別を使用することを認可されていない。¶

"unsupported_grant_type":

認可グラント種別は認可サーバーによって サポートされていない。¶

"invalid_scope":

要求されたスコープが無効、不明、 形式不正、またはリソース所有者によって付与されたスコープを 超えている。¶

error パラメーターの値は、 集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を 含んではなりません (MUST NOT)。¶

"error_description":

OPTIONAL。発生したエラーをクライアント開発者が 理解するのを支援するために使用される、追加情報を提供する 人間可読の ASCII [USASCII] テキスト。 error_description パラメーターの値は、集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んでは なりません (MUST NOT)。¶

"error_uri":

OPTIONAL。エラーに関する情報を持つ 人間可読の Web ページを識別する URI。クライアント開発者に エラーに関する追加情報を提供するために使用されます。 error_uri パラメーターの値は URI-reference 構文に適合しなければならず、 したがって集合 %x21 / %x23-5B / %x5D-7E の外の文字を 含んではなりません (MUST NOT)。¶

パラメーターは、Appendix C.3 で定義される application/json メディア型を使用して、HTTP レスポンスのコンテンツ内に 含まれます。¶

例:¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
 "error": "invalid_request"
}

4.1.1. 認可 リクエスト

認可リクエストを開始するために、クライアントは 認可サーバーの認可エンドポイント URI にパラメーターを追加して 認可リクエスト URI を構築します。クライアントは最終的に、 リクエストを開始するためにユーザーエージェントをこの URI へ リダイレクトします。¶

クライアントは、認可コードインジェクションおよび CSRF 攻撃から保護するために、認可リクエストごとに "code verifier" と呼ばれる一意の秘密値を使用します。 クライアントはまずコードベリファイアを生成し、次に認可リクエストに 含める "code challenge" を導出します。クライアントは、トークンエンドポイントで 認可コードを交換するときにコードベリファイアを使用し、 認可コードを使用しているクライアントが、それを要求した同じクライアントであることを 証明します。¶

クライアントは、Appendix C.1 で説明されるように、 認可エンドポイント URI のクエリコンポーネントに次のパラメーターを 追加してリクエスト URI を構築します:¶

"response_type":

REQUIRED。認可エンドポイントは、異なる リクエストパラメーターおよびレスポンスパラメーターの集合を サポートします。クライアントは特定の response_type 値を使用することで、フローの種別を決定します。この仕様は 値 code を定義しており、クライアントが認可コードフローを 使用したいことを示すために使用されなければなりません。¶

拡張レスポンス種別は、空白区切り（%x20）の 値リストを含んでもよく (MAY)、値の順序は重要ではありません （たとえば、レスポンス種別 a b は b a と同じです）。 そのような複合レスポンス種別の意味は、それぞれの仕様で定義されます。¶

一部の拡張レスポンス種別は [OpenID.Connect] によって定義されています。¶

認可リクエストに response_type パラメーターが欠落している場合、 またはレスポンス種別が理解されない場合、認可サーバーは Section 4.1.2.1 で説明されるエラーレスポンスを返さなければなりません (MUST)。¶

"client_id":

REQUIRED。Section 2.2 で説明される クライアント識別子。¶

"code_challenge":

Section 7.5.1 の 特定の要件が満たされない限り REQUIRED。コードベリファイアから 導出されたコードチャレンジ。¶

"code_challenge_method":

OPTIONAL。リクエストに存在しない場合は plain がデフォルトになります。コードベリファイア変換方式は S256 または plain です。¶

"redirect_uri":

このクライアントに登録されている redirect URI が 1 つだけの場合は OPTIONAL。 このクライアントに複数の redirect URI が登録されている場合は REQUIRED。 Section 2.3.2 を参照してください。¶

"scope":

OPTIONAL。 Section 1.4.1 で 説明されるアクセスリクエストのスコープ。¶

"state":

OPTIONAL。リクエストとコールバックの間で 状態を維持するためにクライアントが使用する不透明な値。 認可サーバーは、ユーザーエージェントをクライアントへ リダイレクトして戻す際にこの値を含めます。¶

code_verifier は、各認可リクエストごとに 生成される、一意で高エントロピーの暗号学的にランダムな文字列であり、 非予約文字 [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~" を使用し、 最小長 43 文字、最大長 128 文字です。¶

クライアントは code_verifier を一時的に保存し、 認可リクエストで使用する code_challenge を計算します。¶

code_verifier の ABNF は次のとおりです。¶

code-verifier = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

クライアントは、認可リクエストで code_verifier を公開しないコードチャレンジ方式を使用するべきです (SHOULD)。 そうでない場合、認可リクエストを読み取ることができる攻撃者 （[RFC9700] の Attacker A4 参照）は、このメカニズムによって提供される セキュリティを破ることができます。現在、S256 がそのような唯一の方式です。¶

NOTE: コードベリファイアは、その値を推測することが非現実的になるだけの 十分なエントロピーを持つべきです (SHOULD)。32 オクテットの シーケンスを作成するために、適切な乱数生成器の出力を使用することが 推奨されます (RECOMMENDED)。その後、オクテットシーケンスは base64url エンコードされ、 コードベリファイアとして使用する 43 オクテットの URL 安全文字列を生成します。¶

次に、クライアントはコードベリファイアに対して次のいずれかの 変換を使用することにより、コードベリファイアから導出された code_challenge を作成します:¶

S256
  code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

plain
  code_challenge = code_verifier

クライアントが S256 を使用できる場合、 S256 を使用しなければなりません (MUST)。 S256 はサーバーにおいて Mandatory To Implement (MTI) であるためです。 クライアントが plain を使用することが許可されるのは、 たとえばハッシュ関数が利用できない制約環境など、何らかの技術的理由により S256 をサポートできず、かつ帯域外設定または Authorization Server Metadata [RFC8414] を通じて、サーバーが plain をサポートしていることを知っている場合のみです。¶

code_challenge の ABNF は次のとおりです。¶

code-challenge = 43*128unreserved
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39

プロパティ code_challenge および code_verifier は、"Proof-Key for Code Exchange"、すなわち PKCE [RFC7636] として知られる OAuth 2.0 拡張から採用されたものであり、 この技術はそこで最初に開発されました。¶

認可サーバーは code_challenge および code_verifier パラメーターをサポートしなければなりません (MUST)。¶

クライアントは code_challenge および code_verifier を使用しなければならず (MUST)、 認可サーバーは Section 7.5.1 で説明される条件下を除き、その使用を強制しなければなりません (MUST)。 その場合であっても、上記のように code_challenge および code_verifier を使用し強制することは、なお推奨されます (RECOMMENDED)。¶

state および scope パラメーターは、 機密性の高いクライアント情報またはリソース所有者情報を平文で 含めるべきではありません (SHOULD NOT)。それらは安全でないチャネルで 送信されたり、安全でない方法で保存されたりする可能性があるためです。¶

クライアントは、HTTP リダイレクト、またはユーザーエージェントを介して 利用可能なその他の手段を使用して、構築された URI へ リソース所有者を誘導します。¶

たとえば、クライアントはユーザーエージェントに次の HTTPS リクエストを行わせます（表示目的のためだけに追加の改行を含む）:¶

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
    &code_challenge=6fdkQaPm51l13DSukcAH3Mdx7_ntecHYd1vi3n0hMZY
    &code_challenge_method=S256 HTTP/1.1
Host: server.example.com

認可サーバーは、すべての必須パラメーターが存在し、 有効であることを確認するためにリクエストを検証します。¶

特に、認可サーバーは、リクエストに redirect_uri が存在する場合、それを検証しなければならず (MUST)、 クライアント登録（Section 2）中に 以前に確立された登録済み redirect URI の 1 つと一致することを 確認しなければなりません。2 つの URI を比較する際、認可サーバーは それら 2 つの URI が等しいことを保証しなければなりません (MUST)。 詳細については、Simple String Comparison である [RFC3986] の Section 6.2.1 を参照してください。 唯一の例外は、localhost URI を使用するネイティブアプリです。この場合、 認可サーバーは [RFC8252] の Section 7.3 で説明されるように、可変ポート番号を許可しなければなりません (MUST)。¶

リクエストが有効な場合、 認可サーバーはリソース所有者を認証し、（リソース所有者に尋ねるか、 または他の手段で承認を確立することにより）認可判断を取得します。¶

判断が確立されると、認可サーバーは HTTP リダイレクトレスポンス、 またはユーザーエージェントを介して利用可能なその他の手段を使用して、 ユーザーエージェントを提供されたクライアント redirect URI へ誘導します。¶

4.1.2. 認可 レスポンス

リソース所有者がアクセスリクエストを許可した場合、 認可サーバーは認可コードを発行し、拡張で別段の指定がない限り、 Appendix C.1 で 説明されるクエリ文字列シリアル化を使用して、次のパラメーターを redirect URI のクエリコンポーネントに追加することにより、 それをクライアントへ配信します:¶

"code":

REQUIRED。認可コードは認可サーバーによって生成され、 クライアントにとって不透明です。認可コードは、漏えいのリスクを 軽減するために、発行後すぐに失効しなければなりません (MUST)。 認可コードの最大有効期間は 10 分が推奨されます (RECOMMENDED)。 認可コードは、クライアント識別子、コードチャレンジ、および redirect URI に結び付けられます。¶

"state":

クライアントの認可リクエストに state パラメーターが存在した場合は REQUIRED。 クライアントから受け取った正確な値。¶

"iss":

OPTIONAL。クライアントが複数の認可サーバーと 相互作用する場合に、mix-up 攻撃を防ぐために使用できる 認可サーバーの識別子。このパラメーターが必要になる場合と、 クライアントがそれを使用して mix-up 攻撃を防ぐ方法に関する 追加の詳細については、Section 7.14 および [RFC9207] を参照してください。¶

たとえば、認可サーバーは次の HTTP レスポンスを送信することで ユーザーエージェントをリダイレクトします:¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

クライアントは認識されないレスポンスパラメーターを 無視しなければなりません (MUST)。認可コード文字列のサイズは この仕様では未定義のままです。クライアントはコード値のサイズに関して 仮定することを避けるべきです。認可サーバーは、自らが発行する 任意の値のサイズを文書化するべきです (SHOULD)。¶

認可サーバーは、後でコードチャレンジを検証できるよう、 code_challenge および code_challenge_method 値を、発行された認可コードに 関連付けなければなりません (MUST)。¶

サーバーが code_challenge を 発行されたコードに関連付けるために使用する正確な方法は、 この仕様の範囲外です。コードチャレンジはサーバー上に保存され、 そこでコードと関連付けられる場合があります。code_challenge および code_challenge_method 値は、コード自体に暗号化された形式で 保存されてもよいですが、サーバーは AS 以外の主体が抽出できる形式で、 レスポンスパラメーターに code_challenge 値を含めては なりません (MUST NOT)。¶

クライアントは、攻撃者による認可コードの 認可レスポンスへの注入（リプレイ）を防がなければなりません (MUST)。 code_challenge および code_verifier を使用することで、 認可サーバーが一致しない code_verifier を持つ トークンリクエストを拒否するため、認可コードの注入を防ぎます。 詳細については Section 7.5.1 を参照してください。¶

HTTP/1.1 302 Found
Location: https://client.example.com/cb?error=access_denied
          &state=xyz&iss=https%3A%2F%2Fauthorization-server.example.com

4.1.3. トークンエンドポイント 拡張

認可グラント種別は、トークンエンドポイントにおいて authorization_code の grant_type 値で識別されます。¶

この値が設定されている場合、Section 3.2.2 を 超えて次の追加トークンリクエストパラメーターがサポートされます:¶

"code":

REQUIRED。認可サーバーから受け取った認可コード。¶

"code_verifier":

認可リクエストに code_challenge パラメーターが 含まれていた場合は REQUIRED。それ以外では使用してはなりません (MUST NOT)。 元のコードベリファイア文字列。¶

"client_id":

クライアントが Section 3.2.1 で説明されるように 認可サーバーで認証していない場合は REQUIRED。¶

認可サーバーは、与えられた認可コードに対して アクセストークンを一度だけ返さなければなりません (MUST)。¶

以前に成功したトークンリクエストと同じ認可コードで 2 回目の有効なトークンリクエストが行われた場合、 認可サーバーはリクエストを拒否しなければならず (MUST)、 その認可コードに基づいて以前に発行されたすべてのアクセストークンおよび リフレッシュトークンを（可能であれば）取り消すべきです (SHOULD)。 さらなる詳細については Section 7.5.2 を 参照してください。¶

たとえば、クライアントは次の HTTPS リクエストを行います （表示目的のためだけに追加の改行を含む）:¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&code_verifier=3641a2d12d66101249cdf7a79c000c1f8c05d2aafcf14bf146497bed

Section 3.2.2 の処理規則に加えて、 認可サーバーは次を行わなければなりません (MUST):¶

• 認可コードが、認証済みの confidential client に発行されたことを確認する、またはクライアントが public である場合は、 リクエスト内の client_id に発行されたことを確認する、¶

• 認可コードが有効であることを検証する、¶

• 認可リクエストに code_challenge パラメーターが存在した場合に限り、 code_verifier パラメーターが存在することを検証する、¶

• code_verifier が存在する場合、 まずクライアントによって指定された code_challenge_method 方式に従って それを変換し、その後、受け取った code_verifier から コードチャレンジを計算して、以前に関連付けられた code_challenge と比較することにより code_verifier を検証する、および¶

• トークンリクエスト内の認可コードに関連付けられた 認可リクエストに code_challenge が存在しなかった場合、 認可サーバーはトークンリクエストを拒否しなければなりません (MUST)。¶

トークンリクエスト内の redirect_uri パラメーターに関する OAuth 2.0 クライアントとの後方互換性の詳細については、 Section 10.2 を参照してください。¶

4.2.1. トークンエンドポイント 拡張

クライアントクレデンシャルグラント種別は、トークン エンドポイントにおいて client_credentials の grant_type 値で 識別されます。¶

この値が設定されている場合、Section 3.2.2 を 超えて次の追加トークンリクエストパラメーターがサポートされます:¶

"scope":

OPTIONAL。 Section 1.4.1 で 説明されるアクセスリクエストのスコープ。¶

たとえば、クライアントはトランスポート層セキュリティを使用して 次の HTTP リクエストを行います（表示目的のためだけに追加の改行を含む）:¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

認可サーバーはクライアントを認証しなければなりません (MUST)。¶

4.3.1. トークンエンドポイント 拡張

リフレッシュトークングラント種別は、トークンエンドポイントにおいて refresh_token の grant_type 値で識別されます。¶

この値が設定されている場合、Section 3.2.2 を超えて 次の追加パラメーターがサポートされます:¶

"refresh_token":

REQUIRED。クライアントに発行されたリフレッシュトークン。¶

"scope":

OPTIONAL。 Section 1.4.1 で 説明されるアクセスリクエストのスコープ。 要求されたスコープは、リソース所有者によって最初に付与された ものではないスコープを含んではならず (MUST NOT)、省略された場合は リソース所有者によって最初に付与されたスコープと等しいものとして 扱われます。¶

リフレッシュトークンは通常、追加のアクセストークンを 要求するために使用される長期的なクレデンシャルであるため、 リフレッシュトークンはそれが発行されたクライアントに結び付けられます。 confidential client は、Section 3.2.1 で説明されるように、認可サーバーで認証しなければなりません (MUST)。¶

たとえば、クライアントはトランスポート層セキュリティを使用して 次の HTTP リクエストを行います（表示目的のためだけに追加の改行を含む）:¶

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Section 3.2.2 の処理規則に加えて、 認可サーバーは次を行わなければなりません (MUST):¶

• クライアント認証がリクエストに含まれる場合、 リフレッシュトークンが認証済みクライアントに発行されたことを確認する、 または client_id がリクエストに含まれる場合、リフレッシュトークンが 一致するクライアントに発行されたことを確認する¶

• このリフレッシュトークンに対応するグラントが まだ有効であることを検証する¶

• リフレッシュトークンを検証する¶

認可サーバーは、public client に対する悪意ある行為者による リフレッシュトークンリプレイを検出するために、次のいずれかの方法を 利用しなければなりません (MUST):¶

• 送信者制約付きリフレッシュトークン: 認可サーバーは、たとえば DPoP [RFC9449] または mTLS [RFC8705] を利用することにより、 リフレッシュトークンを特定のクライアントインスタンスに 暗号学的に結び付けます。¶

• リフレッシュトークンローテーション: 認可サーバーは、アクセストークン更新レスポンスごとに 新しいリフレッシュトークンを発行します。以前のリフレッシュトークンは 無効化されますが、その関係に関する情報は認可サーバーによって 保持されます。リフレッシュトークンが侵害され、その後攻撃者と 正当なクライアントの両方によって使用された場合、そのうちの一方が 無効化されたリフレッシュトークンを提示することになり、これにより 認可サーバーは侵害を知ることができます。認可サーバーは どちらの当事者が無効なリフレッシュトークンを提出したかを判断できませんが、 アクティブなリフレッシュトークンと、それに関連付けられたアクセス認可 グラントも取り消します。これにより、正当なクライアントに新しい 認可グラントの取得を強制する代償を払って、攻撃の進行を停止します。¶

実装上の注記: リフレッシュトークンが属するグラントは、 リフレッシュトークン自体にエンコードされる場合があります。これにより、 認可サーバーはリフレッシュトークンが属するグラントを効率的に判断でき、 ひいては取り消す必要があるすべてのリフレッシュトークンを判断できます。 この場合、認可サーバーは、たとえば署名を使用して、 リフレッシュトークン値の完全性を保証しなければなりません (MUST)。¶

4.3.2. リフレッシュトークン レスポンス

有効で認可されている場合、認可サーバーは Section 3.2.3 で説明されるようにアクセストークンを発行します。¶

認可サーバーは新しいリフレッシュトークンを発行してもよく (MAY)、 その場合、クライアントは古いリフレッシュトークンを破棄し、 新しいリフレッシュトークンに置き換えなければなりません (MUST)。¶

4.3.3. リフレッシュトークン 推奨事項

認可サーバーは、クライアントに新しいリフレッシュトークンを 発行した後、古いリフレッシュトークンを取り消してもよいです (MAY)。 新しいリフレッシュトークンが発行される場合、リフレッシュトークンの スコープは、クライアントがリクエストに含めたリフレッシュトークンの スコープと同一でなければなりません (MUST)。¶

認可サーバーは、次のようなセキュリティイベントの場合に リフレッシュトークンを自動的に取り消してもよいです (MAY):¶

• パスワード変更¶

• 認可サーバーでのログアウト¶

クライアントが一定期間非アクティブであった場合、 すなわちリフレッシュトークンが一定期間新しいアクセストークンを 取得するために使用されていない場合、リフレッシュトークンは 失効するべきです (SHOULD)。失効時刻は認可サーバーの裁量によります。 これはグローバル値である場合もあれば、クライアントポリシーまたは リフレッシュトークンに関連付けられたグラント（およびその機密性）に 基づいて決定される場合もあります。¶

5.1.1. Authorization リクエストヘッダーフィールド

HTTP/1.1 [RFC7235] によって定義される Authorization リクエストヘッダーフィールドでアクセストークンを 送信する場合、クライアントはアクセストークンを送信するために Bearer スキームを使用します。¶

例:¶

 GET /resource HTTP/1.1
 Host: server.example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

このスキームにおける Authorization ヘッダーフィールドの構文は、 [RFC2617] の Section 2 で 定義される Basic スキームの使用法に従います。 Basic と同様に、これは [RFC2617] の Section 1.2 で定義される 汎用構文には準拠していませんが、既存の配備を反映するために そこで概説される推奨プラクティスには従わないものの、 HTTP 1.1 Authentication [RFC7235] の 一般認証フレームワークとは互換性があります。 Bearer クレデンシャルの構文は次のとおりです:¶

token68    = 1*( ALPHA / DIGIT /
                 "-" / "." / "_" / "~" / "+" / "/" ) *"="
credentials = "bearer" 1*SP token68

クライアントは、Bearer HTTP 認可スキームを持つ Authorization リクエストヘッダーフィールドを使用して、 bearer token による認証済みリクエストを行うべきです (SHOULD)。 リソースサーバーはこの方法をサポートしなければなりません (MUST)。¶

[RFC9110] の Section 11.1 で説明されるように、 文字列 bearer は大文字小文字を区別しません。これは、次のすべてが Authorization ヘッダーの有効な使用法であることを意味します:¶

• Authorization: Bearer mF_9.B5f-4.1JqM¶

• Authorization: bearer mF_9.B5f-4.1JqM¶

• Authorization: BEARER mF_9.B5f-4.1JqM¶

• Authorization: bEaReR mF_9.B5f-4.1JqM¶

5.1.2. フォームエンコードされた コンテンツパラメーター

HTTP リクエストコンテンツでアクセストークンを送信する場合、 クライアントは access_token パラメーターを使用して リクエストコンテンツにアクセストークンを追加します。クライアントは、 次のすべての条件が満たされない限り、この方法を使用してはなりません (MUST NOT):¶

• HTTP リクエストが、application/x-www-form-urlencoded に 設定された Content-Type ヘッダーフィールドを含むこと。¶

• コンテンツが、URL Living Standard [WHATWG.URL] によって定義される application/x-www-form-urlencoded content-type の エンコーディング要件に従うこと。¶

• HTTP リクエストコンテンツが単一パートであること。¶

• リクエスト内でエンコードされるコンテンツは、 完全に ASCII [USASCII] 文字で構成されなければなりません (MUST)。¶

• HTTP リクエストメソッドは、コンテンツに 定義済みのセマンティクスがあるものであること。特に、これは GET メソッドを使用してはならない (MUST NOT) ことを意味します。¶

コンテンツは他のリクエスト固有パラメーターを含んでもよく (MAY)、 その場合、access_token パラメーターは & 文字 （ASCII コード 38）を使用してリクエスト固有パラメーターから 適切に分離されなければなりません (MUST)。¶

たとえば、クライアントはトランスポート層セキュリティを使用して 次の HTTP リクエストを行います:¶

POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded

access_token=mF_9.B5f-4.1JqM

application/x-www-form-urlencoded 方式は、 参加するクライアントが Authorization リクエストヘッダーフィールドへ アクセスできないアプリケーションコンテキストを除いて、使用されるべきではありません (SHOULD NOT)。 リソースサーバーはこの方法をサポートしてもよいです (MAY)。¶

5.3.1. WWW-Authenticate レスポンスヘッダーフィールド

保護されたリソースリクエストに認証クレデンシャルが 含まれていない場合、または保護されたリソースへのアクセスを可能にする アクセストークンが含まれていない場合、リソースサーバーは HTTP WWW-Authenticate レスポンスヘッダーフィールドを含めなければなりません (MUST)。 他の条件へのレスポンスにもこれを含めてもよいです (MAY)。 WWW-Authenticate ヘッダーフィールドは、HTTP/1.1 [RFC7235] によって定義されるフレームワークを使用します。¶

このトークン種別のすべてのチャレンジは、auth-scheme 値 Bearer を使用しなければなりません (MUST)。このスキームには 1 つ以上の auth-param 値が続かなければなりません (MUST)。 このトークン種別についてこの仕様で使用または定義される auth-param 属性は次のとおりです。その他の auth-param 属性も 使用してもよいです (MAY)。¶

"realm":

HTTP/1.1 [RFC7235] で 説明される方法で保護の範囲を示すために、 realm 属性を含めてもよいです (MAY)。 realm 属性は複数回出現してはなりません (MUST NOT)。¶

"scope":

scope 属性は Section 1.4.1 で 定義されています。scope 属性は、大文字小文字を区別する スコープ値の空白区切りリストであり、要求されたリソースに アクセスするためにアクセストークンに必要なスコープを示します。 scope 値は実装定義であり、それらのための集中レジストリはありません。 許可される値は認可サーバーによって定義されます。 scope 値の順序は重要ではありません。場合によっては、 保護されたリソースを利用するために十分なアクセススコープを持つ 新しいアクセストークンを要求する際に、scope 値が使用されます。 scope 属性の使用は OPTIONAL です。scope 属性は 複数回出現してはなりません (MUST NOT)。scope 値は プログラムによる使用を意図しており、エンドユーザーに表示されることを 意図していません。¶

2 つのスコープ値の例を以下に示します。 これらはそれぞれ、OpenID Connect [OpenID.Messages] および Open Authentication Technology Committee (OATC) Online Multimedia Authorization Protocol [OMAP] OAuth 2.0 ユースケースから取られています:¶

scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"

¶

"error":

保護されたリソースリクエストがアクセストークンを 含んでおり、認証に失敗した場合、リソースサーバーは アクセスリクエストが拒否された理由をクライアントに提供するために error 属性を含めるべきです (SHOULD)。パラメーター値は Section 5.3.2 で説明されます。¶

"error_description":

リソースサーバーは、開発者に エンドユーザーに表示されることを意図しない人間可読の説明を 提供するために、error_description 属性を含めてもよいです (MAY)。¶

"error_uri":

リソースサーバーは、エラーを説明する 人間可読の Web ページを識別する絶対 URI を持つ error_uri 属性を含めてもよいです (MAY)。¶

error、error_description、および error_uri 属性は複数回出現してはなりません (MUST NOT)。¶

Appendix A.4 で指定される scope 属性の値は、スコープ値を表すための集合 %x21 / %x23-5B / %x5D-7E、およびスコープ値間の区切り文字である %x20 の外の文字を含んではなりません (MUST NOT)。 Appendix A.7 および Appendix A.8 で指定される error および error_description 属性の値は、 集合 %x20-21 / %x23-5B / %x5D-7E の外の文字を含んでは なりません (MUST NOT)。 Appendix A.9 で指定される error_uri 属性の値は、URI-reference 構文に適合しなければならず、 したがって集合 %x21 / %x23-5B / %x5D-7E の外の文字を 含んではなりません (MUST NOT)。¶

5.3.2. エラーコード

リクエストが失敗した場合、リソースサーバーは 適切な HTTP ステータスコード（通常は 400、401、403、または 405）を使用して応答し、 レスポンスに次のエラーコードのいずれかを含めます:¶

"invalid_request":

リクエストに必須パラメーターが欠落している、 サポートされていないパラメーターまたはパラメーター値を含んでいる、 同じパラメーターを繰り返している、アクセストークンを含めるために 複数の方法を使用している、またはその他の形式不正である。 リソースサーバーは HTTP 400 (Bad Request) ステータスコードで 応答するべきです (SHOULD)。¶

"invalid_token":

提供されたアクセストークンが失効済み、取り消し済み、 形式不正、またはその他の理由で無効である。リソースサーバーは HTTP 401 (Unauthorized) ステータスコードで応答するべきです (SHOULD)。 クライアントは新しいアクセストークンを要求し、保護されたリソースリクエストを 再試行してもよいです (MAY)。¶

"insufficient_scope":

リクエストは、クライアントに付与されアクセストークンによって 表されるスコープよりも高い権限（スコープ）を必要とする。 リソースサーバーは HTTP 403 (Forbidden) ステータスコードで 応答するべきであり (SHOULD)、保護されたリソースへアクセスするために 必要なスコープを持つ scope 属性を含めてもよいです (MAY)。¶

拡張は、追加のエラーコードを定義したり、 上記のエラーコードが返される追加の状況を指定したりできます。¶

リクエストに認証情報がまったくない場合 （たとえば、クライアントが認証が必要であることを知らなかった、 またはサポートされていない認証方式を使用して試行した場合）、 リソースサーバーはエラーコードまたはその他のエラー情報を 含めるべきではありません (SHOULD NOT)。¶

例:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"

また、失効したアクセストークンを使用した認証試行を伴う 保護されたリソースリクエストへのレスポンスでは次のようになります:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
                  error="invalid_token",
                  error_description="The access token expired"

6.1.1. 登録済み アクセストークン種別

[RFC6750] は、 OAuth トークン認証スキーム間で共有されるエラー値のために、 [RFC6749] の Section 11.4 に共通レジストリを確立しています。¶

主に OAuth トークン認証のために設計された新しい認証スキームは、 エラー状態コードをクライアントに提供するためのメカニズムを 定義するべきであり (SHOULD)、そこで許可されるエラー値は この仕様によって確立されるエラーレジストリに登録されます。¶

そのようなスキームは、有効なエラーコードの集合を 登録値の部分集合に制限してもよいです (MAY)。エラーコードが名前付き パラメーターを使用して返される場合、パラメーター名は error であるべきです (SHOULD)。¶

OAuth トークン認証に使用できるものの、その目的を主として 設計されていないその他のスキームは、同じ方法でそのエラー値を レジストリに結び付けてもよいです (MAY)。¶

新しい認証スキームは、この仕様での使用法と並行する方法で エラー情報を返すために、error_description および error_uri パラメーターの使用も指定することを 選択してもよいです (MAY)。¶

種別名は type-name ABNF に適合しなければなりません (MUST)。 種別定義が新しい HTTP 認証スキームを含む場合、種別名は （[RFC2617] で定義される） HTTP 認証スキーム名と同一であるべきです (SHOULD)。 トークン種別 example は例での使用のために予約されています。¶

type-name  = 1*name-char
name-char  = "-" / "." / "_" / DIGIT / ALPHA

6.1.2. ベンダー固有アクセストークン種別

URI 名を利用する種別は、一般に適用可能ではなく、 使用されるリソースサーバーの実装詳細に固有の、 ベンダー固有実装に限定されるべきです (SHOULD)。¶

その他すべての種別は登録されなければなりません (MUST)。¶

7.1.1. セキュリティ脅威

次の一覧は、何らかの形式のトークンを利用するプロトコルに対する いくつかの一般的な脅威を示します。この脅威一覧は NIST Special Publication 800-63 [NIST800-63] に基づいています。¶

7.1.2. 脅威の軽減

デジタル署名を使用してアクセストークンの内容を保護し、 定期的な鍵ローテーションなど署名鍵管理のベストプラクティスに従うことで、 広範な脅威を軽減できます。¶

あるいは、bearer token は、認可情報を直接エンコードするのではなく、 認可情報への参照を含むことができます。参照を使用する場合、 その参照を認可情報に解決するために、リソースサーバーと認可サーバーとの間で 追加の相互作用が必要になる場合があります。そのような相互作用の仕組みは この仕様では定義されませんが、そのようなメカニズムの 1 つは Token Introspection [RFC7662] で定義されています。¶

この文書はアクセストークンのエンコーディングまたは内容を 指定しません。したがって、アクセストークンの完全性保護を保証する 手段に関する詳細な推奨事項は、この仕様の範囲外です。 アクセストークンのエンコードおよび署名メカニズムの一例は、 JSON Web Token Profile for Access Tokens [RFC9068] で説明されています。¶

アクセストークンリダイレクトに対処するには、 認可サーバーが、トークン内に意図された受信者（audience）の アイデンティティ、通常は単一のリソースサーバー（またはリソースサーバーの リスト）を含めることが重要です。トークンの使用を特定のスコープに 制限することも推奨されます (RECOMMENDED)。¶

Section 1.5 は、アクセストークンの開示から保護し、 クライアント、リソースサーバー、および認可サーバー間の通信に 機密性と完全性を提供するための情報を提供します。¶

7.1.3. 推奨事項の 要約

7.1.4. アクセストークンの 権限制限

アクセストークンに関連付けられる権限は、 特定のアプリケーションまたはユースケースに必要な最小限に 制限されるべきです (SHOULD)。これにより、クライアントがリソース所有者によって 認可された権限を超えることを防ぎます。また、ユーザーがそれぞれの セキュリティポリシーによって認可された権限を超えることも防ぎます。 権限制限は、アクセストークン漏えいの影響を減らす助けにもなります。¶

特に、アクセストークンは特定のリソースサーバー （audience 制限）、望ましくは単一のリソースサーバーに制限されるべきです (SHOULD)。 これを実現するために、認可サーバーはアクセストークンを特定の リソースサーバーと関連付け、各リソースサーバーは、すべてのリクエストについて、 そのリクエストとともに送信されたアクセストークンがその特定の リソースサーバーで使用されることを意図したものかどうかを検証する義務があります。 そうでない場合、リソースサーバーはそれぞれのリクエストへの応答を 拒否しなければなりません (MUST)。クライアントおよび認可サーバーは、 アクセスしたいリソースサーバーを決定するために、この文書および [RFC8707] でそれぞれ指定される scope または resource パラメーターを利用してもよいです (MAY)。¶

さらに、アクセストークンは、リソースサーバーまたはリソース上の 特定のリソースおよびアクションに制限されるべきです (SHOULD)。 これを実現するために、認可サーバーはアクセストークンをそれぞれの リソースおよびアクションと関連付け、各リソースサーバーは、 すべてのリクエストについて、そのリクエストとともに送信されたアクセストークンが その特定のリソースに対するその特定のアクションで使用されることを 意図したものかどうかを検証する義務があります。そうでない場合、 リソースサーバーはそれぞれのリクエストへの応答を拒否しなければなりません。 クライアントおよび認可サーバーは、それらのリソースおよび/またはアクションを 決定するために、[RFC9396] で指定される scope パラメーターおよび authorization_details を利用してもよいです (MAY)。¶

7.3.1. ネイティブアプリの なりすまし

上記のように、認可サーバーは、 クライアントのアイデンティティを保証できる場合を除き、 ユーザーの同意または相互作用なしに認可リクエストを自動的に処理する べきではありません (SHOULD NOT)。これには、ユーザーが以前に 特定のクライアント ID に対する認可リクエストを承認している場合も含まれます。 クライアントのアイデンティティを証明できない限り、そのリクエストは 以前のリクエストが承認されていなかったかのように処理されるべきです (SHOULD)。¶

claimed https スキームリダイレクトなどの措置は、 アイデンティティ証明として認可サーバーに受け入れられてもよいです (MAY)。 一部のオペレーティングシステムは、適切な場合に受け入れられてもよい 代替のプラットフォーム固有アイデンティティ機能を提供する場合があります (MAY)。¶

7.3.2. アクセストークンの 権限制限

クライアントは必要最小限のスコープでアクセストークンを 要求するべきです (SHOULD)。認可サーバーは、要求されたスコープを どのように認めるかを選択する際にクライアントアイデンティティを考慮するべきであり (SHOULD)、 要求されたものより少ないスコープでアクセストークンを発行してもよいです (MAY)。¶

アクセストークンに関連付けられる権限は、 特定のアプリケーションまたはユースケースに必要な最小限に 制限されるべきです (SHOULD)。これにより、クライアントがリソース所有者によって 認可された権限を超えることを防ぎます。また、ユーザーがそれぞれの セキュリティポリシーによって認可された権限を超えることも防ぎます。 権限制限は、アクセストークン漏えいの影響を減らす助けにもなります。¶

特に、アクセストークンは特定のリソースサーバー （audience 制限）、望ましくは単一のリソースサーバーに制限されるべきです (SHOULD)。 これを実現するために、認可サーバーはアクセストークンを特定の リソースサーバーと関連付け、各リソースサーバーは、すべてのリクエストについて、 そのリクエストとともに送信されたアクセストークンがその特定の リソースサーバーで使用されることを意図したものかどうかを検証する義務があります。 そうでない場合、リソースサーバーはそれぞれのリクエストへの応答を 拒否しなければなりません (MUST)。クライアントおよび認可サーバーは、 アクセスしたいリソースサーバーを決定するために、 [RFC8707] でそれぞれ指定される scope または resource パラメーターを利用してもよいです (MAY)。¶

7.5.1. 認可 コードインジェクション

認可コードインジェクションは、クライアントが正当な認可サーバーからの 認可コードではなく、攻撃者からの認可コードをその redirect URI で受け取る 攻撃です。保護策がない場合、クライアントは攻撃が発生したことを知るための メカニズムを持ちません。認可コードインジェクションは、攻撃者が被害者の アカウントへのアクセスを取得することと、被害者が誤って攻撃者の アカウントへアクセスしてしまうことの両方につながる可能性があります。¶

7.5.2. 認可コードの 再利用

認可コードが複数回使用できる場合、いくつかの種類の 攻撃が可能になります。¶

Section 4.1.3 で説明されるように、 認可サーバーは、すでにアクセストークンの発行に使用された認可コードを 使用した 2 回目の有効なリクエストを受信した場合、トークンリクエストを 拒否し、発行済みの任意のトークンを取り消さなければなりません。 攻撃者が認可コードを流出させ、正当なクライアントより先にそれを使用できる場合、 攻撃者はアクセストークンを取得し、正当なクライアントは取得できません。 発行済みの任意のトークンを取り消すことは、攻撃者のトークンも取り消されることを 意味し、攻撃がそれ以上進行することを止めます。¶

ただし、認可サーバーは、認可コードを含むリクエストも code_verifier やクライアント認証などのその他のパラメーターを含めて 有効である場合にのみ、発行済みトークンを取り消すべきです。 認可サーバーは、無効なパラメーターを含むリプレイされた認可コードを 受信した場合、発行済みトークンを取り消すべきではありません (SHOULD NOT)。 そうしてしまうと、認可コードを取得できるものの、クライアント認証または code_verifier を取得できない攻撃者が、正当なクライアントより先に 無効な認可コードリクエストを送信し、正当なクライアントが有効なリクエストを 行った時点でそのトークンを取り消すことによって、サービス拒否の機会を 作り出すことになります。¶

7.5.3. HTTP 307 リダイレクト

ユーザークレデンシャルを含む可能性のあるリクエストを リダイレクトする認可サーバーは、リダイレクトに 307 ステータスコード （[RFC9110] の Section 15.4.8）を使用してはなりません (MUST NOT)。 そのようなリクエストに HTTP リダイレクト（たとえば JavaScript ではなく）が 使用される場合、AS はステータスコード 303 ("See Other") を使用するべきです (SHOULD)。¶

認可エンドポイントでは、典型的なプロトコルフローとして、 AS がユーザーにフォームでクレデンシャルを入力するよう促し、そのフォームが （POST メソッドを使用して）認可サーバーへ送信されます。AS は クレデンシャルを確認し、成功した場合、ユーザーエージェントをクライアントの redirect URI へリダイレクトします。¶

ステータスコード 307 がリダイレクトに使用された場合、 ユーザーエージェントは POST リクエストを介してユーザークレデンシャルを クライアントへ送信します。¶

これにより、機密クレデンシャルがクライアントに開示されます。 クライアントが悪意ある場合、AS でユーザーになりすますために そのクレデンシャルを使用できます。¶

この挙動は開発者にとって予期しないものかもしれませんが、 [RFC9110] の Section 15.4.8 で定義されています。このステータスコードは、 ユーザーエージェントに POST リクエストを GET リクエストへ書き換え、 それによって POST リクエストコンテンツ内のフォームデータを破棄することを 要求しません。¶

HTTP [RFC9110] では、ステータスコード 303 のみが HTTP POST リクエストを HTTP GET リクエストへ書き換えることを明確に 強制します。一般的な 302 を含む他のすべてのステータスコードでは、 ユーザーエージェントは POST を GET リクエストへ書き換えないことを 選択でき、そのためユーザークレデンシャルをクライアントに開示する可能性があります。 （ただし実際には、ほとんどのユーザーエージェントは 307 リダイレクトでのみ この挙動を示します。）¶

7.12.1. Open Redirector としてのクライアント

クライアントは open redirector を公開してはなりません (MUST NOT)。 攻撃者は open redirector を使用してクライアントを指す URL を生成し、 [RFC9700] の Section 4.1.1 で説明されるように、 それらを利用して認可コードを流出させる可能性があります。 もう 1 つの悪用例は、クライアントを指しているように見える URL を 生成することです。これによりユーザーはその URL を信頼してブラウザで 開くよう騙される可能性があります。これはフィッシングに悪用できます。¶

オープンリダイレクトを防ぐために、クライアントは 対象 URL がホワイトリスト登録されている場合、またはリクエストの origin と 完全性を認証できる場合にのみリダイレクトするべきです。 オープンリダイレクトに対する対策は OWASP [owasp_redir] によって説明されています。¶

7.12.2. Open Redirector としての 認可サーバー

クライアントの場合と同様に、攻撃者は、フィッシング攻撃を 実行するために、ユーザーの認可サーバー（特にその URL）への信頼を 利用しようとする可能性があります。OAuth 認可サーバーは定期的に ユーザーを他の Web サイト（クライアント）へリダイレクトしますが、 それを安全に行わなければなりません。¶

Section 4.1.2.1 は、 client_id と redirect_uri の組み合わせが無効な場合に 認可サーバーがユーザーエージェントを自動的にリダイレクトしてはならない (MUST NOT) と述べることで、すでにオープンリダイレクトを防いでいます。¶

しかし、攻撃者は正しく登録された redirect URI を利用して フィッシング攻撃を行うこともできます。たとえば、攻撃者は dynamic client registration [RFC7591] を介してクライアントを登録し、 次のいずれかの攻撃を実行する可能性があります:¶

1. たとえば無効なスコープ値を使用するなどして、 意図的に誤った認可リクエストを送信し、認可サーバーに ユーザーエージェントをそのフィッシングサイトへリダイレクトするよう 指示する。¶

2. 攻撃者によって制御される client_id および redirect_uri を持つ有効な認可リクエストを 意図的に送信する。ユーザーが認証した後、認可サーバーはユーザーに リクエストへの同意を求めます。ユーザーがリクエストの問題に気付き、 リクエストを拒否した場合でも、認可サーバーはユーザーエージェントを フィッシングサイトへリダイレクトします。この場合、ユーザーエージェントは ユーザーが取った行動に関係なくフィッシングサイトへリダイレクトされます。¶

3. 攻撃者によって制御される client_id および redirect_uri を持つ有効なサイレント認証 リクエスト（prompt=none）を意図的に送信する。この場合、 認可サーバーはユーザーエージェントをフィッシングサイトへ 自動的にリダイレクトします。¶

認可サーバーはこれらの脅威を防ぐための予防措置を 講じなければなりません (MUST)。認可サーバーは常にまずユーザーを 認証しなければならず (MUST)、サイレント認証のユースケースを除いて、 ユーザーをリダイレクトする前に必要に応じてユーザーにクレデンシャルを 求めなければなりません。認可サーバーは、そのリスク評価に基づいて、 redirect URI を信頼できるかどうかを決定する必要があります。 URI の背後にあるコンテンツの信用性と信頼性、および redirect URI と その他のクライアントデータの出所を評価するために、内部的または 何らかの外部サービスを通じて行われる URI 分析を考慮することができます。¶

認可サーバーは、redirect URI を信頼する場合にのみ ユーザーエージェントを自動的にリダイレクトするべきです (SHOULD)。 URI が信頼されていない場合、認可サーバーはユーザーに通知し、 ユーザーが正しい判断を行うことに依存してもよいです (MAY)。¶

7.14.1. 発行者識別による Mix-Up 防御

この防御では、認可サーバーがその発行者識別子を 認可レスポンスでクライアントへ送信する必要があります。 認可レスポンスを受け取ると、クライアントは受け取った発行者識別子を 保存済みの発行者識別子と比較しなければなりません (MUST)。 不一致がある場合、クライアントは相互作用を中止しなければなりません (MUST)。¶

この発行者識別子をクライアントへ転送する方法は複数あります:¶

• 発行者情報は、たとえば任意のレスポンスパラメーター iss（Section 4.1.2 を参照）を介して転送できます。¶

• OpenID Connect が使用され、ID Token が 認可レスポンスで返される場合、クライアントは ID Token 内の iss Claim を評価できます。¶

どちらの場合も、iss 値は [RFC9207] に従って 評価されなければなりません (MUST)。¶

この防御は、発行者情報を転送するための追加パラメーターを 使用する必要がある場合がありますが、mix-up に対する堅牢で比較的単純な 防御です。¶

7.14.2. 個別の Redirect URI による Mix-Up 防御

この防御では、クライアントは相互作用する各発行者ごとに 個別の redirect URI を使用しなければなりません (MUST)。¶

クライアントは、発行者用の個別の redirect URI を、 認可レスポンスを受信した URI と比較することで、認可レスポンスが 正しい発行者から受信されたことを確認しなければなりません (MUST)。 不一致がある場合、クライアントはフローを中止しなければなりません (MUST)。¶

この防御は既存の OAuth 機能の上に構築されていますが、 クライアントが多くの異なる発行者の使用に対して一度だけ登録する シナリオ（いくつかのオープンバンキングスキームなど）では使用できず、 クライアント登録との密接な統合のため、自動的に配備することが より困難です。¶

さらに、攻撃者は、クライアントが攻撃者の AS に割り当てた redirect URI を使用して "honest" AS に新しいクライアントを登録することで、 この防御によって提供される保護を回避できる可能性があります。 攻撃者はその後、新しく作成したクライアントのクライアント ID に置き換えて、 上記の攻撃を実行できます。¶

したがって、この防御は他の選択肢が利用できない場合にのみ 使用されるべきです (SHOULD)。¶

8.1.1. ネイティブアプリクライアントの 登録

Dynamic Client Registration [RFC7591] のような メカニズムを使用してインスタンスごとのクレデンシャルをプロビジョニングする場合を除き、 ネイティブアプリは Section 2.1 で定義される public client として分類され、そのようなものとして認可サーバーへ 登録されなければなりません (MUST)。認可サーバーは、リクエストを 適切に識別して処理するために、クライアント登録詳細にクライアント種別を 記録しなければなりません (MUST)。¶

8.1.2. ネイティブアプリ アテステーション

ドラフト仕様 [I-D.ietf-oauth-attestation-based-client-auth] は、ネイティブアプリが認可サーバーまたはリソースサーバーへ 認証するための鍵結合アテステーションを取得するために使用できる メカニズムを定義しています。これは、モバイルアプリのアイデンティティについて、 より高い保証レベルを提供できます。¶

8.4.1. Claimed "https" スキーム URI リダイレクション

一部のオペレーティングシステム、特にモバイル オペレーティングシステムでは、アプリが自分たちの制御するドメイン内で https URI （Section 4.2.2 of [RFC9110] を参照） を claim できます。ブラウザが claimed URI に遭遇すると、 ページをブラウザで読み込む代わりに、ネイティブアプリが 起動され、その URI が起動パラメーターとして渡されます。¶

そのような URI は、ネイティブアプリによって redirect URI として 使用できます。それらは認可サーバーにとって、通常の Web ベース クライアントの redirect URI と区別できません。例を示します:¶

https://app.example.com/oauth2redirect/example-provider

redirect URI だけでは public native app client と confidential web client を区別するには不十分であるため、 Section 8.1.1 では、 サーバーがクライアント種別を判断し、それに応じて動作できるように、 クライアント登録時にクライアント種別を記録することが REQUIRED です。¶

App-claimed https スキーム redirect URI は、 他のネイティブアプリ用 redirect 選択肢と比べて、宛先アプリの アイデンティティがオペレーティングシステムによって認可サーバーへ 保証されるという利点があります。このため、ネイティブアプリは 可能な場合、他の選択肢よりもそれらを使用するべきです (SHOULD)。¶

8.4.2. ループバック インターフェイスリダイレクション

特別な権限なしにループバックネットワーク インターフェイス上でポートを開くことができるネイティブアプリ （通常はデスクトップオペレーティングシステム上のもの）は、 OAuth redirect を受信するためにループバックインターフェイスを 使用できます。¶

ループバック redirect URI は http スキームを使用し、 ループバック IP リテラルと、クライアントが待ち受けている任意のポートで 構築されます。¶

すなわち、IPv4 では http://127.0.0.1:{port}/{path}、 IPv6 では http://[::1]:{port}/{path} です。ランダムに割り当てられたポートを 使用した IPv4 ループバックインターフェイスによる redirect の例:¶

http://127.0.0.1:51004/oauth2redirect/example-provider

ランダムに割り当てられたポートを使用した IPv6 ループバックインターフェイスによる redirect の例:¶

http://[::1]:61023/oauth2redirect/example-provider

localhost という名前を使用する redirect URI （すなわち http://localhost:{port}/{path}）は、ループバック IP redirect と同様に機能しますが、localhost の使用は 推奨されません (NOT RECOMMENDED)。localhost ではなく ループバック IP リテラルを持つ redirect URI を指定することで、 誤ってループバックインターフェイス以外のネットワーク インターフェイスで待ち受けることを避けられます。また、ユーザーの デバイス上のクライアント側ファイアウォールや誤設定されたホスト名解決の 影響を受けにくくなります。¶

認可サーバーは、ループバック IP redirect URI について、 クライアントがリクエスト時にオペレーティングシステムから利用可能な 一時ポートを取得することに対応するため、リクエスト時に任意のポートが 指定されることを許可しなければなりません (MUST)。¶

クライアントは、デバイスが特定のバージョンの Internet Protocol をサポートしていると仮定するべきではありません (SHOULD NOT)。 クライアントは IPv4 と IPv6 の両方を使用してループバック インターフェイスへのバインドを試み、利用可能な方を使用することが 推奨されます (RECOMMENDED)。¶

8.4.3. Private-Use URI スキームリダイレクション

多くのモバイルおよびデスクトップコンピューティング プラットフォームは、アプリが com.example.app のような private-use URI スキーム（俗に "custom URL schemes" と呼ばれることもあります）を 登録できるようにすることで、URI を介したアプリ間通信をサポートしています。 ブラウザまたは別のアプリが private-use URI スキームを持つ URI を 読み込もうとすると、それを登録したアプリがリクエストを処理するために 起動されます。¶

private-use URI スキームをサポートする多くの環境では、 スキームを claim し、他の当事者が別のアプリケーションのスキームを 使用することを防ぐメカニズムが提供されていません。そのため、 private-use URI スキームを使用するクライアントは、自分たちの redirect URI に対する潜在的な攻撃に脆弱です。したがって、この選択肢は、 前述のより安全な選択肢が利用できない場合にのみ使用されるべきです。¶

private-use URI スキーム redirect を使用して認可リクエストを 実行するために、ネイティブアプリは標準的な認可リクエストを用いて ブラウザを起動します。ただし、その redirect URI は、オペレーティング システムに登録した private-use URI スキームを利用します。¶

アプリに関連付ける URI スキームを選択する際、アプリは、 private-use URI スキームについて Section 3.8 of [RFC7595] で 推奨されるように、自分たちの制御下にあるドメイン名に基づき、 逆順で表された URI スキームを使用しなければなりません (MUST)。¶

たとえば、ドメイン名 app.example.com を制御するアプリは、そのスキームとして com.example.app を 使用できます。一部の認可サーバーは、たとえば client1234.usercontent.example.net のように、ドメイン名に基づいて クライアント識別子を割り当てます。これは、同じ方法で逆順にした場合、 スキームのドメイン名としても使用できます。しかし、 myapp のようなスキームは、ドメイン名に基づいていないため、 この要件を満たしません。¶

同じ発行者による複数のアプリがある場合、 各スキームがそのグループ内で一意になるよう注意しなければなりません。 逆順ドメイン名に基づくアプリ識別子を使用するプラットフォームでは、 この問題を避けるために、それらの識別子を OAuth redirect 用の private-use URI スキームとして再利用できます。¶

Section 3.2 of [RFC3986] の 要件に従い、private-use URI スキーム redirect には命名機関がないため、 スキームコンポーネントの後には単一のスラッシュ（/）だけが 現れます。private-use URI スキームを利用する完全な redirect URI の例は 次のとおりです:¶

com.example.app:/oauth2redirect/example-provider

認可サーバーがリクエストを完了すると、通常どおり クライアントの redirect URI へリダイレクトします。 redirect URI は private-use URI スキームを使用しているため、 その結果、オペレーティングシステムがネイティブアプリを起動し、 URI を起動パラメーターとして渡します。その後、ネイティブアプリは 認可レスポンスの通常の処理を使用します。¶

8.5.1. ネイティブアプリにおける 埋め込みユーザーエージェント

埋め込みユーザーエージェントは、ネイティブアプリを 認可するための技術的には可能な方法です。これらの埋め込みユーザー エージェントは、認可サーバーに対する第三者による使用には、 定義上安全ではありません。埋め込みユーザーエージェントをホストする アプリは、そのアプリのために意図された OAuth 認可グラントだけでなく、 ユーザーの完全な認証クレデンシャルにアクセスできるためです。 また通常、オペレーティングシステムによってサンドボックス化されており、 Web origin に依存する WebAuthn などのメカニズムは無効化されます。¶

Web ビューに基づく埋め込みユーザーエージェントの典型的な実装では、 ホストアプリケーションはログインフォームに入力されたすべてのキー入力を 記録してユーザー名とパスワードを取得し、ユーザー同意を回避するために フォームを自動送信し、セッション Cookie をコピーしてユーザーとして 認証済みアクションを実行できます。¶

認可サーバーと同じ当事者に属する信頼されたアプリで 使用される場合であっても、埋め込みユーザーエージェントは、 必要以上に強力なクレデンシャルへアクセスできるため、最小権限の原則に 違反し、攻撃面を増加させる可能性があります。¶

ブラウザが持つ通常のアドレスバーや可視の証明書検証機能なしに、 埋め込みユーザーエージェントでユーザーにクレデンシャルを入力するよう 促すことは、ユーザーが正当なサイトにサインインしているかどうかを 知ることを不可能にします。たとえ正当なサイトであっても、サイトを 先に検証せずにクレデンシャルを入力してもよいという行動を ユーザーに学習させてしまいます。¶

セキュリティ上の懸念に加えて、埋め込みユーザーエージェントは 認証状態を他のアプリやブラウザと共有しないため、ユーザーは各 認可リクエストごとにログインする必要があり、これはしばしば劣った ユーザー体験と見なされます。¶

8.5.2. ネイティブアプリにおける 偽の外部ユーザーエージェント

認可リクエストを開始しているネイティブアプリは、 ユーザーインターフェイスに対して大きな制御権を持っており、 偽の外部ユーザーエージェント、すなわち外部ユーザーエージェントに 見えるよう作られた埋め込みユーザーエージェントを提示できる可能性があります。¶

すべての善意のアクターが外部ユーザーエージェントを 使用している場合の利点は、セキュリティ専門家が悪意あるアクターを 検出できることです。外部ユーザーエージェントを偽装している者は、 証明可能に悪意があるためです。一方、善意のアクターも悪意あるアクターも 同様に埋め込みユーザーエージェントを使用している場合、悪意あるアクターは 何も偽装する必要がなくなり、検出が困難になります。 悪意あるアプリが検出された後は、この知識を用いてマルウェアスキャン ソフトウェアでアプリの署名をブラックリスト登録し、（アプリストアで 配布されているアプリの場合は）削除措置を講じ、悪意あるアプリの影響と 拡散を減らすためのその他の手段を取ることが可能な場合があります。¶

認可サーバーは、真の外部ユーザーエージェントでのみ 利用可能な認証要素を要求することにより、偽の外部ユーザーエージェントに 直接対抗することもできます。¶

in-app browser tabs を使用する際にセキュリティを特に懸念する ユーザーは、追加の手段として、in-app browser tab からフルブラウザで リクエストを開き、そこで認可を完了することもできます。 in-app browser tab パターンのほとんどの実装は、そのような機能を 提供しているためです。¶

8.5.3. ネイティブアプリにおける 悪意ある外部ユーザーエージェント

悪意あるアプリがオペレーティングシステム内で https スキーム URI のデフォルトハンドラーとして 自分自身を設定できる場合、デフォルトブラウザを使用する認可リクエストを 傍受し、この信頼された位置をフィッシングなどの悪意ある目的に 悪用できます。¶

この攻撃は OAuth に限定されません。このように設定された 悪意あるアプリは、ネイティブアプリによる OAuth 使用を超えて、 ユーザーに対する一般的かつ継続的なリスクをもたらします。 多くのオペレーティングシステムは、http および https スキーム URI のデフォルトハンドラーを変更するために、明示的な ユーザー操作を要求することで、この問題を軽減しています。¶

8.5.4. ネイティブアプリにおける ループバック redirect の考慮事項

ループバックインターフェイス redirect URI は http スキーム（すなわち TLS なし）を使用してもよいです (MAY)。 HTTP リクエストがデバイスから出ないため、これはループバック インターフェイス redirect URI では許容されます。¶

クライアントは、認可リクエストを開始するときだけ ネットワークポートを開き、レスポンスが返されたらそれを閉じるべきです (SHOULD)。¶

クライアントは、他のネットワークアクターによる干渉を 避けるため、ループバックネットワークインターフェイスのみで 待ち受けるべきです (SHOULD)。¶

クライアントは、Section 8.4.2 で説明されるように、 文字列 localhost ではなくループバック IP リテラルを 使用するべきです (SHOULD)。¶