OAuth 2.1 認可フレームワーク

1.3.1. 認可コード

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

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

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

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

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

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

+--------+                                           +---------------+
|        |--(1)-------- 認可グラント --------------->|               |
|        |                                           |               |
|        |<-(2)-------- アクセストークン -------------|               |
|        |               & リフレッシュトークン       |               |
|        |                                           |               |
|        |                            +----------+   |               |
|        |--(3)--- アクセストークン -->|          |   |               |
|        |                            |          |   |               |
|        |<-(4)--- 保護リソース -------| リソース |   |     認可      |
|クライアント|                         | サーバー  |   |    サーバー    |
|        |--(5)--- アクセストークン -->|          |   |               |
|        |                            |          |   |               |
|        |<-(6)-- 無効トークンエラー --|          |   |               |
|        |                            +----------+   |               |
|        |                                           |               |
|        |--(7)----- リフレッシュトークン ----------->|               |
|        |                                           |               |
|        |<-(8)-------- アクセストークン -------------|               |
+--------+        & 任意のリフレッシュトークン        +---------------+

図 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. アクセストークンのスコープ

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

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

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

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

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

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

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

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

1.4.2. Bearer トークン

Bearer トークンは、そのトークンを所持する任意の主体 （「bearer」）が、他の任意の所持者と同じ方法で そのトークンを使用できるという特性を持つセキュリティトークンです。 Bearer トークンを使用する際、bearer が暗号鍵素材の所持を 証明する必要はありません（proof-of-possession）。¶

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

アクセストークンの漏えいを防ぐため、 クライアントとリソースサーバーの間の通信は、 1.5節 で説明されている 機密性および完全性の保護を使用しなければなりません。¶

Bearer トークンの特定の構造や形式に関する要件はありません。 Bearer トークンが認可情報への参照である場合、そのような参照は、 十分に長い暗号学的にランダムな文字列を使用するなど、攻撃者が推測することが 実行不可能でなければなりません。Bearer トークンが 認可情報をトークン自体に格納するエンコードメカニズムを使用する場合、 アクセストークンはトークンの変更を防止するのに十分な 完全性保護を使用しなければなりません。アクセストークンのエンコードおよび 署名メカニズムの一例は 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] など、 アクセストークンを送信者に制約するメカニズムを使用すべきです。 盗まれたまたは漏えいしたアクセストークンの悪用を防ぐため、 4.10.1節 of [RFC9700] を参照してください。¶

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

1.7.1. 値のサイズ

この仕様では、 client_id、認可コード、アクセストークン、リフレッシュトークン、 その他ほとんどのプロトコルパラメーターの最大長を定義していません。これらの値の長さは、 それらを発行する主体が選択する実装方法に依存するためです。 実際には、実装は独自の制限を設けており、 受信側実装の制限を超える値があると リクエストは失敗します。¶

実装は、受信した値が特定の長さに 収まると想定してはなりません。値を発行する主体は、その長さを 文書化し、それを運ぶ構成要素の制限を 考慮すべきです。特に、認可コードなど リダイレクトで返される値は URI クエリ文字列で運ばれ、 HTTP 実装では一般にリクエスト行および 個々のヘッダーフィールドの長さが制限されます（3節 of [RFC9112] および 5.4節 of [RFC9110]）。 実装は、リクエストが 3節 of [RFC9112] で推奨される 8000オクテットのリクエスト行長以内に収まるのに十分な長さの パラメーター値をサポートすべきです。特にリソース サーバーは、アクセストークンの長さに小さな制限を設けるべきではありません。 [RFC9068] で定義されているような 構造化形式のトークンは、通常1キロバイトを超えるためです。¶

2.3.1. 登録 要件

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

認可サーバーは、クライアントが複数の リダイレクト URI を登録することを許可してもかまいません。¶

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

私的利用 URI スキームに基づくリダイレクト URI の場合、 認可サーバーは、 クライアントが逆ドメイン名ベースのスキームを使用するという 8.4.3節 の要件を適用すべきです。 少なくとも、ピリオド文字（.）を含まない 私的利用 URI スキームは拒否すべきです。¶

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

クライアントは、7.13節 で説明されているような、 クエリパラメーターから取得した任意の URI へユーザーのブラウザを転送する URL （「オープンリダイレクター」）を公開してはなりません。 オープンリダイレクターは、認可コードやアクセストークンの 外部流出を可能にする可能性があります。¶

必要な場合、クライアントはリクエストごとにリダイレクト URI を 変える代わりに、state リクエストパラメーターを使用して リクエストごとのカスタマイズを実現してもかまいません。¶

リダイレクト URI の登録を必須にしない場合、 攻撃者は 7.13節 で説明されているように、認可エンドポイントをオープンリダイレクターとして 使用できます。¶

2.3.2. 複数のリダイレクト URI

クライアントに複数のリダイレクト URI が登録されている場合、 クライアントは認可リクエストに redirect_uri リクエストパラメーター （4.1.1節）を使用してリダイレクト URI を 含めなければなりません。 クライアントに登録されているリダイレクト URI が1つだけの場合、 redirect_uri リクエストパラメーターは任意です。¶

2.3.3. CSRF 攻撃の防止

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

2.3.4. Mix-Up 攻撃の防止

OAuth クライアントが1つの認可 サーバーとのみ対話できる場合、Mix-Up 防御は不要です。一方、 OAuth クライアントが2つ以上の認可サーバーと対話する場合、 クライアントは Mix-Up 攻撃を防止しなければなりません。 Mix-Up 攻撃を防止するため、クライアントは、それぞれのリクエストを送信した 発行者からのリダイレクトレスポンスのみを、かつその認可リクエストを開始した 同じユーザーエージェントからのものとして処理しなければなりません。¶

Mix-Up 攻撃に対する2つの異なる防御の詳細な説明については 7.15節 を参照してください。¶

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

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

2.3.6. エンドポイントのコンテンツ

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

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

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

クライアントシークレットを保持する confidential クライアントを サポートするため、認可サーバーは、クライアントが 次のパラメーターを使用してリクエスト本文のコンテンツに クライアントクレデンシャルを含めることをサポートしなければなりません。¶

"client_id":

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

"client_secret":

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

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

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

たとえば、コンテンツパラメーターを使用して アクセストークンを更新するリクエスト（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 認証スキームをサポートしてもかまいません。¶

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

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

たとえば、次のようになります（表示目的のみで追加の改行を含みます）。¶

Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

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

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

2.4.2. その他の 認証方式

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

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

3.2.1. クライアント 認証

confidential クライアントは、トークンエンドポイントへ リクエストするとき、 2.4節 で説明されているように、 認可サーバーで認証しなければなりません。¶

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

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

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

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

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

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

"grant_type":

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

"client_id":

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

confidential クライアントは、3.2.1節 で説明されているように、 認可サーバーで認証しなければなりません。¶

たとえば、クライアントは次の 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

認可サーバーは次を行わなければなりません。¶

• confidential クライアント （またはその他の認証要件を持つクライアント）に クライアント認証を要求する。¶

• クライアント認証が含まれている場合は クライアントを認証する。¶

さらにグラントタイプ固有の処理規則が適用され、 各グラントタイプとともに規定されています。¶

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

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

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

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

"access_token":

必須。認可サーバーが発行したアクセストークン。¶

"token_type":

必須。1.4節 で説明されている 発行されたアクセストークンのタイプです。値は 大文字と小文字を区別しません。¶

"expires_in":

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

"scope":

クライアントが要求したスコープと同一の場合は推奨。 それ以外の場合は必須。1.4.1節 で説明されているアクセストークンのスコープ。¶

"refresh_token":

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

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

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

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

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

たとえば次のようになります。¶

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"
}

クライアントは、レスポンス内の認識できない値の名前を 無視しなければなりません。認可 サーバーから受信するトークンおよびその他の値の長さは、 1.7.1節 で説明されているように未定義です。¶

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

認可サーバーは、特に指定がない限り、 HTTP 400 (Bad Request) ステータスコードで応答し、 レスポンスに次のパラメーターを含めます。¶

"error":

必須。次の中から選ばれる単一の ASCII [USASCII] エラーコード。¶

"invalid_request":

リクエストに必要なパラメーターが欠けている、 サポートされていないパラメーター値 （グラントタイプを除く）を含んでいる、 パラメーターが重複している、複数のクレデンシャルを含んでいる、 クライアントを認証するために複数のメカニズムを使用している、 認可リクエストで code_challenge が送信されていないにもかかわらず code_verifier を含んでいる、 またはその他の理由で不正な形式です。¶

"invalid_client":

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

"invalid_grant":

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

"unauthorized_client":

認証されたクライアントには、 この認可グラントタイプを使用する権限がありません。¶

"unsupported_grant_type":

認可グラントタイプが 認可サーバーでサポートされていません。¶

"invalid_scope":

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

error パラメーターの値には、 集合 %x20-21 / %x23-5B / %x5D-7E の外側の文字を 含めてはなりません。¶

"error_description":

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

"error_uri":

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

パラメーターは、付録 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」を導出します。クライアントは トークンエンドポイントで認可コードを交換するときにコードベリファイアを使用し、 認可コードを使用しているクライアントが、その認可コードを要求した 同じクライアントであることを証明します。¶

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

"response_type":

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

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

一部の拡張レスポンスタイプは [OpenID.Connect] で定義されています。¶

認可リクエストに response_type パラメーターがない場合、 またはレスポンスタイプを理解できない場合、認可サーバーは 4.1.2.1節 で説明されているエラーレスポンスを返さなければなりません。¶

"client_id":

必須。2.2節 で説明されているクライアント識別子。¶

"code_challenge":

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

"code_challenge_method":

必須。値 S256、または将来の拡張で定義される値。¶

"redirect_uri":

このクライアントに登録されているリダイレクト URI が1つだけの場合は 任意。 このクライアントに複数のリダイレクト URI が登録されている場合は必須。 2.3.2節 を参照してください。¶

"scope":

任意。1.4.1節 で説明されている アクセス要求のスコープ。¶

"state":

任意。リクエストとコールバックの間で 状態を維持するためにクライアントが使用する不透明な値。 認可サーバーは、ユーザーエージェントをクライアントへ リダイレクトして戻す際にこの値を含めます。この値は 認可リクエスト URI のクエリコンポーネントで運ばれ、 クライアントへのリダイレクトでも再び運ばれるため、実際の長さは 認可サーバー、ユーザーエージェント、およびクライアントが受け入れる URI と HTTP ヘッダーフィールドの長さによって制限されます。 1.7.1節 を参照してください。¶

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 を公開しないコードチャレンジ方式を使用しなければなりません。 そうしない場合、認可リクエストを読み取れる攻撃者 （[RFC9700] の攻撃者 A4 を参照）は、 このメカニズムによって提供されるセキュリティを 破ることができます。現在、S256 がそのような唯一の方式です。¶

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

次にクライアントは、有効な変換方式でコードベリファイアを 変換することにより、コードベリファイアから導出した code_challenge を作成します。¶

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

この仕様で定義する変換は S256 のみです。将来の拡張で 追加の変換方式が定義される場合があります。¶

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 拡張から 採用されています。[RFC7636] で定義された plain 変換方式は、 この仕様では削除され、明示的に禁止されています。詳細については 7.5.2節 を参照してください。¶

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

クライアントは code_challenge および code_verifier を使用しなければならず、 認可サーバーは 7.5.1節 で説明されている条件を除き、それらの使用を強制しなければなりません。 この場合でも、上記のとおり code_challenge と code_verifier を使用し、その使用を強制することが 引き続き推奨されます。¶

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

クライアントは 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 が存在する場合、それがクライアント登録 （2節） で事前に確立された登録済みリダイレクト URI のいずれかと一致することを確認して、 検証しなければなりません。 2つの URI を比較する際、認可サーバーは それらが等しいことを確認しなければなりません。詳細については 6.2.1節 of [RFC3986] の単純文字列比較を参照してください。 唯一の例外は localhost URI を使用するネイティブアプリです。この場合、認可 サーバーは 8.4.2節 で説明されているように、可変ポート番号を許可しなければなりません。¶

リクエストが有効である場合、 認可サーバーはリソース所有者を認証し、 認可の決定を取得します（リソース所有者に尋ねるか、 その他の手段で承認を確立します）。¶

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

4.1.2. 認可 レスポンス

リソース所有者がアクセス要求を許可した場合、認可 サーバーは認可コードを発行し、拡張によって別途規定されていない限り、 付録 C.1 で説明されているクエリ文字列シリアル化を使用して、 リダイレクト URI のクエリコンポーネントに次のパラメーターを 追加することによりクライアントへ届けます。¶

"code":

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

"state":

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

"iss":

必須。認可サーバーの発行者識別子。 クライアントが複数の認可サーバーと対話する場合、 Mix-Up 攻撃を防止するために使用できます。 クライアントが Mix-Up 攻撃を防止するためにこれを使用する方法の 詳細については 7.15節 および [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

クライアントは、認識できないレスポンスパラメーターを無視しなければなりません。 認可コード文字列の長さは、 1.7.1節 で説明されているように、この仕様では未定義です。¶

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

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

クライアントは、攻撃者による認可コードの 認可レスポンスへのインジェクション（リプレイ）を防止しなければなりません。 code_challenge および code_verifier を使用すると、認可サーバーが一致しない code_verifier を持つトークンリクエストを拒否するため、 認可コードのインジェクションを防止できます。詳細については 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. トークンエンドポイント 拡張

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

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

"code":

必須。認可サーバーから受信した 認可コード。¶

"code_verifier":

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

"client_id":

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

認可サーバーは、特定の認可コードについて アクセストークンを1回だけ返さなければなりません。¶

以前に成功したトークンリクエストと同じ 認可コードを使用して2回目の有効なトークンリクエストが行われた場合、 認可サーバーはそのリクエストを拒否し、可能であれば、 その認可コードに基づいて以前に発行されたすべてのアクセストークンと リフレッシュトークンを取り消すべきです。 詳細については 7.5.3節 を参照してください。¶

たとえば、クライアントは次の 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

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

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

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

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

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

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

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

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

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

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

"scope":

任意。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

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

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

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

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

"refresh_token":

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

"scope":

任意。1.4.1節 で説明されている アクセス要求のスコープ。要求するスコープには、 リソース所有者が元々付与していないスコープを 含めてはならず、省略した場合は リソース所有者が元々付与したスコープと同一として扱われます。¶

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

たとえば、クライアントはトランスポート層セキュリティを使用して 次の 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

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

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

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

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

認可サーバーは、public クライアントについて、 悪意ある主体によるリフレッシュトークンのリプレイを検出するため、 次のいずれかの方式を使用しなければなりません。¶

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

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

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

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

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

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

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

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

認可サーバーは、次のような セキュリティイベントが発生した場合に、リフレッシュトークンを自動的に取り消してもかまいません。¶

• パスワードの変更¶

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

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

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 ヘッダーフィールドの構文は、 2節 of [RFC2617] で定義されている Basic スキームの使用法に従います。 Basic と同様に、これは 1.2節 of [RFC2617] で定義されている 一般構文には準拠しませんが、HTTP 1.1 Authentication [RFC7235] の一般的な認証フレームワークとは 互換性があることに注意してください。ただし、既存のデプロイメントを反映するため、 そこで示されている推奨プラクティスには従いません。 Bearer クレデンシャルの構文は次のとおりです。¶

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

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

11.1節 of [RFC9110] で説明されているように、 文字列 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 パラメーターを使用して リクエストコンテンツにアクセストークンを追加します。 次のすべての条件を満たさない限り、クライアントはこの方法を使用してはなりません。¶

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

• コンテンツが、URL 現行標準 [WHATWG.URL] で定義されている application/x-www-form-urlencoded コンテンツタイプの エンコード要件に従っている。¶

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

• リクエストでエンコードされるコンテンツが すべて ASCII [USASCII] 文字で構成されている。¶

• HTTP リクエストメソッドが、コンテンツについて 定義された意味論を持つメソッドである。特に、これは GET メソッドを使用してはならないことを意味します。¶

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

たとえば、クライアントはトランスポート層セキュリティを使用して 次の 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 リクエストヘッダーフィールドへ アクセスできないアプリケーションコンテキストを除き、 使用すべきではありません。リソースサーバーはこの方法をサポートしてもかまいません。¶

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

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

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

"realm":

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

"scope":

scope 属性は 1.4.1節 で定義されています。 scope 属性は、要求されたリソースへアクセスするために アクセストークンに必要なスコープを示す、大文字と小文字を区別する スコープ値の空白区切りリストです。scope 値は実装によって 定義され、中央集約されたレジストリはありません。許可される値は 認可サーバーによって定義されます。scope 値の順序は 重要ではありません。場合によっては、保護されたリソースを 利用するのに十分なアクセススコープを持つ新しいアクセストークンを 要求するときに scope 値が使用されます。 scope 属性の使用は任意です。 scope 属性は複数回出現してはなりません。 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 属性を含めるべきです。パラメーター値は 5.3.2節 で説明されています。¶

"error_description":

リソースサーバーは、 エンドユーザーに表示することを意図しない、人間が読める 開発者向けの説明を提供するために error_description 属性を含めてもかまいません。¶

"error_uri":

リソースサーバーは、 エラーを説明する人間が読める Web ページを識別する 絶対 URI を持つ error_uri 属性を 含めてもかまいません。¶

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

scope 属性 （付録 A.4 で規定） の値には、スコープ値を表すための集合 %x21 / %x23-5B / %x5D-7E およびスコープ値間の区切り文字としての %x20 の外側の文字を 含めてはなりません。error および error_description 属性 （付録 A.7 および 付録 A.8 で規定）の値には、 集合 %x20-21 / %x23-5B / %x5D-7E の外側の文字を含めてはなりません。 error_uri 属性 （付録 A.9 で規定） の値は URI-reference 構文に準拠しなければならず、したがって 集合 %x21 / %x23-5B / %x5D-7E の外側の文字を含めてはなりません。¶

5.3.2. エラーコード

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

"invalid_request":

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

"invalid_token":

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

"insufficient_scope":

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

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

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

たとえば次のようになります。¶

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 トークン認証スキーム間で共有されるエラー値のための 共通レジストリを 11.4節 of [RFC6749] で確立しています。¶

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

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

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

新しい認証スキームは、この仕様での使用法と同様の方法で エラー情報を返すために、 error_description および error_uri パラメーターの使用も 規定することを選択してもかまいません。¶

タイプ名は type-name ABNF に準拠しなければなりません。タイプ定義に新しい HTTP 認証スキームが含まれる場合、タイプ名は HTTP 認証スキーム名（[RFC2617] で定義）と同一にすべきです。 トークンタイプ example は、例で使用するために予約されています。¶

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

6.1.2. ベンダー固有のアクセストークンタイプ

URI 名を利用するタイプは、一般的には適用できず、 使用されるリソースサーバーの実装詳細に 固有である、ベンダー固有の実装に限定すべきです。¶

その他のすべてのタイプは登録しなければなりません。¶

7.1.1. セキュリティ上の脅威

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

7.1.2. 脅威の緩和

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

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

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

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

1.5節 では、 アクセストークンの漏えいを防止し、 クライアント、リソースサーバー、および認可サーバー間の通信に 機密性と完全性を提供するための情報を示しています。¶

7.1.3. 推奨事項の 要約

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

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

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

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

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

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

宣言済み https スキームリダイレクトなどの措置を、 認可サーバーが身元証明として受け入れてもかまいません。 一部のオペレーティングシステムは、必要に応じて受け入れることのできる 代替のプラットフォーム固有の身元確認機能を提供する場合があります。¶

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

クライアントは、必要最小限のスコープを持つアクセストークンを 要求すべきです。認可サーバーは、要求されたスコープをどのように 承認するかを決定する際にクライアントの身元を考慮すべきであり、 要求されたものより少ないスコープを持つアクセストークンを 発行してもかまいません。¶

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

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

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

認可コードインジェクションとは、クライアントが 正当な認可サーバーからの認可コードではなく、攻撃者からの認可コードを 自身のリダイレクト URI で受信する攻撃です。保護措置がなければ、 クライアントには攻撃が発生したことを知る手段がありません。 認可コードインジェクションにより、攻撃者が被害者のアカウントへの アクセスを取得する場合もあれば、被害者が誤って攻撃者のアカウントへの アクセスを取得する場合もあります。¶

7.5.2. PKCE "plain" コードチャレンジ方式

[RFC7636] で定義されている plain コードチャレンジ方式は、OAuth 2.1 では明示的に禁止されています。 plain 方式は、コードベリファイアが認可リクエスト内で 平文で送信されるため、認可リクエストを読み取れる攻撃者 （[RFC9700] の攻撃者 A4） による認可コードの傍受に対して何の保護も提供しません。¶

plain モードをサポートする歴史的な根拠 （暗号学的ハッシュ機能を持たないデバイス）は、 証明書検証のために SHA-256 のサポートを要求する OAuth 2.1 の TLS 1.2+ 要件によって陳腐化しています。 OAuth 2.1 を実装できるデバイスは必然的に SHA-256 をサポートします。¶

plain コードチャレンジ方式をサポートする認可サーバーは、 検証不可能なダウングレード攻撃ベクトルを生み出します。これは、サーバーが 正当な制約付きクライアントと、制約付きであると主張する 攻撃者によって改変されたリクエストを区別できないためです。¶

S256 をサポートできない既存クライアントを持つデプロイメントは、 レガシーな認可方式のサポートを終了する前に、 有効期間を延長したリフレッシュトークンを発行すべきです。 リフレッシュトークングラント（4.3節）は PKCE を必要としないためです。¶

7.5.3. 認可コードの 再利用

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

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

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

7.5.4. HTTP 307 リダイレクト

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

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

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

これにより、機密性の高いクレデンシャルがクライアントへ漏えいします。 クライアントが悪意あるものであれば、そのクレデンシャルを使用して AS でユーザーになりすますことができます。¶

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

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

7.13.1. オープン リダイレクターとしてのクライアント

クライアントはオープンリダイレクターを公開してはなりません。 攻撃者はオープンリダイレクターを使用してクライアントを指す URL を作成し、 4.1.1節 of [RFC9700] で説明されているように、それを利用して認可コードを 流出させる可能性があります。 別の悪用例として、クライアントを指しているように見える URL を作成できます。 これにより、ユーザーがその URL を信頼してブラウザでアクセスするよう 騙される可能性があります。これはフィッシングに悪用できます。¶

オープンリダイレクトを防止するため、クライアントは、 対象 URL が許可リストに含まれている場合、またはリクエストの オリジンと完全性を認証できる場合にのみリダイレクトすべきです。 オープンリダイレクトへの対策は OWASP [owasp_redir] で説明されています。¶

7.13.2. オープンリダイレクターとしての 認可サーバー

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

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

ただし、攻撃者は正しく登録された リダイレクト URI を使用してフィッシング攻撃を実行することもできます。 たとえば、攻撃者は動的クライアント登録 [RFC7591] を介してクライアントを登録し、 次のいずれかの攻撃を実行できます。¶

1. たとえば無効なスコープ値を使用することで、 意図的に誤った認可リクエストを送信し、認可サーバーに ユーザーエージェントを自身のフィッシングサイトへリダイレクトさせます。¶

2. 攻撃者が制御する client_id と redirect_uri を使用して、 意図的に有効な認可リクエストを送信します。ユーザーが認証した後、 認可サーバーはユーザーにリクエストへの同意を求めます。 ユーザーがリクエストの問題に気付いて拒否した場合でも、認可 サーバーはユーザーエージェントをフィッシングサイトへリダイレクトします。 この場合、ユーザーが取った操作にかかわらず、 ユーザーエージェントはフィッシングサイトへリダイレクトされます。¶

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

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

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

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

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

この発行者識別子をクライアントへ伝達する方法には いくつかあります。¶

• 発行者情報はレスポンスパラメーター iss を介して伝達されます （4.1.2節 を参照）。¶

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

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

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

7.15.2. 異なるリダイレクト URI による Mix-Up 防御

この防御では、クライアントは対話する発行者ごとに 異なるリダイレクト URI を使用しなければなりません。¶

クライアントは、発行者用の固有のリダイレクト URI と 認可レスポンスを受信した URI を比較することにより、 認可レスポンスが正しい発行者から受信されたことを 確認しなければなりません。一致しない場合、クライアントは フローを中止しなければなりません。¶

この防御は既存の OAuth 機能を利用しますが、 クライアントが多数の異なる発行者を使用するために1回だけ登録する シナリオ（一部のオープンバンキング方式など）では使用できません。 また、クライアント登録と密接に統合されているため、 自動的にデプロイすることがより困難です。¶

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

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

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

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

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

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

8.4.1. 宣言された "https" スキーム URI リダイレクト

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

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

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

リダイレクト URI だけでは public なネイティブ アプリクライアントと confidential Web クライアントを区別するのに十分ではないため、 8.1.1節 では、 サーバーがクライアントタイプを判断して 適切に処理できるよう、クライアント登録時に クライアントタイプを記録することが必須とされています。¶

アプリが宣言した https スキームのリダイレクト URI は、 宛先アプリの身元がオペレーティングシステムによって 認可サーバーに保証されるという点で、 その他のネイティブアプリのリダイレクト方式より利点があります。 このため、可能な場合、ネイティブアプリは他の選択肢より この方式を使用すべきです。¶

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

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

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

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

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

ランダムに割り当てられたポートを使用する IPv6 ループバックインターフェイスのリダイレクト例を次に示します。¶

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

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

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

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

8.4.3. 私的利用 URI スキームリダイレクト

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

私的利用 URI スキームをサポートする多くの環境では、 あるスキームを占有し、他の主体が別のアプリケーションの スキームを使用することを防止するメカニズムがありません。 そのため、私的利用 URI スキームを使用するクライアントは、 リダイレクト URI に対する潜在的な攻撃の影響を受けます。 したがって、この選択肢は、前述したより安全な選択肢が 利用できない場合にのみ使用すべきです。¶

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

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

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

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

3.2節 of [RFC3986] の要件に従うと、私的利用 URI スキームリダイレクトには 命名機関が存在しないため、スキームコンポーネントの後には 単一のスラッシュ（/）だけが現れます。 私的利用 URI スキームを利用する完全なリダイレクト URI の例は次のとおりです。¶

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

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

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

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

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

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

通常のアドレスバーやブラウザが備える可視の証明書検証機能がない 埋め込みユーザーエージェントにユーザーがクレデンシャルを入力することを 奨励すると、ユーザーは正当なサイトにサインインしているかどうかを 判断できなくなります。実際に正当なサイトであったとしても、 サイトを事前に検証せずにクレデンシャルを入力してよいという習慣を ユーザーに身に付けさせてしまいます。¶

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

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

認可リクエストを開始するネイティブアプリは、 ユーザーインターフェイスを大きく制御できるため、 偽の外部ユーザーエージェント、すなわち 外部ユーザーエージェントのように見せかけた埋め込みユーザーエージェントを 提示できる可能性があります。¶

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

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

アプリ内ブラウザタブを使用する際のセキュリティを 特に懸念するユーザーは、追加の措置として、 アプリ内ブラウザタブからリクエストを完全なブラウザで開き、 そこで認可を完了することもできます。 アプリ内ブラウザタブパターンのほとんどの実装は、 このような機能を提供しています。¶

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

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

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

8.5.4. ネイティブアプリでのループバック リダイレクトに関する考慮事項

ループバックインターフェイスのリダイレクト URI は http スキーム（すなわち TLS なし）を 使用してもかまいません。HTTP リクエストがデバイスの外へ 出ることがないため、ループバックインターフェイスの リダイレクト URI ではこれは許容されます。¶

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

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

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