6.1.2.1. セッションおよび OAuth エンドポイント

BFF は、ブラウザベースアプリケーションと BFF の間の やり取りを実装するうえで重要な一連のエンドポイントを提供します。 このセクションでは、その目的と ユースケースを明確にするため、これらのエンドポイントについて詳しく説明します。¶

「セッション確認」エンドポイント (図1の (B) および (I)) は、 ブラウザベースアプリケーションが呼び出す API エンドポイントです。利用可能な場合、リクエストには セッション情報が含まれ、BFF が有効な セッションを確認できるようになります。レスポンスは、セッションが有効かどうかを ブラウザベースアプリケーションに示す必要があります。さらに BFF は、 認証済みユーザーの識別情報など、ほかの情報を含めることができます。¶

認可コードフローを開始するエンドポイント (C) には、ブラウザのナビゲーションによってアクセスします。アプリケーションは、 セッション確認後 (B) に未認証状態を検出した場合、 ブラウザをこのエンドポイントへ移動させることができます。これにより、BFF は ブラウザを認可サーバーへ移動させるリダイレクトで応答できます。通常、このフローを 開始するエンドポイントは、Web サーバー上で動作するコンフィデンシャルクライアント向けに OAuth 2.0 をサポートするライブラリによって「ログイン」エンドポイントとして提供されます。 BFF が (B) で有効なセッションが存在しないことを検出した際に、 認可コードフローを開始することも可能です。その場合、BFF は レスポンスで認可 URI を返し、アプリケーションが この URI を使用してナビゲーションイベントをトリガーすることを想定します。ただし、このシナリオには カスタム実装が必要となり、標準の OAuth ライブラリを使用しにくくなります。¶

認可コードを受け取るエンドポイント (E) は、 ブラウザ内からのナビゲーションイベントによって呼び出されます。この時点では アプリケーションは読み込まれておらず、リダイレクトを処理できる状態ではありません。 フローの開始時と同様に、リダイレクトを処理するエンドポイントは 標準の OAuth ライブラリによって提供されます。BFF は、このリクエストに対し、 ブラウザにアプリケーションを読み込ませるリダイレクトで応答できます。¶

最後に、BFF はアプリケーションに 「ログアウト」エンドポイントを提供することもできます。これは 図1には示されていません。ログアウト エンドポイントの正確な動作は、アプリケーションの要件によって異なります。標準の OAuth ライブラリでも通常、「ログアウト」エンドポイントの実装が提供されることに注意してください。¶

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

セクション 4.14（[RFC9700]）で説明されているようにリフレッシュトークンを使用する場合、BFF は リフレッシュトークン (F) を取得し、ユーザーのセッションに関連付けます。¶

ユーザーのアクセストークンが 期限切れになったことを BFF が検出し、BFF がリフレッシュトークンを保持している場合、 リフレッシュトークンを使用して新しいアクセストークンを取得できます。BFF の OAuth クライアントは コンフィデンシャルクライアントであるため、リフレッシュトークンリクエストでクライアント認証を使用します。通常、BFF は、 フロントエンドからの API 呼び出しを処理する際に、これらの手順をインラインで実行します。その 場合、図1には明示されていないこれらの手順が、 (J) と (K) の間で実行されます。すべてのトークン情報を サーバー側で利用可能な状態に保つ BFF は、トークンの期限切れイベントを検出したときに 新しいアクセストークンを要求し、API リクエストのパフォーマンスを向上させることもできます。¶

リフレッシュトークンの期限が切れると、まったく新しい認可コードフローを 実行しない限り、有効なアクセストークンを取得する方法はありません。 したがって、BFF が管理する Cookie ベースのセッションの有効期間を、 リフレッシュトークンの最大有効期間と等しく設定することは合理的です。 さらに、有効なセッションのリフレッシュトークンが 無効になったことを BFF が認識した場合、そのセッションも無効にすることが合理的です。¶

6.1.2.3. Cookie ベースのセッション状態

BFF は、ユーザーのトークンへのアクセスに使用される セッションを追跡するため、ブラウザの Cookie [RFC6265bis]を利用します。サーバー側と クライアント側のどちらの Cookie ベースセッションにも、いくつかの欠点があります。¶

サーバー側セッションでは、セッション識別子だけを公開し、 すべてのデータをサーバーに保持します。これにより、有効なセッションを高度に制御でき、 任意のセッションを必要に応じて失効させることもできます。この 手法の欠点はスケーラビリティへの影響であり、「スティッキーセッション」や 「セッションレプリケーション」などの解決策が必要になります。これらの欠点を考慮すると、 BFF でのサーバー側セッションの使用は、小規模なシナリオでのみ推奨されます。¶

クライアント側セッションでは、すべてのデータを署名付き、 必要に応じて暗号化されたオブジェクトとしてブラウザへ送信します。このパターンにより、サーバーは セッションデータを追跡する必要がなくなりますが、有効な セッションの制御が大幅に制限され、セッションの失効処理が困難になります。ただし、 クライアント側セッションを BFF のコンテキストで使用する場合、これらの特性は 大きく変化します。Cookie ベースのセッションはユーザーの トークンを取得するためだけに使用されるため、すべての制御および失効の特性は、アクセストークンと リフレッシュトークンの使用に基づきます。Cookie ベースのセッションを明示的に 無効にしなくても、ユーザーのアクセストークンや リフレッシュトークンを失効させるだけで、保護されたリソースへの継続的なアクセスを防止できます。¶

セッション Cookie を保護するためのベストプラクティスについては、 セクション 6.1.3.2で説明します。¶

6.1.2.4. OAuth と OpenID Connect の組み合わせ

このアプリケーションアーキテクチャで使用する OAuth フローは、 認可リクエスト (C) に必要な OpenID Connect スコープ (少なくとも [OpenID]のセクション 3.1.2.1 で定義されている openid スコープ) を含めることで、OpenID Connect と組み合わせることができます。 この場合、BFF は (F) で ID トークンを受け取ります。BFF は ID トークンの情報をユーザーのセッションに関連付け、(B) または (I) でアプリケーションに提供できます。¶

必要な場合、BFF はユーザーのセッションに関連付けられた アクセストークンを使用して、UserInfo エンドポイントへリクエストを送信できます。¶

6.1.2.5. 実用的な展開戦略

静的 JavaScript コードの配信は、 OAuth トークンの処理およびリクエストの転送とは別の責務です。図1では、 BFF と静的 Web ホストが2つの別個の主体として示されています。実際の 展開では、これらのコンポーネントを単一のサービス (すなわち、BFF が 静的 JavaScript コードを配信)、2つの別個のサービス (すなわち、コンテンツ 配信ネットワーク (CDN) と BFF)、または単一サービス内の2つのコンポーネント (すなわち、クラウドプラットフォーム上の静的ホスティングとサーバーレス関数) として展開できます。¶

特定のシナリオをサポートするため、この アーキテクチャをさらにカスタマイズできることに注意してください。たとえば、内部と外部の 両方のリソースサーバーを利用するアプリケーションは、内部 リソースサーバーを BFF と共にホストできます。このシナリオでは、内部 リソースサーバーへのリクエストは、ネットワーク経由で 転送することなく、BFF で直接処理されます。ユーザーのセッションは内部で アクセストークンおよびそのクレームへ変換されるため、リソースサーバーから見た認可は 変わりません。¶

6.1.3.1. 認可コードグラント

BFF を使用する主な利点は、BFF が コンフィデンシャルクライアントとして動作できることです。したがって、BFF は MUST、 認可サーバーとの間でクレデンシャルを確立し、コンフィデンシャルクライアントとして 動作しなければなりません。さらに、BFF は MUST、 アクセストークンのリクエストを開始するため、セクション 2.1.1（[RFC9700]）で説明されている OAuth 2.0 認可コードグラントを 使用しなければなりません。¶

6.1.3.2. Cookie セキュリティ

BFF は Cookie を使用してユーザーセッションを作成します。このセッションは、 サーバー側またはクライアント側のセッション状態を通じて、ユーザーのトークンに 直接関連付けられます。これらの Cookie は機密性が高いため、 適切に保護しなければなりません。¶

この BFF アーキテクチャには、 次の Cookie セキュリティガイドラインが適用されます。¶

• BFF は MUST、 Cookie の Secure フラグを有効にしなければなりません。¶

• BFF は MUST、 Cookie の HttpOnly フラグを有効にしなければなりません。¶

• BFF は SHOULD、 Cookie の SameSite=Strict フラグを有効にすべきです。¶

• BFF は SHOULD、 Cookie のパスを / に設定すべきです。¶

• BFF は SHOULD NOT、 Cookie に Domain 属性を設定すべきではありません。¶

• BFF は SHOULD、 Cookie が HTTP を介して設定されたことを示す接頭辞で Cookie 名を開始すべきです。たとえば、[COOKIES]で定義されている __Host-Http- 接頭辞を使用します。¶

注: 新しい展開では、上記の要件はすべて 容易に実装できる可能性があります。「SHOULD」の項目が「MUST」の項目とされていないのは、既存のアーキテクチャも 準拠できるようにするためです。これらの要件がもたらす影響を以下に示します。¶

これらの Cookie セキュリティガイドラインは、 HTTPS の使用と組み合わせることで、Cookie ベースのセッションを直接標的とする攻撃への対策に役立ちます。 Secure および HttpOnly Cookie フラグにより、セッションハイジャックは不可能になります。 __Host-Http- 接頭辞は、Cookie がサブドメインと共有されることを 防止し、サブドメインベースのセッションハイジャックや セッション固定攻撃に対抗します。一般的な BFF 展開シナリオでは、上記の要件よりも緩い Cookie セキュリティ 設定を使用する理由はありません。これらの設定から逸脱する場合は、 対象となる展開シナリオに適した根拠が必要です。¶

さらに、アクセストークンを含むクライアント側セッション (トークンがサーバー上にのみ存在するサーバー側セッションとは異なる) を使用する場合、 BFF は SHOULD、Cookie の内容を暗号化すべきです。 Cookie の暗号化を使用しても BFF パターンのセキュリティ 特性には影響しませんが、Cookie に保存されたトークンが 平文形式でユーザーのローカル永続ストレージへ書き込まれないことを保証できます。この セキュリティ対策は、攻撃者がハードドライブから Cookie を読み取れる場合に、 トークンの機密性を確保するのに役立ちます。このような攻撃は、 被害者のコンピューターで動作するマルウェアを介して実行できます。 Cookie の内容を暗号化すると埋め込まれたトークンへの直接アクセスは防止できますが、 攻撃者は暗号化された Cookie をセッションハイジャック 攻撃に使用できることに注意してください。¶

Cookie セキュリティのベストプラクティスに関する詳細なガイダンスについては、 OWASP チートシートシリーズ [OWASPCheatSheet]を参照してください。¶

6.1.3.3. クロスサイトリクエストフォージェリ対策

ブラウザベースアプリケーションと BFF の間のやり取りでは、認証と認可に Cookie を使用します。ほかの Cookie ベースのやり取りと同様に、BFF はクロスサイトリクエスト フォージェリ (CSRF) 攻撃を考慮する必要があります。CSRF 攻撃が成功すると、 BFF への攻撃者のリクエストによって、保護されたリソースへの外向きの呼び出しがトリガーされる可能性があります。¶

BFF は MUST、適切な CSRF 防御を実装しなければなりません。使用する具体的な仕組みまたは仕組みの組み合わせは、 以下で説明するように、BFF が展開される ドメインによって異なります。¶

6.1.3.4. BFF アーキテクチャにおけるプライバシー上の 考慮事項

BFF パターンでは、ブラウザベース アプリケーションがリソースサーバーへのすべてのリクエストを、バックエンドの BFF コンポーネント経由で転送する必要があります。その結果、BFF コンポーネントは、 アプリケーションとリソースサーバー間のすべてのリクエストとレスポンスを監視でき、 プライバシーに大きな影響を与える可能性があります。¶

ブラウザベースアプリケーションと BFF が同じ主体によって 構築および展開される場合、プライバシーへの影響は最小限である可能性があります。ただし、 サードパーティーによって提供またはホストされる BFF コンポーネントを使用してこのパターンを実装する場合、このプライバシーへの影響を考慮する必要があります。¶

6.1.3.5. 運用上の考慮事項

BFF はフロントエンドに代わって すべてのリクエストをリソースサーバーへ転送するため、リソース サーバーがこのコンポーネントを認識し、レート 制限やその他の不正使用防止対策に適切なポリシーを使用するよう注意する必要があります。たとえば、 BFF が単一インスタンスのサービスとして展開され、リソースサーバーが IP アドレスに基づいてリクエストをレート制限している場合、多数のユーザーの ブラウザが BFF の単一の IP アドレスからアクセスしているように見えるため、 サーバーがリクエストをブロックし始める可能性があります。¶

6.1.3.6. プロキシの 制限

BFF は、フロントエンドからリクエストを受け取り、 リソースサーバーへ転送することで、プロキシサービスとして動作します。受信リクエストには Cookie が含まれ、BFF は送信リクエストでそれをアクセストークンへ変換します。 (このため、BFF は HTTP プロキシよりもアプリケーション層のリバースプロキシに近いものとなります。) CSRF 攻撃のほかに、攻撃者は BFF を操作して、 意図しないホストへリクエストを転送させようとする可能性があります。攻撃者が これを悪用することに成功すると、BFF を任意のサーバーへリダイレクトし、 ユーザーのアクセストークンを露出させる可能性があります。¶

このリスクを緩和するため、BFF は MUST、リクエストを転送する前に送信先ホストを 検証し、厳格な送信リクエスト制御を適用しなければなりません。これには、 承認されたリソースサーバーの明示的な許可リストを維持し、 リクエストが事前定義されたバックエンドにのみプロキシされることを保証する必要があります (例: /bff/orders/create は https://order-api.example.com/createにのみマッピングされる)。 パスに基づく動的ルーティング (例: /bff/orders/{id}) が必要な場合、BFF は MUST、認可された送信先だけに アクセスできるよう厳格な検証を適用しなければなりません。さらに、エンドポイントごとに許可する HTTP メソッドを制限することで、攻撃ベクトルをさらに減らすことができます。¶

動的に設定可能なプロキシを実装する場合、 BFF は MUST、明示的に許可された ホストとパスへのリクエストだけを許可しなければなりません。これらの制限を適用しないと、 認可されていないアクセスやアクセストークンの漏洩につながる可能性があります。¶

6.1.3.7. 高度な セキュリティ

BFF パターンでは、OAuth に関するすべての責務が、 コンフィデンシャルクライアントとして動作するサーバー側コンポーネントである BFF へ 移されます。サーバー側アプリケーションはブラウザベース アプリケーションよりも制御された環境で動作するため、高度な OAuth セキュリティプラクティスを 導入しやすくなります。たとえば、鍵ベースのクライアント認証や送信者制約付き トークンがあります。¶

6.1.4.1. 攻撃 シナリオとその影響

攻撃者がアプリケーションの実行コンテキスト内で 悪意のあるコード (例: JavaScript または WASM) を実行できる場合、 次の攻撃シナリオが該当します。¶

• ユーザーのブラウザを介したリクエストのプロキシ (セクション 5.1.4)¶

この攻撃シナリオは、次の 影響をもたらすことに注意してください。¶

• クライアントハイジャック (セクション 5.2.3)¶

クライアントハイジャックは、 ブラウザベースアプリケーションの性質に内在する攻撃シナリオであることに注意してください。そのため、 悪意のあるコードの実行自体を阻止する以外に、 このような攻撃を防止する方法はありません。これに役立つ手法には、 セキュアコーディングガイドラインへの準拠、コード分析、コンテンツセキュリティポリシー [W3C.CSP3]などの多層防御 機構の展開があります。¶

このアーキテクチャでは、BFF は、 セキュリティ固有のさまざまな責務とプロキシベースの動作を処理する主要コンポーネントです。 プロキシベースアプリケーションの安全な実装について説明することは この文書の範囲外ですが、BFF のセキュリティ脆弱性が アプリケーションに重大な影響を与える可能性があることに注意することが極めて重要です。¶

最後に、BFF はブラウザベースアプリケーションと リソースサーバー間のすべてのトラフィックを監視できる独自の位置にあります。 高度なセキュリティを必要とするアプリケーションが異常検出やレート 制限を実装する場合、BFF はそのための理想的な場所です。このような制限は、 クライアントハイジャックによる影響をさらに緩和するのに役立ちます。¶

6.1.4.2. 緩和される攻撃シナリオ

以下に示すほかの攻撃シナリオは、BFF アプリケーションアーキテクチャによって効果的に緩和されます。¶

• 単一実行によるトークン窃取 (セクション 5.1.1)¶

• 持続的なトークン窃取 (セクション 5.1.2)¶

• 新しいトークンの取得および抽出 (セクション 5.1.3)¶

BFF はブラウザベースアプリケーションに トークンを一切露出させないことで、最初の2つの攻撃シナリオに対抗します。攻撃者が アプリケーションを完全に制御した場合でも、盗めるトークンは 存在しません。¶

3番目のシナリオでは、攻撃者がサイレントフローを実行して 新しいアクセストークン (および必要に応じてリフレッシュトークン) を取得しますが、 BFF をコンフィデンシャルクライアントにすることで緩和されます。攻撃者が 認可コードの取得に成功した場合でも、クライアントクレデンシャルを持たないため、 そのコードを交換できません。さらに、PKCE を使用すると、 認可コードに対するほかの攻撃を防止できます。¶

リフレッシュトークンとアクセストークンは BFF によって管理され、 ブラウザに露出しないため、潜在的な攻撃がもたらす次の2つの影響は 該当しなくなります。¶

• 盗まれたリフレッシュトークンの悪用 (セクション 5.2.1)¶

• 盗まれたアクセストークンの悪用 (セクション 5.2.2)¶

6.1.4.3. まとめ

BFF のアーキテクチャは、ブラウザのみのアプリケーションよりも 大幅に複雑です。サーバー側の BFF コンポーネントを展開して運用する必要があります。 さらに、このパターンでは、アプリケーションとリソースサーバー間のすべての やり取りを BFF がプロキシする必要があります。展開パターンによっては、 このプロキシ動作がサーバー側コンポーネントに 大きな負荷を加える可能性があります。BFF がリソース サーバーとして動作する場合の追加の注記については、セクション 6.2.2.6を参照してください。¶

ただし、BFF アーキテクチャ パターンの性質上、強力なセキュリティ保証が提供されます。BFF を使用すると、 OAuth の使用によってアプリケーションの攻撃対象領域が増加しないことも保証されます。実行可能な唯一の 攻撃パターンは、ユーザーのブラウザ内にあるクライアントアプリケーションのハイジャックです。これは、 Web アプリケーションに内在する問題です。¶

このアーキテクチャは、業務 アプリケーション、機密性の高いアプリケーション、および個人 データを扱うアプリケーションに強く推奨されます。¶

6.2.2.1. セッションおよび OAuth エンドポイント

トークン仲介バックエンドの エンドポイント実装の大部分は、BFF について説明したものと同様です。¶

• 「セッション確認」エンドポイント (図 2の (B) および (I)) は、ブラウザベースアプリケーションが呼び出す API エンドポイントです。利用可能な場合、リクエストにはセッション情報が含まれ、 バックエンドが有効なセッションを確認できるようになります。レスポンスは、 セッションが有効かどうかをブラウザベースアプリケーションに示す必要があります。 有効なセッションが見つかった場合、バックエンドはアクセストークンを レスポンスに含めます。さらに、バックエンドは、認証済みユーザーの 識別情報など、ほかの情報を含めることができます。¶

• 認可コード フローを開始するエンドポイント (C) は、BFF アーキテクチャについて説明したエンドポイントと同一です。詳細については、セクション 6.1.2.1を参照してください。¶

• 認可 コードを受け取るエンドポイント (E) は、BFF アーキテクチャについて説明したエンドポイントと同一です。詳細については、セクション 6.1.2.1を参照してください。¶

• ログアウトをサポートするエンドポイントは、 BFF アーキテクチャについて説明したエンドポイントと同一です。詳細については、セクション 6.1.2.1を 参照してください。¶

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

セクション 4.14（[RFC9700]）で説明されているようにリフレッシュトークンを使用する場合、トークン仲介バックエンドは (F) でリフレッシュトークンを取得し、ユーザーのセッションに関連付けます。¶

リソースサーバーがアクセストークンを拒否した場合、 アプリケーションはトークン仲介バックエンドへ新しいアクセス トークンを要求できます。トークン仲介バックエンドは、この リクエストに関連付けられた Cookie を使用してユーザーのリフレッシュトークンを検索し、 リフレッシュトークンを使用してトークンリクエストを行います。これらの手順は、図2には示されていません。このリフレッシュトークン リクエストはコンフィデンシャルクライアントであるバックエンドから送信されるため、 クライアント認証が必要になることに注意してください。¶

リフレッシュトークンの期限が切れると、まったく新しい認可コードグラントを 開始しない限り、有効なアクセストークンを取得する方法はありません。 したがって、この情報が事前に判明している場合は、Cookie ベースのセッションの有効期間を リフレッシュトークンの最大有効期間と等しく設定することが合理的です。 さらに、有効なセッションのリフレッシュトークンが 無効になったことをトークン仲介バックエンドが認識した場合、そのセッションを 無効にすることが合理的です。¶

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

アクセスするリソースサーバーおよび 認可サーバーでのスコープ設定によっては、アプリケーションは、 異なるスコープ設定を持つアクセストークンを要求する場合があります。この動作により、 アプリケーションは、スコープを最小限に抑えた アクセストークンを使用するというベストプラクティスに従うことができます。¶

アプリケーションは、有効なセッションを確認する際 ((A) および (I)) に、必要なスコープをトークン仲介バックエンドへ通知できます。 以前に取得したアクセストークンが 必要なスコープの条件を満たすかどうかは、トークン仲介バックエンドが判断します。¶

トークン仲介バックエンドにおけるこのアクセストークンのキャッシュ 機構は、無差別に適用するとスコープ昇格のリスクを引き起こす可能性があることに 注意する必要があります。キャッシュされたアクセストークンが、 フロントエンドから要求されたスコープの上位集合を持つ場合、トークン仲介バックエンドは SHOULD NOT、そのトークンをフロントエンドへ返すべきではありません。代わりに、SHOULD、リフレッシュトークンを使用して、より小さなスコープ集合を持つ アクセストークンを認可サーバーへ要求すべきです。このような アクセストークンのスコープ縮小機構をサポートするかどうかは、 認可サーバーの裁量で決定されることに注意してください。¶

トークン仲介バックエンドは、 [RFC8707]で説明されている拡張機能を利用して 特定のリソースサーバー向けのアクセストークンを取得する場合にも、 スコープ縮小機構と同様の仕組みを使用できます。¶

6.2.2.4. Cookie ベースのセッション状態

BFF と同様に、トークン仲介バックエンドは、 ユーザーのセッションを追跡するためにブラウザの Cookie を利用します。Cookie ベースセッションの 実装ガイドラインとセキュリティ上の考慮事項は、セクション 6.1.2.3で説明した BFF のものと同じです。¶

6.2.2.5. OAuth と OpenID Connect の組み合わせ

BFF と同様に、トークン仲介バックエンドは、 OAuth と OpenID Connect を単一のフローに組み合わせることができます。詳細については、セクション 6.1.2.4を 参照してください。¶

6.2.2.6. 実用的な展開シナリオ

静的 JavaScript または WASM コードのホスティングは、 認可サーバーとのやり取りの処理とは別の責務です。図2では、 トークン仲介バックエンドと静的 Web ホストが2つの別個の主体として示されています。 実際の展開シナリオでは、これらのコンポーネントを単一の サービス (すなわち、トークン仲介バックエンドが静的コードを配信)、2つの 別個のサービス (すなわち、CDN とトークン仲介バックエンド)、または単一サービス内の2つの コンポーネント (すなわち、クラウドプラットフォーム上の静的ホスティングとサーバーレス関数) として展開できます。これらの展開方法の違いは、このパターンで説明した関係には影響しませんが、 クロスオリジン通信を有効にするために CORS を適切に設定する必要性など、 ほかの実務上の事項に影響する可能性があります。¶

6.2.3.1. 認可コードグラント

トークン仲介バックエンドを使用する主な利点は、 バックエンドがコンフィデンシャルクライアントとして動作できることです。したがって、 トークン仲介バックエンドは MUST、コンフィデンシャル クライアントとして動作しなければなりません。さらに、トークン仲介バックエンドは MUST、 アクセストークンのリクエストを開始するため、セクション 2.1.1（[RFC9700]）で説明されている OAuth 2.0 認可コードグラントを 使用しなければなりません。¶

6.2.3.2. Cookie セキュリティ

トークン仲介バックエンドは Cookie を使用してユーザー セッションを作成します。このセッションは、サーバー側または クライアント側のセッション状態を通じて、ユーザーのトークンに直接関連付けられます。セクション 6.1.3.2で説明した BFF 向けの Cookie セキュリティガイドラインが、 同様に適用されます。¶

6.2.3.3. クロスサイトリクエストフォージェリ対策

ブラウザベースアプリケーションと トークン仲介バックエンドの間のやり取りでは、認証と認可に Cookie を使用します。 BFF と同様に、トークン仲介バックエンドは CSRF 攻撃を考慮する必要があります。¶

セクション 6.1.3.3では、 CSRF 攻撃に対するさまざまな緩和戦略の詳細を説明しています。 トークン仲介バックエンドの場合、これらの CSRF 防御は、 アプリケーションがアクセストークンを取得できるエンドポイントにのみ適用されます。¶

6.2.3.4. 高度な OAuth セキュリティ

トークン仲介バックエンドは、 サーバー側コンポーネントとして動作するコンフィデンシャルクライアントです。トークン仲介バックエンドは、 鍵ベースのクライアント認証など、コンフィデンシャルクライアント向けの セキュリティベストプラクティスを採用できます。¶

6.2.4.1. 攻撃シナリオとその影響

攻撃者がアプリケーションの実行コンテキスト内で 悪意のあるコードを実行できる場合、次の攻撃シナリオが 該当します。¶

• アクセストークンに対する単一実行によるトークン窃取 (セクション 5.1.1)¶

• アクセストークンに対する持続的なトークン窃取 (セクション 5.1.2)¶

• ユーザーのブラウザを介したリクエストのプロキシ (セクション 5.1.4)¶

これらの攻撃シナリオは、次の 影響をもたらすことに注意してください。¶

• 盗まれたアクセストークンの悪用 (セクション 5.2.2)¶

• クライアントハイジャック (セクション 5.2.3)¶

ブラウザベースアプリケーションへアクセストークンを 露出させることは、トークン仲介バックエンドアーキテクチャパターンの中核となる考え方です。 その結果、アクセストークンは悪意のある ブラウザベースのコードによるトークン窃取に対して脆弱になります。¶

6.2.4.2. 緩和される攻撃シナリオ

以下に示すほかの攻撃シナリオは、 トークン仲介バックエンドによって効果的に緩和されます。¶

• リフレッシュトークンに対する単一実行によるトークン窃取 (セクション 5.1.1)¶

• リフレッシュトークンに対する持続的なトークン窃取 (セクション 5.1.2)¶

• 新しいトークンの取得および抽出 (セクション 5.1.3)¶

トークン仲介バックエンドは、リフレッシュトークンを ブラウザベースアプリケーションに露出させないことで、最初の2つの攻撃 シナリオに対抗します。攻撃者がアプリケーションを完全に制御した場合でも、 盗めるリフレッシュトークンは存在しません。¶

3番目のシナリオでは、攻撃者がサイレントフローを実行して 新しいアクセストークン (および必要に応じてリフレッシュトークン) を取得しますが、 トークン仲介バックエンドをコンフィデンシャルクライアントにすることで緩和されます。 攻撃者が認可コードの取得に成功した場合でも、 クライアントクレデンシャルを持たないため、そのコードを交換できません。さらに、 PKCE を使用すると、認可コードに対するほかの攻撃を防止できます。¶

トークン仲介バックエンドの性質により、 潜在的な攻撃がもたらす次の影響は該当しなくなります。¶

• 盗まれたリフレッシュトークンの悪用 (セクション 5.2.1)¶

6.2.4.3. 追加の 防御策

このアーキテクチャは本質的にアクセストークンを露出させますが、 アプリケーションのセキュリティ態勢を 強化するのに役立つ追加の防御策がいくつかあります。¶

6.2.4.4. まとめ

トークン仲介バックエンドのアーキテクチャは、 ブラウザのみのアプリケーションより複雑ですが、プロキシを行う BFF の運用ほど複雑ではありません。同様に、トークン仲介バックエンドが提供する セキュリティ特性は、BFF の使用と ブラウザのみのアプリケーションの運用との中間に位置します。¶

トークン仲介バックエンドは、 攻撃者にユーザーの代理として長期間アクセスする権限を与える一般的なシナリオに対処します。ただし、 アクセストークン窃取の影響により、攻撃者は依然として リソースサーバーへ直接アクセスできます。¶

トークン仲介バックエンドアーキテクチャを検討する場合、 セクション 6.1で説明した完全な BFF の採用が 実行可能な代替手段であるかどうかを評価することを強く推奨します。 ユースケースまたはシステム要件によって プロキシを行う BFF を使用できない場合に限り、完全な BFF よりもトークン仲介バックエンドを検討すべきです。¶

6.3.2.1. 認可コードグラント

パブリッククライアントであるブラウザベースアプリケーションは MUST、アクセストークンを取得するときに PKCE [RFC7636]拡張機能を実装しなければならず、 認可サーバーは MUST、このようなクライアントに対して PKCE をサポートし、適用しなければなりません。¶

PKCE 拡張機能は、 認可コードを交換する クライアントインスタンスがフローを開始したものと同一であることを 認可サーバーが検証できるようにすることで、認可コードが傍受され、 悪意のあるクライアントによってアクセストークンと交換される攻撃を防止します。¶

6.3.2.2. クロスサイトリクエストフォージェリ対策

ブラウザベースアプリケーションは MUST、 リダイレクト URI に対する CSRF 攻撃を防止しなければなりません。これは、 次のいずれかによって実現できます。¶

• このクライアントに対して PKCE を必須とするよう認可サーバーを設定する¶

• CSRF トークンを伝達するため、OAuth の state パラメーターに一意の値を使用して検証する¶

• アプリケーションが OpenID Connect も 使用する場合、[OpenID]で説明されている OpenID Connect の nonce パラメーターを使用して検証する¶

認可コードフローに適した CSRF 防御の選択に関する詳細については、セクション 2.1（[RFC9700]）を参照してください。¶

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

ブラウザベースクライアントの場合、アプリケーションが明示的に DPoP [RFC9449]を使用しない限り、リフレッシュトークンは通常 ベアラートークンです。その結果、漏洩したリフレッシュトークンの リスクは漏洩したアクセストークンより高くなります。攻撃者が盗んだリフレッシュトークンを使用し続け、 認可サーバーに 検出されることなく新しいアクセストークンを取得できる可能性があるためです。¶

認可サーバーは、ブラウザベース アプリケーションへリフレッシュトークンを発行するかどうかを選択できます。ただし、 サードパーティー Cookie ブロック機構の影響を考慮すると、 リフレッシュトークンの使用は大幅に魅力的になっています。 [RFC9700]では、 [RFC6749]の推奨事項に加えて、リフレッシュトークンに関する 追加要件がいくつか説明されています。この BCP に準拠するアプリケーションと認可 サーバーは MUST、ブラウザベースアプリケーションにリフレッシュトークンを発行する場合、 リフレッシュトークンに関する [RFC9700]の 推奨事項にも従わなければなりません。¶

具体的には、認可サーバーは次の要件に従わなければなりません。¶

• MUST、 使用するたびにリフレッシュトークンをローテーションするか、セクション 4.14.2（[RFC9700]）で説明されている 送信者制約付きリフレッシュトークンを使用しなければならない¶

• MUST、 リフレッシュトークンに最大有効期間を設定するか、一定期間 リフレッシュトークンが使用されなかった場合に期限切れにしなければならない¶

• MUST NOT、 リフレッシュトークンに事前設定された有効期限がある場合、 ローテーションされたリフレッシュトークンの発行時に、新しいリフレッシュ トークンの有効期間を最初のリフレッシュトークンの有効期間より先まで 延長してはならない¶

リフレッシュトークン全体の有効期間を 最初のリフレッシュトークンの有効期間に制限すると、盗まれたリフレッシュトークンが 無期限に使用されることを防止できます。¶

例:¶

• ユーザーがアプリケーションを認可し、 有効期間10分のアクセストークンと有効期間8 時間のリフレッシュトークンが発行される。¶

• 10分後、最初のアクセストークンが 期限切れになるため、アプリケーションはリフレッシュトークンを使用して新しいアクセス トークンを取得する。¶

• 認可サーバーは、有効期間10分の新しいアクセス トークンと、有効期間7時間 50分の新しいリフレッシュトークンを返す。¶

• これは、最初の 認可から8時間が経過するまで続く。¶

• この時点で、アプリケーションが 8時間後にリフレッシュトークンを使用しようとすると、リクエストは失敗し、 アプリケーションはユーザーの認証または以前に確立されたセッションを利用する 認可コードフローを再度開始する必要がある。¶

認可サーバーは SHOULD、 リフレッシュトークンの有効期間を、認可サーバーにおけるユーザーの認証済みセッションに 関連付けるべきです。これにより、ユーザーがログアウトしたとき、 ブラウザベースアプリケーションへ以前に発行されたリフレッシュトークンが無効になり、 シングルログアウトのシナリオを再現できます。認可サーバーは MAY、 ほかのパブリッククライアントとは異なる、ブラウザベースアプリケーション向けの リフレッシュトークンの発行、有効期間、および期限切れに関するポリシーを設定してもかまいません。¶

6.3.3.1. クライアント 認証

ブラウザベースアプリケーションのソースコードは、 エンドユーザーの ブラウザへ配信されるため、事前設定されたシークレットを含めるのには適していません。その結果、 ブラウザベースアプリケーションは通常、セクション 2.1（[RFC6749]）で定義される パブリッククライアントとして展開されます。¶

複数のユーザーへ配布されるアプリケーションの一部として 静的に含まれるシークレットは、 機密のシークレットとして扱うべきではありません。各 ユーザーが自身のコピーを調査して、共有シークレットを知ることができるためです。この 理由と、セクション 5.3.1（[RFC6819]）に記載された理由から、認可 サーバーは MUST NOT、共有シークレットを使用したブラウザベース アプリケーションのクライアント認証を要求してはなりません。この認証は、 client_id パラメーターによってすでに提供される クライアント識別以上の価値を持たないためです。¶

SPA クライアントに静的に含まれる共有 シークレットを依然として要求する認可サーバーは MUST、そのクライアントを パブリック クライアントとして扱い、シークレットをクライアントの身元証明として受け入れてはなりません。 追加の対策がない場合、このようなクライアントはクライアント偽装の対象となります (セクション 6.3.3.2を参照)。¶

6.3.3.2. クライアント 偽装

セクション 10.2（[RFC6749]）に記載されているように、認可 サーバーは SHOULD NOT、クライアントアプリケーションの身元を 保証できる場合を除き、ユーザーの同意または操作なしで 認可リクエストを自動的に処理すべきではありません。¶

認可サーバーがリダイレクト URI を、 ワイルドカードドメイン、ワイルドカードパス、またはワイルドカード クエリ文字列コンポーネントを使用できない、固定された絶対 HTTPS URI の集合に制限している場合、認可サーバーは、 登録された絶対 HTTPS URI との完全一致を MAY、 client_idに対する以前のリクエストが すでに承認されているときに、認可リクエストを 自動処理するかどうかを判断するためのクライアントの身元証明として 受け入れてもかまいません。¶

6.3.3.3. ブラウザ内通信フローのセキュリティ

ブラウザベースアプリケーションでは、 プライマリウィンドウをリダイレクトする代わりに、 ポップアップや iframe などのセカンダリウィンドウで OAuth フローを実行することが一般的です。 このようなフローでは、ページの再読み込みを避けたり、 フレームベースのフローをサイレントに実行したりするため、ブラウザベースアプリケーションが プライマリウィンドウの制御を保持します。¶

ブラウザベースアプリケーションと認可サーバーが 異なるフレームで呼び出される場合、トップレベルの リダイレクトの代わりに、postMessage API (別名 [WebMessaging]) などのブラウザ内通信技術を使用する必要があります。 メッセージの機密性と真正性を保証するため、postMessage の送信元 オリジンと受信側オリジンの両方を MUST、 postMessage API が本来提供する仕組みを使用して検証しなければなりません ([WebMessaging]のセクション 9.3.2)。¶

セクション 4.17（[RFC9700]）では、 ブラウザ内通信フローのセキュリティと、これらの攻撃を防ぐために ブラウザベースアプリケーションおよび認可サーバーが MUST 適用しなければならない対策について詳しく説明しています。¶

6.3.3.4. クロスオリジン リクエスト

このシナリオでは、アプリケーションはブラウザ API を使用して、 認可サーバーとリソースサーバーへリクエストを送信します。 OAuth 2.0 の性質上、これらは通常クロスオリジンリクエストであり、 ブラウザによって適用されるクロスオリジン通信の制限を受けます。 認可サーバーとリソースサーバーは MUST、 アプリケーションが必要なクロスオリジンリクエストを送信できるようにするため、 必要な CORS ヘッダー ([Fetch]で定義) を送信しなければなりません。 ブラウザベース OAuth クライアントが 認可サーバーまたはリソースサーバーと同じオリジンで動作する例外的なシナリオでは、 必要なやり取りを有効にするための CORS ポリシーは不要であることに注意してください。¶

認可サーバーの場合、CORS 設定は、 ブラウザベースアプリケーションが認可コードをトークンと交換するトークンエンドポイントに 関係します。さらに、認可サーバーが ディスカバリメタデータ URL、JSON Web Key Set、動的クライアント登録、失効、イントロスペクション、 またはユーザー情報エンドポイントなどの追加エンドポイントをアプリケーションへ提供する場合、 ブラウザベースアプリケーションがこれらのエンドポイントにアクセスすることもあります。そのため、認可サーバーは、 これらのエンドポイントで CORS をサポートする責務を負います。¶

この仕様には、 ワイルドカードオリジンまたはより制限的な設定で構成できる 具体的な CORS ポリシーの実装を決定するためのガイドラインは含まれていません。CORS には、 異なるセキュリティ特性を持つ2つの動作モードがあることに注意してください。最初のモードは、 CORS セーフリストリクエスト (以前は単純リクエストと呼ばれていた) に適用されます。この場合、ブラウザは リクエストを送信し、CORS レスポンスヘッダーを使用して、 レスポンスをクライアント側の実行コンテキストへ公開できるかどうかを判断します。 カスタムリクエストヘッダーを含むリクエストなど、CORS セーフリストにない リクエストの場合、ブラウザは最初にプリフライトを使用して CORS ポリシーを 確認します。サーバーがプリフライトレスポンスで承認を返した場合に限り、ブラウザは 実際のリクエストを送信します。¶

認可サーバー固有の 設定によっては、プリフライトへの CORS レスポンスが 実際のリクエストへの CORS レスポンスと異なる場合があることに注意してください。プリフライト中、 認可サーバーは提供されたオリジンだけを検証できますが、実際の リクエストでは、クライアント ID などの完全なリクエストデータを利用できます。 そのため、認可サーバーはプリフライト中に既知のオリジンを承認したうえで、 そのオリジンを特定のクライアントの事前登録済みオリジン一覧と比較し、 実際のリクエストを拒否できます。¶

6.3.4.1. 攻撃シナリオとその影響

攻撃者がアプリケーションの実行コンテキスト内で 悪意のあるコードを実行できる場合、次の攻撃シナリオが 該当します。¶

• 単一実行によるトークン窃取 (セクション 5.1.1)¶

• 持続的なトークン窃取 (セクション 5.1.2)¶

• 新しいトークンの取得および抽出 (セクション 5.1.3)¶

• ユーザーのブラウザを介したリクエストのプロキシ (セクション 5.1.4)¶

最も危険な攻撃シナリオは、新しいトークンの取得および 抽出です。この攻撃シナリオでは、攻撃者は認可サーバーとのみやり取りするため、 クライアント内の OAuth 機能の実際の実装詳細は 関係しません。正規のクライアント アプリケーションがトークンを攻撃者から完全に分離する方法を見つけた場合でも、 攻撃者は認可サーバーからトークンを取得できます。¶

これらの攻撃シナリオは、次の 影響をもたらすことに注意してください。¶

• 盗まれたリフレッシュトークンの悪用 (セクション 5.2.1)¶

• 盗まれたアクセストークンの悪用 (セクション 5.2.2)¶

• クライアントハイジャック (セクション 5.2.3)¶

6.3.4.2. 追加の 防御策

このアーキテクチャは本質的に 悪意のあるブラウザベースのコードに対して脆弱ですが、アプリケーションのセキュリティ態勢を 強化するのに役立つ追加の防御策がいくつかあります。これらの 防御策はいずれも、攻撃者が新しいフローを実行して トークンを取得できるという根本的な問題に対処したり、その問題を解決したりするものではないことに注意してください。¶

6.3.4.3. まとめ

まとめると、ブラウザベース OAuth クライアントアプリケーションのアーキテクチャは単純ですが、 アプリケーションの攻撃対象領域を大幅に増加させます。攻撃者は、 クライアントをハイジャックできるだけでなく、完全な機能を持つ一組のトークンを ブラウザベースアプリケーションから抽出することもできます。¶

このアーキテクチャは、業務 アプリケーション、機密性の高いアプリケーション、および個人 データを扱うアプリケーションには推奨されません。¶

7.2.3.1. リダイレクト URI の操作

攻撃者が認可レスポンスを 自身の管理下にある URI に送信させることができれば、 アクセストークンを含む認可レスポンスに直接アクセスできる。 この攻撃を実行するいくつかの方法が、[RFC9700]で詳しく説明されている。¶

7.2.3.2. ブラウザ履歴におけるアクセス トークンの漏えい

攻撃者はブラウザ履歴から アクセストークンを取得できる可能性がある。 [RFC6819]で推奨される対策は、トークンに短い 有効期限を 使用することと、ブラウザがレスポンスをキャッシュしないようにすることに限られる。 いずれもこの攻撃を完全には防止せず、潜在的な 被害を軽減するだけである。¶

さらに、現在では多くのブラウザがブラウザ履歴を クラウドサービスや 複数のデバイスにも同期するため、URL からアクセストークンを抽出できる 攻撃対象領域がさらに広がる。¶

これについては、セクション 4.3.2（[RFC9700]）で詳しく説明されている。¶

7.2.3.3. スクリプトの操作

攻撃者は、さまざまな 手段でページを変更したり、ブラウザにスクリプトを挿入したりできる可能性がある。これには、 たとえば企業ネットワークによってブラウザの HTTPS 接続が傍受される場合も 含まれる。TLS レイヤーに対する攻撃の防止は、通常、 基本的なセキュリティ推奨事項の範囲外 であるが、ブラウザベースアプリケーションの場合、 このような攻撃ははるかに実行しやすい。挿入されたスクリプトにより、攻撃者は ページ上のすべてのものにアクセスできる可能性がある。¶

アプリケーションが既知の標準的な方法で アクセストークンを取得している場合、ページ上で悪意のあるスクリプトが実行されるリスクが 増幅される可能性がある。つまり、攻撃者はいつでも window.location 変数を確認して アクセストークンを見つけられる。この脅威プロファイルは、 認可コードフローを介して取得されたアクセストークンがどこに、またはどのように 保存されるかを把握したうえで、攻撃者が特定のアプリケーションを 標的にする場合とは異なる。¶

7.2.3.4. サードパーティスクリプトへのアクセス トークンの漏えい

ブラウザベースアプリケーションで、 分析ツール、クラッシュレポート、さらにはソーシャルメディアの「いいね」 ボタンなどのサードパーティスクリプトを使用することは比較的一般的である。 このような状況では、アプリケーションの作成者が、アプリケーションで実行される コード全体を 完全に把握できない可能性がある。アクセストークンがフラグメントで 返されると、ページ上のすべてのサードパーティスクリプトから見える。¶

7.4.1.1. Service Worker への攻撃

Service Worker の使用によって得られる一見有望な セキュリティ上の利点については、そのセキュリティ上の制約をさらに詳しく検討する必要がある。 関連する攻撃シナリオ（セクション 5.1）からアプリケーションを 完全に保護するには、Service Worker が次の 2 つのセキュリティ要件を満たす必要がある。¶

1. 攻撃者が トークンを外部へ持ち出すことを防止する。¶

2. 攻撃者が新しい一連の トークンを取得することを防止する。¶

登録されると、Service Worker は認可 コードフローを実行してトークンを取得する。Service Worker は自身の隔離された実行環境で トークンを管理するため、潜在的に悪意のあるコードを含め、 どのアプリケーションコードもトークンにアクセスできない。したがって、 Service Worker は、トークンの外部流出を防止するという最初の要件を満たす。 これにより、セクション 5.1で説明した最初の 2 つの攻撃シナリオは実質的に無効化される。¶

2 番目のセキュリティ要件を満たすには、Service Worker は、正規のアプリケーションを制御する攻撃者が新しい認可コードグラントを 実行できないことを保証できなければならない。この攻撃については、 セクション 5.1.3で説明している。Service Worker の性質上、登録済みの Service Worker は、そのような新しいフローを開始するすべての送信リクエストを、 フレームまたは新しいウィンドウ内で発生した場合でも阻止できる。¶

しかし、アプリケーション内で実行される悪意のあるコードは、 この Service Worker の登録を解除できる。Service Worker の登録解除は アプリケーションの機能に重大な影響を与える可能性があるため、ブラウザが 軽々しく処理する操作ではない。そのため、登録解除された Service Worker は そのようにマークされるが、現在実行中のすべてのインスタンスは、それぞれに対応する ブラウジングコンテキストが終了するまで（たとえばタブまたは ウィンドウを閉じるまで）アクティブなままである。したがって、攻撃者が Service Worker の登録を解除しても、 その Service Worker はアクティブなままであり、攻撃者が認可 サーバーへ到達することを阻止できる。¶

Service Worker の登録を解除した場合の結果の 1 つは、 新しいブラウジングコンテキストが開かれたときに、その Service Worker が存在しないことである。したがって、 攻撃者が最初に Service Worker の登録を解除してから、フレーム内で新しいフローを 開始すると、そのフレームのブラウジングコンテキストに関連付けられた Service Worker は 存在しない。その結果、攻撃者は独自の新しい 認可コードグラントを実行し、フレームの URL から認可コードを抽出して、 トークンと交換できる。要するに、Service Worker は 2 番目のセキュリティ要件を満たせず、攻撃者が新しい一連のトークンを 取得するシナリオ（セクション 5.1.3）に対して脆弱なままとなる。¶

これらの欠点に加え、Service Worker の登録と 維持には相当な複雑さが伴うため、このパターンは 推奨されない。¶

最後に、Service Worker の使用それ自体が アプリケーションの攻撃対象領域を拡大するわけではないことに注意すること。実際には、Service Worker は、送信リクエストに OAuth アクセストークンを含める機能を レガシーアプリケーションへ後付けするために使用されることが多い。このような シナリオにおける Service Worker は、アプリケーションのセキュリティ特性を変更するのではなく、 単にアプリケーションの開発と保守を簡素化する。¶