Skip to content

FAPI 2.0 Security Profile

  • Workgroup: fapi
  • Published: 2025年2月22日
  • Status: Final

Authors

  • D. Fett (Authlete)
  • D. Tonge (Moneyhub Financial Technology)
  • J. Heenan (Authlete)

Abstract

OIDF FAPI 2.0は、OAuth 2.0 Authorization Framework [RFC6749] に基づく、高セキュリティ用途に適したAPIセキュリティプロファイルである。

Foreword

OpenID Foundation（OIDF）は、OpenIDコミュニティとその技術を推進し、保護し、育成する。OIDFは非営利の国際標準化団体であり、160を超える参加主体（workgroup participant）で構成される。実装者向けドラフトおよび最終的な国際標準の策定作業は、OpenID Processに従い、OIDFのワーキンググループを通じて実施される。ワーキンググループが設置されている分野に関心のある参加者は、そのワーキンググループで代表される権利を有する。OIDFと連携関係にある国際機関（政府・非政府を含む）も作業に参加する。OIDFは、関連分野の他の標準化団体とも緊密に協力している。

ワーキンググループが合意形成により採択した最終ドラフトは、公開レビューのために60日間一般に回覧され、またOIDFメンバーの投票のためにも回覧される。OIDF Standardとして公開するには、投票したメンバーの少なくとも50%の承認が必要である。本書の要素の一部は特許権の対象となる可能性がある。OIDFは、それらの特許権の全部または一部を特定する責任を負わない。

Introduction

FAPI 2.0 Security Profileは、OAuth 2.0 Authorization Framework [RFC6749] および関連仕様に基づくAPIセキュリティプロファイルであり、Attacker Model [attackermodel] で示されたセキュリティ目標の達成を目的としている。これにより、高価値なシナリオにおけるAPI保護に適するように設計されている。また、OAuth Security BCP [RFC9700] の推奨にも従う。

本書は、clientがauthorization serverからsender-constrained tokensを取得し、それらをresource serversで安全に利用するためのプロセスを規定する。

OpenID Foundation FAPI Working Groupは、FAPI 2.0 frameworkの一部として、このプロファイルを基盤とする追加文書を公開している。

このセキュリティ特性は、前述のattacker modelの下で形式的に解析されている [FAPI2SEC]。セキュリティ上の前提については、attacker modelを参照されたい。

このセキュリティプロファイルは当初、金融用途を重視して開発されたが、高価値かつ機微（個人情報その他）のデータを公開するAPIを保護するために、e-healthやe-governmentなどのアプリケーションにも普遍的に適用できるよう設計されている。

Notational conventions

本書中のキーワード "shall", "shall not", "should", "should not", "may", "can" は、ISO Directive Part 2 [ISODIR2] に記載のとおり解釈される。これらのキーワードは辞書的な意味で用いられるものではなく、出現箇所はすべてキーワードとして解釈され、自然言語としての意味で解釈してはならない。

1. Scope

本書は、所定のattacker modelを満たすことが形式解析により証明された、OAuth 2.0の汎用高セキュリティプロファイルを提供する。本書は次の要件を規定する。

  • Confidential clientsがauthorization serversからOAuth tokensを安全に取得するための要件
  • Confidential clientsがresource serversで保護されたリソースへアクセスするために、それらのtokensを安全に利用するための要件
  • authorization serversがconfidential clientsに対してOAuth tokensを安全に発行するための要件
  • resource serversがconfidential clientsからのOAuth tokensを安全に受理し検証するための要件

2. Normative references

以下の文書は、本書の要件の一部または全部を構成する形で本文中に参照される。日付付き参照の場合、引用された版のみが適用される。日付なし参照の場合、参照文書の最新版（改訂を含む）が適用される。

規範参照はSection 10を参照。

3. Terms and definitions

本書の目的において、[RFC6749], [RFC6750], [RFC7636], [OIDC], [ISO29100] で定義された用語を適用する。

4. Symbols and Abbreviated terms

  • API – Application Programming Interface（アプリケーション・プログラミング・インターフェース）
  • BCM – Basin, Cremers, Meier
  • BCP – Best Current Practice
  • CAA – Certificate Authority Authorization
  • CIBA – Client Initiated Backchannel Authentication
  • CSRF – Cross-Site Request Forgery
  • DNS – Domain Name System
  • DNSSEC – Domain Name System Security Extensions
  • HTTP – Hyper Text Transfer Protocol
  • JAR – JWT-Secured Authorization Request
  • JARM – JWT Secured Authorization Response Mode
  • JWK – JSON Web Key
  • JWKS – JSON Web Key Sets
  • JWT – JSON Web Token
  • JOSE – Javascript Object Signing and Encryption
  • JSON – JavaScript Object Notation
  • MTLS – Mutual Transport Layer Security
  • OIDF – OpenID Foundation
  • PAR – Pushed Authorization Requests
  • PKCE – Proof Key for Code Exchange
  • QR – Quick Response
  • RSA – Rivest-Shamir-Adleman
  • REST – Representational State Transfer
  • TLS – Transport Layer Security
  • URI – Uniform Resource Identifier
  • URL – Uniform Resource Locator

5. Security profile

5.1. Overview

5.1.1. Introduction

FAPI 2.0 Security Profileは、OAuth 2.0 Authorization Framework [RFC6749] に基づくAPIセキュリティプロファイルであり、次を目的とする。

  • Attacker Model [attackermodel] に示されたセキュリティ目標を達成すること
  • OAuth Security BCP [RFC9700] の推奨に従うこと

OpenID FAPI Working Groupは現時点で、Public clientを同等の水準で保護できる仕組みを把握していない。そのため、本書の対象範囲には含めない。

本書を用いて一からauthorization serversやクライアントを実装することも可能ではあるが、実装者は「ゼロからの実装」ではなく、既存のOpenID Connectおよび／またはOAuth 2.0実装の上に構築することが推奨される。実装の完全性と正確性を確保するための追加の考慮事項についてはSection 6.6を参照。

5.1.2. Profiling this document

本書は、所定のattacker modelを満たすことが形式解析により証明された、OAuth 2.0の汎用高セキュリティプロファイルである。

本書および基礎となる仕様は、実装者・展開者・エコシステムに対して複数の選択肢を残している。具体的なユースケースを把握したうえで選択肢をさらに絞ることで、セキュリティが改善する場合があり、また実装や相互運用が容易になる場合もある。

ただし、本書に準拠したプロファイルとするためには、必須の挙動を削除または上書きしてはならない。そうした変更は、形式的セキュリティ解析を無効化し、予測しにくい形でセキュリティを低下させる可能性が高い。

5.2. Network layer protections

5.2.1. Requirements for all endpoints

ネットワーク攻撃に対する防御のため、clients、authorization servers、およびresource serversは次を満たさなければならない。

  • TLSで保護されたendpointsのみを提供し、他サーバへの接続もTLSを用いて確立すること
  • TLS version 1.2以降を用いてTLS接続を確立すること
  • [BCP195] における「Secure Use of Transport Layer Security」の推奨に従うこと
  • DNS spoofing攻撃（不正なdomain-validated TLS certificatesの発行につながり得る）への対策としてDNSSECを使用すべきである
  • [RFC9525] に従ってTLS server certificate checkを実施すること

NOTE 1: endpointがorganization validated（OV）またはextended validation（EV）のTLS certificatesのみを用いていても、攻撃者が不正なdomain-validated certificatesを用いれば、そのendpointになりすましてman-in-the-middle攻撃を実行できる。CAA records [RFC8659] はこのリスクの軽減に役立つ。

5.2.2. Requirements for endpoints not used by web browsers

web browsersで利用されないserver-to-server communication endpointsについては、次の要件を適用する。

  • TLS 1.2を使用する場合、serversは[BCP195]で推奨されるcipher suitesのみを許可しなければならない
  • TLS 1.2を使用する場合、clientsは[BCP195]で推奨されるcipher suitesのみを許可すべきである
5.2.2.1. MTLS ecosystems

エコシステムによっては、機微なデータを送信する必要があるすべてのserver-to-server endpointsに対し、トランスポート層で追加のセキュリティ制御としてMTLSを実装することがある。例えば、MTLS接続と併用してクライアント認証にprivate_key_jwtを用いることができる。相互運用性を確保するため、次を満たすべきである。

  • MTLS ecosystemsは、certificate authoritiesのtrust listを提供すべきである
  • authorization server実装は、[RFC8705] のSection 5で記述されるmtls_endpoint_aliases authorization server metadataを利用し、MTLSとnon-MTLSの両方のendpointsを持ち得るendpointsのdiscovery機構を提供してよい
  • クライアント実装は、endpoint通信において、存在する場合はclient metadata use_mtls_endpoint_aliases（Section 5.2.2.1.1参照）を使用しなければならない
5.2.2.1.1. Client Metadata

Dynamic Client Registration Protocol [RFC7591] は、OAuth 2.0 client metadataをauthorization serversへ動的に登録するためのAPIを定義する。[RFC7591] で定義されるmetadataおよびそれに登録された拡張は、動的登録プロトコルを用いない場合であっても、authorization server実装に有用な、クライアントに関する一般的なデータモデルを示唆する。これらの実装では通常、クライアント設定を管理するための何らかのユーザーインターフェースが提供される。

本仕様は、次のclient metadata parameterを導入する。

  • use_mtls_endpoint_aliases:\ OPTIONAL。Boolean値。Mutual-TLS endpoint aliases [RFC8705] を、Mutual-TLS Client Authentication and Certificate-Bound Access Tokensのユースケースを超えても、authorization serverがmetadataで宣言する場合にクライアントが使用することを要求するかどうかを示す。省略された場合、デフォルト値はfalseである。

5.2.3. Requirements for endpoints used by web browsers

web browsersで使用されるendpointsには、次の追加要件を適用する。

  • Serversは、TLS stripping attacksにより接続がダウングレードできないことを保証する方法を使用しなければならない。\ この目的には、preloaded [preload] のHTTP Strict Transport Security policy [RFC6797] を用いることができる。.bankや.insuranceのような一部のトップレベルドメインはそのようなポリシーを設定しており、その配下のすべてのセカンドレベルドメインを保護している。
  • TLS 1.2を使用する場合、serversは[BCP195]で許可されるcipher suitesのみを使用しなければならない。
  • Serversはauthorization endpointに対してCORS [CORS.Protocol] をサポートしてはならない。クライアントはこのendpointへ直接アクセスするのではなく、HTTP redirectを行わなければならないためである。

NOTE 1: TLS1.2を使用する場合、web browsersで使用されるendpointsは[BCP195]で許可される任意のcipher suiteを使用できる一方、web browsersで使用されないendpointsは[BCP195]で推奨されるcipher suitesのみを使用できる。

NOTE 2: [BCP195] の新しい版はIETFにより定期的に公開される。少なくとも、実装者は新たに公開された版のBCP195に、12か月以内（またはそれより早く）準拠することが求められる。

5.3. Profile

5.3.1. General

以下では、次の技術に対するプロファイルを定義する。

  • OAuth 2.0 Authorization Framework [RFC6749]
  • OAuth 2.0 Bearer Tokens [RFC6750]
  • Proof Key for Code Exchange by OAuth Public Clients (PKCE) [RFC7636]
  • OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (MTLS) [RFC8705]
  • OAuth 2.0 Demonstrating Proof of Possession (DPoP) [RFC9449]
  • OAuth 2.0 Pushed Authorization Requests (PAR) [RFC9126]
  • OAuth 2.0 Authorization Server Metadata [RFC8414]
  • OAuth 2.0 Authorization Server Issuer Identification [RFC9207]
  • OpenID Connect Core 1.0 incorporating errata set 1 [OIDC]

5.3.2. Requirements for authorization servers

5.3.2.1. General requirements

Authorization serversは次を満たさなければならない。

  • [OIDD] および [RFC8414] で規定されるmetadata documentを通じて、discovery metadata（authorization endpointなど）を配布すること
  • resource owner password credentials grantを用いるリクエストを拒否すること
  • [RFC6749] で定義されるconfidential clientsのみをサポートすること
  • sender-constrained access tokensのみを発行すること
  • sender-constrained access tokensに、次のいずれかの方法を用いること
    • MTLS（[RFC8705]）
    • DPoP（[RFC9449]）
  • クライアント認証に、次のいずれかの方法を用いること
    • MTLS（[RFC8705] のSection 2）
    • private_key_jwt（[OIDC] のSection 9）
  • open redirectorsを公開してはならない（[I-D.ietf-oauth-security-topics] のSection 4.11参照）
  • クライアント認証アサーションで受信するaud claimについて、（[RFC8414]で定義される）issuer identifier valueとして、自身の値のみを文字列として受理しなければならない
  • 極めて例外的な状況を除きrefresh token rotationを使用してはならない（下記NOTE 1参照）
  • DPoPを使用する場合、server provided nonce mechanism（[RFC9449] のSection 8）を使用してよい
  • authorization codesを最大60秒の有効期限で発行しなければならない
  • DPoPを使用する場合、"Authorization Code Binding to DPoP Key"（[RFC9449] のSection 10.1で要求）をサポートしなければならない
  • 時計のずれに対応するため、iatまたはnbfが未来（0〜10秒）を指すJWTsを受理しなければならない一方、iatまたはnbfが未来（60秒超）を指すJWTsは拒否しなければならない（NOTE 3参照）
  • access tokenに紐づく権限を、対象アプリケーション／ユースケースで必要最小限に制限すべきである

NOTE 1: confidential clientsとsender-constrained access tokensの組み合わせでは、refresh token rotationの使用はセキュリティ上の利点を提供しない。本仕様は、クライアントが新しいrefresh tokenの保存に失敗する、または受信に失敗するたびにユーザー体験の低下や運用上の問題が発生し、かつリトライ手段がないため、セキュリティ上の理由でrefresh token rotationの使用を禁止する。

ただし、インフラ移行などの例外的事情によりrefresh token rotationが必要になる場合があるため、本仕様は、失敗時に古いrefresh tokenで一定期間リトライできる選択肢をauthorization serversがクライアントへ提供することを条件に、これを許容する。実装者は、新しいrefresh token発行後にそれを失った場合にクライアントが復旧するための安全な仕組みを検討する必要がある。この仕組みの詳細は本仕様の対象外である。

NOTE 2: 本書は、上記の一般要件と併用できるさまざまなgrantをサポートする構造になっている。例えばclient credentials grantやCIBA grant [CIBA] などである。実装者は、執筆時点ではauthorization code flowとCIBA flowsのみが詳細なセキュリティ解析 [FAPI2SEC] を経ている点に留意すべきである。

NOTE 3: clock skewは相互運用上の問題の多くの原因である。数百ミリ秒程度のずれであっても、JWTsが「未来に発行された」として拒否されることがある。DPoP仕様 [RFC9449] は、JWTsを合理的に近い未来（秒〜分のオーダー）まで受理することを示唆している。本書はさらに踏み込み、authorization serversが未来最大10秒までのtimestampを持つJWTsを受理することを要求する。10秒は、セキュリティへ影響を与えずに相互運用性を大きく改善する値として選定された。実装者は未来最大60秒までのtimestampを持つJWTsを受理してよい。エコシステムによってはclock skew問題を完全に解消するために30秒が必要だと分かっている例もある。実装がiatおよびnbfの検査を完全に無効化してしまうことを防ぐため、本書は未来の最大timestampを60秒に制限する。

5.3.2.2. Authorization endpoint flows

authorization endpointを用いるflowsについて、authorization serversは次を満たさなければならない。

  • response_typeの値としてcodeを要求すること（[RFC6749]）
  • クライアント認証付きのpushed authorization requestsをサポートすること（[RFC9126]）
  • [RFC9126] を用いずに送信されたauthorization requestsを拒否すること
  • クライアント認証のないpushed authorization requestsを拒否すること
  • code challenge methodとしてS256のPKCEを要求すること（[RFC7636]）
  • pushed authorization requestsにおいてredirect_uri parameterを要求すること
  • authorization responseにiss parameterを返すこと（[RFC9207]）
  • 暗号化されていない接続でauthorization responsesを送信してはならない。そのため、native clientsがloopback interface Redirection（[RFC8252] のSection 7.3）を使用する場合を除き、"http" schemeのredirect URIsを許可してはならない
  • 以前に使用されたauthorization codeを拒否すること（[RFC6749] Section 1.3.1）
  • user credentialsを含むリクエストをredirectする際、HTTP 307 status codeを使用してはならない（[I-D.ietf-oauth-security-topics] Section 4.12参照）
  • status codesでuser agentをredirectする際、HTTP 303 status codeを使用すべきである
  • pushed authorization requestsのrequest_uriは、expires_inが600秒未満となる値で発行しなければならない
  • end-usersが同意判断できるよう、クライアント識別とauthorizationのscopeなど必要情報を提供すべきである
  • [OIDC] をサポートする場合、nonce parameter valuesは最大64文字をサポートし、64文字超は拒否してよい

NOTE 1: authorization codeのリプレイ識別ができない場合、authorization codeの有効期間を1分または適切に短い期間に設定することが望ましい。有効期間は、（使用している場合の）authorization code cacheをいつクリアするかを示すキャッシュ制御の指標として機能し得る。

NOTE 2: request_uriのexpires_in時間は、ユーザーの端末がリンクを受信し、ユーザーがリンクを開く手続きを完了できるだけ十分でなければならない。多くの場合（ネットワーク接続が不安定、またはユーザーが使用するブラウザを手動選択する必要がある場合など）、30秒を超えることは容易に起こり得る。

NOTE 3: request_uri valuesのワンタイム使用を強制するauthorization serversでは、その強制が、authorizationページの読み込み時点ではなく、authorization時点で行われることが推奨される。これにより、URLを事前読み込みするユーザーソフトウェアによってrequest_uriが無効化されることを防ぐ。

NOTE 4: 本書ではstate parameterをCSRF保護の目的では使用しないが、クライアントがアプリケーション状態のために使用してよい。クライアントがアプリケーション状態をJWTに符号化する状況では、state parameter valueの長さが1000文字を超える可能性がある。

NOTE 5: scope parameterが、クライアントが取得したいauthorizationを表現するのに十分でない場合、OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] の使用が推奨される。

5.3.2.3. Returning authenticated user's identifier

token responseで認証済みユーザーの識別子をクライアントへ提供したい場合、authorization serverはOpenID Connect [OIDC] をサポートしなければならない。

5.3.3. Requirements for clients

5.3.3.1. General requirements

Clientsは次を満たさなければならない。

  • sender-constrained access tokensを、次の方法の一方または両方でサポートすること
    • MTLS（[RFC8705]）
    • DPoP（[RFC9449]）
  • クライアント認証を、次の方法の一方または両方でサポートすること
    • MTLS（[RFC8705] Section 2）
    • private_key_jwt（[OIDC] Section 9）
  • HTTP headerでaccess tokensを送信すること（OAuth 2.0 Bearer Token Usage [RFC6750] Section 2.1 または DPoP [RFC9449] Section 7.1）
  • open redirectorsを公開してはならない（[I-D.ietf-oauth-security-topics] Section 4.11参照）
  • private_key_jwtを使用する場合、クライアント認証アサーションのaud claimにauthorization serverのissuer identifier value（[RFC8414]）を使用しなければならない（配列要素ではなく文字列）
  • refresh tokensと、そのrotationをサポートしなければならない
  • MTLS client authenticationまたはMTLS sender-constrained access tokensを使用する場合、mtls_endpoint_aliases metadata（[RFC8705]）をサポートしなければならない
  • DPoPを使用する場合、server provided nonce mechanism（[RFC9449] Section 8）をサポートしなければならない
  • metadata document（[OIDD], [RFC8414]）から取得したauthorization server metadataのみを使用しなければならない
  • metadata取得の基点となるissuer URLが、権威ある情報源から、かつ安全なチャネルで得られることを保証しなければならない（攻撃者に改ざんされないこと）
  • issuer URLと、取得したmetadata内のissuer valueが一致することを保証しなければならない
  • end-userの明示的または黙示的な同意がある場合にのみauthorization processを開始し、開始をCSRFから保護しなければならない（flow開始の文脈をend-userが認識できるようにする）
  • 最小権限でauthorizationを要求すべきである

NOTE 1: このプロファイルは、システムクロックが正確ではない可能性のあるユーザー管理端末上のconfidential clientsでも使用され得る。その場合、private_key_jwtのクライアント認証が失敗する可能性がある。そのような状況では、クライアントはクライアント認証アサーション生成時に、サーバから返されるHTTP date headerを用いて自端末の時刻を同期することを検討すべきである。

NOTE 2: authorization serversは"Authorization Code Binding to DPoP Key"（[RFC9449] Section 10.1）をサポートすることが要求されるが、clientsはそれを使用することを要求されない。

5.3.3.2. Authorization code flow

authorization code flowについて、clientsは次を満たさなければならない。

  • authorization code grantを使用すること（[RFC6749]）
  • pushed authorization requestsを使用すること（[RFC9126]）
  • code challenge methodとしてS256のPKCEを使用すること（[RFC7636]）
  • 各authorization requestごとにPKCE challengeを生成し、challengeをクライアントとflow開始時のuser agentに安全に結び付けること
  • mix-up attacksを防ぐため、authorization response内のiss parameterを確認すること（[RFC9207]）
  • authorization endpointへ送信するauthorization request parametersはclient_idとrequest_uriのみに限定すること（その他はpushed authorization request内で送信）
  • [OIDC] を使用する場合、64文字を超えるnonce parameter valuesを使用しないことが望ましい

NOTE 1: nonce parameter valueの長さに対する推奨制限は、相互運用性を助けるためである。

5.3.4. Requirements for resource servers

FAPI 2.0 endpointsは、提出されたaccess tokenに紐づくresource ownerに関する保護情報を返す、OAuth 2.0で保護されたリソースendpointsである。

FAPI endpointsを持つResource serversは次を満たさなければならない。

  • HTTP headerでaccess tokensを受理すること（OAuth 2.0 Bearer Token Usage [RFC6750] Section 2.1 または DPoP [RFC9449] Section 7.1）
  • query parameters内のaccess tokensを受理してはならない（OAuth 2.0 Bearer Token Usage [RFC6750] Section 2.3）
  • access tokensの有効性、完全性、expiration、およびrevocation statusを検証しなければならない
  • access tokenが表すauthorizationが要求されたリソースアクセスに十分であることを検証し、十分でない場合は[RFC6750] Section 3.1のとおりエラーを返さなければならない
  • sender-constrained access tokensをサポートし、検証しなければならない（次の一方または両方）
    • MTLS（[RFC8705]）
    • DPoP（[RFC9449]）

5.4. Cryptography and secrets

5.4.1. General requirements

暗号操作およびsecretには、次の要件を適用する。

Authorization servers、clients、およびresource serversがJWTsを作成または処理する際は次を満たさなければならない。

  • [RFC8725] を順守すること
  • PS256、ES256、またはEdDSA（Ed25519 variantを使用）アルゴリズムを使用すること
  • none algorithmを使用してはならず、また受理してはならない

RSA keysは最小長2048 bitsでなければならない。\ Elliptic curve keysは最小長224 bitsでなければならない。

end-usersが取り扱うことを意図しないcredentials（例: access tokens、refresh tokens、authorization codesなど）は、少なくとも128 bitsのentropyを持つように作成しなければならない。これにより、攻撃者が値を正しく推測できる可能性は計算上無視できるものとなる（[RFC6749] Section 10.10参照）。

Note: 執筆時点では、"EdDSA using the Ed25519 variant" を記述する、登録済みで完全に規定されたalgorithmは存在しない。将来そのようなalgorithmが登録された場合、本プロファイルでも使用が許可される。

5.4.2. JSON Web Key Sets

本プロファイルはprivate_key_jwtの使用をサポートし、さらにOpenID Connectの使用も許可する。これらを使用する場合、clientsおよびauthorization serversは、相手方の鍵でpayloadsを検証する必要がある。authorization serversについて、本プロファイルはpublic keysを配布するためにJWKS URI endpointsの使用を強く推奨する。クライアント側の鍵管理については、本プロファイルは、JWKS URI endpointsの使用、または[RFC7591] と [RFC7592] と組み合わせたjwks parameterの使用を推奨する。

authorization server jwks_uriの定義は[RFC8414]に、client jwks_uriの定義は[RFC7591]に記載されている。

さらに、jwks_uri endpointを提供する任意のserverは次を満たさなければならない。

  • TLS上でのみjwks_uri endpointを提供すること
  • JOSE headersのx5uおよびjkuを使用しないことが望ましい
  • 同一のkidを持つ複数のkeysを含むJWK setを提供しないことが望ましい

5.4.3. Handling Duplicate Key Identifiers

JWK setsは同一のkidを持つ複数のkeysを含むべきではない。ただし、相互運用性を高めるため、同一のkidを持つ複数のkeysが存在する場合、検証者は、特定のJWS messageに対する検証鍵を選択する際に、kty、use、algなど他のJWK attributesも考慮しなければならない。例えば、message signatureの検証にどの鍵を使用するかを選ぶために、次のalgorithmを用いることができる。

  • JOSE header内のkidと一致するkidを持つkeysを見つける
  • 単一のkeyが見つかった場合、そのkeyを使用する
  • 複数のkeysが見つかった場合、検証者はkeysを順に試し、検証対象messageに対応するalg、use、kty、またはcrvが一致するkeyが見つかるまで反復すべきである

5.5. Main differences to FAPI 1.0

Table 1

FAPI 1.0 - Part 2: Advanced FAPI 2.0 Reasons
JAR PAR authorization requestsのintegrity保護および互換性改善
JARM only code in response authorization responseをauthorization codeのみに縮小し、integrity保護の必要性を解消
BCM principles, defences based on particular threats attacker model, security goals, best practices from the OAuth Security BCP 設計指針の明確化、形式解析への適合性
s_hash PKCE stateにより提供されていた保護（特にCSRFに対して）はPKCEにより提供されるようになった; stateのintegrityはPARにより部分的に保護される
pre-registered redirect URIs redirect URIs in PAR クライアント認証とPARがある場合、事前登録は不要
response types code id_token or code response type code フロントチャネルにID Tokenを置かない（プライバシー改善）; nonce/signature checkはクライアントで省略され得るが、PKCEは省略できない（セキュリティ改善）
ID Token as detached signature PKCE ID tokenがdetached signatureとして機能する必要がなくなった
potentially encrypted ID Tokens in the front channel No ID Tokens in the front channel (therefore no encryption required) ID Tokensはバックチャネルでのみ交換されるため暗号化不要
nbf & exp claims in request object request_uri has limited lifetime リクエストの事前生成を防止
x-fapi-* headers Moved to Implementation and Deployment Advice document セキュリティプロファイルの中核には無関係
MTLS for sender-constrained access tokens MTLS or DPoP TLS層との緊密な統合がないため、シナリオによってはDPoPの方が展開が容易になり得る

6. Security considerations

6.1. Access token lifetimes

短命のaccess tokens（refresh tokensとの併用）は、一部の攻撃に対する時間的な攻撃可能範囲を縮小し得る。

refresh tokensを使用すると、クライアントは、鍵が侵害された場合、または良好なセキュリティ衛生の一環として、grantsを失うことなくsender-constraining keysをローテーションできる。

長期間のgrants（例: 日／週）を発行する場合は、短命（例: 分／時間）のaccess tokensとrefresh tokensの組み合わせを検討されたい。

access token lifetimeを短くしすぎると、authorization serverへの負荷および依存度が増し、性能とレジリエンスのトレードオフが生じる。

6.2. DPoP proof replay

タイプA5の攻撃者（[attackermodel]参照）は、DPoP proofsを取得し、それらをreplayできる可能性がある。

また、DPoPはHTTP requestsのbodyや多くのheadersに署名しないため、改変されたリクエストでDPoP proofを再利用できる場合がある。例えば支払いリクエストでは、攻撃者が金額や送金先口座を別のものに指定できる可能性がある。

考えられる緩和策は次のとおりである。

  • Resource serversが短命のDPoP noncesを使用し、リクエストがreplayされ得る時間窓を縮小する。
  • Resource serversがjti headerを用いたreplay防止を実装する（[RFC9449]）。
  • 署名付きresource requestsを使用し、改変されたリクエストのreplayを防止する（FAPI Message Signing [FAPIMessageSigning]）。
  • DPoPではなくMTLS sender-constrainingを検討する。

これらの緩和策には、複雑性、性能、またはスケーラビリティの面でトレードオフがあり得る。タイプA5は強力な攻撃者であり、多くのエコシステムでは緩和策が不要な場合もある。

6.3. Injection of stolen access tokens

[FAPI1SEC] の "Cuckoo's Token Attack" で述べられるように、攻撃者が盗まれたaccess tokensをクライアントへ注入し、[RFC8705] または [RFC9449] によるaccess tokenのsender-constrainingを回避できる状況が存在し得る。

この攻撃の前提条件は、攻撃者が、ターゲットresource server向けのaccess tokensを発行するものとしてクライアントに信頼されているauthorization serverを支配していることである。攻撃者がauthorization serverを支配する方法として、次があり得る。

  • クライアントが信頼する別のauthorization serverのセキュリティを侵害する
  • social engineeringを用いてauthorization serverとして振る舞い、クライアントと信頼関係を確立する
  • クライアントを侵害する

中央集権的なディレクトリ、またはresource server discovery機構があると、攻撃者が、攻撃者支配のauthorization serverから受け取った盗難access tokenを、クライアントが正直なresource serverへ送るよう誘導でき、攻撃はより容易になり得る。

この攻撃の前提条件は多くのエコシステムには当てはまらず、強力な攻撃者を必要とする。前提条件が満たされ得る状況では、緩和策として次が考えられる。

  • clientsがauthorization serverごとに異なるDPoP keysまたはMTLS certificatesを使用する
  • clientsがaccess tokenを取得したissuer identifierをresource serverへ送信し、resource serversがissuer一致を検証するよう要求する（ただし標準化された送信方法はない）
  • refresh tokensと併用した短命のaccess tokensにより攻撃可能時間窓を縮小する

6.4. Authorization request leaks lead to CSRF

タイプA3の攻撃者（[attackermodel]参照）はauthorization requestを傍受し、authorization serverでログインしてauthorization codeを受け取り、その攻撃者のauthorization codeを用いてCSRF攻撃により正直なユーザーを正直なクライアントへredirectできる。結果として、ユーザーは攻撃者のリソースへアクセスしてしまい、session integrityが破壊される。

実務上使われているredirectベースのflowsは、すべて原理的にこの攻撃に影響を受け得る点に留意が必要である。redirectionは、ユーザーのブラウザとクライアント間のセッション、およびユーザーのブラウザとauthorization server間のセッションを、厳密に結び付けることを許さないためである。ただし、この攻撃は、authorization requestsを読み取り、短時間でCSRF攻撃を行える強力な攻撃者を必要とする。

考えられる緩和策は次のとおりである。

  • authorization serverに、request_uriを一度だけ受理させる（request_uriの先取り利用を防ぐ）。
  • クライアントに、authorization endpoint呼び出しごとにauthorization code grant呼び出しを一回だけ行わせる（先行レスポンス送信による攻撃を防ぐ）。
  • authorization codeの有効期限を短くし、CSRF攻撃の時間窓を縮小する。

ユーザーのリクエストを完全にブロックできる攻撃者は、上記の1つ目と2つ目の防御を回避できる。しかし実際には、攻撃者はauthorization requestを読み取れる（例: ログファイルや別のサイドチャネル経由）一方で、リクエスト送信自体を妨害できない場合が多い。被害者のインターネット接続が遅い場合、攻撃者の成功確率は上がり得る。

6.5. Browser-swapping attacks

被害者のブラウザ経由で送られたauthorization responseにアクセスできる攻撃者は、次のようにbrowser-swapping attackを実行できる。

  1. 攻撃者は自分のブラウザと何らかのクライアントを用いて新たなflowを開始する。クライアントはpushed authorization requestをauthorization serverへ送信し、レスポンスでrequest_uriを受け取る。その後、クライアントは攻撃者のブラウザをauthorization serverへredirectする。
  2. 攻撃者はこのredirectionを横取りし、そのURLを被害者へ転送する。例えば、そのURLへのリンクをphishingサイト、メール、またはQR codeに埋め込める。
  3. 被害者は、正当なauthentication/authorizationが必要だと誤認させられる可能性がある。その結果、被害者はauthorization serverで認証し、クライアントへデータアクセスを許可してしまう可能性がある。
  4. 攻撃者は被害者のブラウザ内のauthorization responseを横取りし、自分のブラウザを使ってそれをクライアントへ転送できる。
  5. クライアントは、そのauthorization responseが、取引を開始したのと同じブラウザ（攻撃者のブラウザ）に属していると判断し、authorization codeをaccess tokenへ交換し、あるいはユーザー情報を取得する。
  6. そのクライアントを介して、攻撃者はユーザーのリソースへアクセスできる、またはユーザーとしてログインした状態になる。

現時点で広く展開されている技術では、redirectベースのプロトコルにおいてauthorization responseが攻撃者へ漏えいし得る限り、この攻撃を完全に防ぐ方法はない。したがって、authorization responseの機密性を保つことが重要である。本セキュリティプロファイルの要件は、例えばopen redirectorsを禁止し、redirect_uriを認証済みかつ暗号化されたチャネル（pushed authorization request）で送信することを要求して、redirect_uriが攻撃者により改ざんされないことを保証するなど、この目標を達成するために設計されている。

実装者はシステム設計においてauthorization responseの機密性を極めて重要なものとして扱う必要がある。特に、このセキュリティプロファイルがモバイルアプリケーションなど別文脈で使用される場合は注意が必要である。

6.6. Incomplete or incorrect implementations of the specifications

本書および基礎となるOpenID ConnectおよびOAuth仕様の実装が、完全で正確であることは、セキュリティと相互運用性の利点を最大化するために重要である。

OpenID Foundationは、実装が正しいことを確認するためのツールを提供している。

  • https://openid.net/certification/

OpenID Foundationは、認証済み実装の一覧も維持している。

  • https://openid.net/developers/certified/

本書を使用する展開では、認証済み実装を用いるべきである。

6.7. Client Impersonating Resource Owner

[I-D.ietf-oauth-security-topics] のSection 4.15は、悪意あるクライアントがclient_idに影響を与え、end-userのsubject identifierと取り違えられる可能性を生む攻撃を説明する。この攻撃は、authorization serverがクライアントとend-usersの双方に類似の権限を持つaccess tokensを発行することも前提とする。

このため、authorization serversは、client_idがend-userのsubject identifierと取り違えられ得る形で、クライアントがclient_idに影響を与えることを許可すべきではない。

6.8. Key Compromise

暗号鍵が侵害された場合、その影響を限定することが重要である。これは次により達成できる。

  • Key rotation: 自動化された定期的なkey rotationは推奨される。侵害された鍵が悪用され得る時間窓を縮小できるためである。jwks_uri endpointsは、手作業で誤りやすい調整を行うことなく、当事者が鍵をローテーションできるようにする。
  • Key scope: 単一目的の鍵が推奨される。例えば、署名と暗号化に同じ鍵を使用することは推奨されない。追加の指針は[NIST.SP.800-57pt1r5] のSection 5.2を参照。
  • Stateful credentials: 実装者は、access tokensのようなcredentialsについて、statefulとstatelessのトレードオフを検討することが推奨される。鍵侵害が起きた場合、侵害鍵で署名されたstateless tokensは攻撃者により偽造され得る。このリスクは、すべてのtokensがstatefulであり、中央の権威またはデータベースを通じて各tokenのactive statusを検証できる仕組みがある場合に軽減できる。一方でstateless tokensには重要な利点がある。自分自身に必要情報を全て含むため、サーバ側データベース照会を不要にして性能を向上させ、中央のセッションデータ保存も不要にする。さらに、resource serversがauthorization serverの追加関与なしに直接解析・検証できる。これにより、特にauthorization serverとresource serverが同一場所にない、または同一主体により運用されないシナリオで、スケーラビリティと柔軟性が向上する（[RFC9068] の導入部でも議論される）。
  • Credential linking: 複数のcredentialsが同一authorizationの一部として発行される場合、それらの関係を明示的に確立し記録することが推奨される。これにより、リンクされた集合の一つが侵害された場合に、関連するcredentialsもすべてrevocationできる。

7. Privacy considerations

本書を実装するにあたり、プライバシーの観点で考慮すべき要因は多い。本書はOAuth 2.0およびOpenID Connectのプロファイルであるため、プライバシー考慮事項は本書固有のものではなく、一般にOAuthまたはOpenID Connectに適用される。実装者は、十分なプライバシー影響評価を行い、特定されたリスクを適切に管理することが推奨される。

NOTE 1: この目的のため、実装者は[ISO29100]や[ISO29134]のような文書を参照できる。

OAuthおよびOpenID Connect実装に対するプライバシー上の脅威には次が含まれる。

  • 不適切なプライバシー通知: プライバシー通知（例: policy_urlで提供されるもの）または他手段が不適切または不十分である可能性。
  • 不十分な選択肢: 十分な選択肢のない同意画面の提供は同意を形成しない。
  • データの目的外使用: authorization server、resource server、またはクライアントが、合意された目的に従わずにデータを使用し得る。
  • 収集最小化原則の違反: クライアントが目的達成に絶対必要な量を超えるデータを要求することは、収集最小化原則に反する。
  • resource serverからの未承諾の個人データ: 不適切なresource server実装が要求以上のデータを返す可能性。返されるデータが個人データなら、プライバシー原則違反となり得る。
  • データ最小化原則の違反: 必要以上のデータを処理するあらゆるプロセスは、データ最小化原則に反する。
  • authorization serversによるend-users追跡: authorization serversが、どのend-userのどのデータがどのクライアントに提供されているかを特定できること。
  • クライアントによるend-user追跡: 2つ以上のクライアントがaccess tokensまたはID Tokensを相関させてユーザー追跡を行う可能性。
  • end-usersによるクライアント誤認: authorization serverのauthorization pageでのクライアント表示が紛らわしく、end-userがクライアントを誤認する可能性。
  • end-userがデータ提供を十分理解しないまま付与すること: エコシステムの信頼向上のため、authorization serverがauthorization requestに含まれる内容（例: クライアントに開示されるデータ）を明確にすることがベストプラクティスである。
  • 攻撃者がauthorization request/response内の個人データを観測: authorization requestまたはresponseに個人データが含まれる可能性。法域によっては、セキュリティparametersであっても個人データと見なされる場合がある。本プロファイルはauthorization requestおよびresponseで送信されるデータを必要最小限に減らすことを目的とするが、それでも攻撃者が一部データを観測する可能性はある。
  • authorization serverからのデータ漏えい: authorization serverは一般に個人データを保存する。侵害された場合、データが漏えいまたは改ざんされ得る。
  • resource serversからのデータ漏えい: 一部のresource serversは個人データを保存する。侵害された場合、データが漏えいまたは改ざんされ得る。
  • クライアントからのデータ漏えい: 一部のクライアントは個人データを保存する。侵害された場合、データが漏えいまたは改ざんされ得る。

8. IANA Considerations

8.1. OAuth Dynamic Client Registration Metadata registration

本仕様は、[RFC7591] により設置されたIANA "OAuth Dynamic Client Registration Metadata" registryへの、次のclient metadata定義の登録を要請する。

8.1.1. Registry Contents

  • Client Metadata Name: use_mtls_endpoint_aliases
  • Client Metadata Description: Mutual-TLS Client Authentication and Certificate-Bound Access Tokensのユースケースを超えても、authorization serverがmetadataで宣言するmutual-TLS endpoint aliases [RFC8705] をクライアントが使用することを要求するかどうかを示すBoolean値。
  • Change Controller: OpenID Foundation FAPI Working Group - openid-specs-fapi@lists.openid.net
  • Specification Document(s): 本仕様のSection 5.2.2.1.1

9. Normative References

  • [RFC7636]\ Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, 2015年9月,\ https://www.rfc-editor.org/info/rfc7636.
  • [RFC9126]\ Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, 2021年9月,\ https://www.rfc-editor.org/info/rfc9126.
  • [RFC9449]\ Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, 2023年9月,\ https://www.rfc-editor.org/info/rfc9449.
  • [RFC9700]\ Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, 2025年1月,\ https://www.rfc-editor.org/info/rfc9700.

10. Informative References

  • [FAPI1SEC]\ Fett, D., Hosseyni, P., and R. Kuesters,\ "An Extensive Formal Security Analysis of the OpenID Financial-grade API", 2019年1月31日,\ https://arxiv.org/abs/1901.11520.
  • [RFC7592]\ Richer, J., Ed., Jones, M., Bradley, J., and M. Machulak,\ "OAuth 2.0 Dynamic Client Registration Management Protocol", RFC 7592, DOI 10.17487/RFC7592, 2015年7月,\ https://www.rfc-editor.org/info/rfc7592.
  • [RFC8659]\ Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,\ "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, 2019年11月,\ https://www.rfc-editor.org/info/rfc8659.
  • [RFC8705]\ Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt,\ "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, 2020年2月,\ https://www.rfc-editor.org/info/rfc8705.

Appendix A. Acknowledgements

本書はOpenID FAPI Working Groupにより開発された。

本書の発展に貢献した貴重なフィードバックと寄与に対して、Takahiko Kawasaki、Filip Skokan、Nat Sakimura、Stuart Low、Dima Postnikov、Torsten Lodderstedt、Travis Spencer、Brian Campbell、Ralph Bragg、Łukasz Jaromin、Pedram Hosseyni、Ralf Küsters、Tim Würtele、Edmund Jay、Aaron Parecki、Hideki Ikedaに感謝する。

Appendix B. Notices

Copyright (c) 2025 The OpenID Foundation.

OpenID Foundation（OIDF）は、任意のContributor、developer、implementer、またはその他の関係者に対し、非独占的、ロイヤルティ無償、全世界的な著作権ライセンスを付与する。これにより、(i) 仕様の開発、および(ii) Implementers Draft、Final Specification、ならびにErrata Correctionsを取り込んだFinal Specificationに基づく実装のためにのみ、本Implementers Draft、Final Specification、またはErrata Correctionsを取り込んだFinal Specificationを、複製し、派生物を作成し、配布し、上演し、表示することができる。ただし、OIDFが資料の出所であることを示す帰属表示を行うことを条件とし、その帰属表示はOIDFによる承認を示すものであってはならない。

本仕様で記述される技術は、OpenID Foundationのメンバーおよびその他を含む、さまざまな出所からの貢献により提供された。OpenID Foundationは、その技術が配布可能であることを確保するための措置を講じてきたが、本仕様に記述される技術の実装または使用に関して主張され得る知的財産権その他の権利の有効性または範囲、あるいは当該権利に基づくライセンスが利用可能であるか否かについて、いかなる立場も取らない。また、そのような権利を特定するための独自の努力を行ったことを表明するものでもない。OpenID Foundationおよび本仕様への貢献者は、本仕様に関し、商品性、非侵害、特定目的適合性、権原に関する黙示保証を含むがこれに限られない、明示・黙示その他いかなる保証も行わず（ここに明示的に否認する）、本仕様の実装に伴う一切のリスクはimplementerが負うものとする。OpenID Intellectual Property Rights policy（openid.netに掲載）は、貢献者に対し、他の貢献者およびimplementersに対して一定の特許請求を主張しない旨のpatent promiseを提示することを求めている。OpenIDは、本仕様を実施するために必要となり得る技術をカバーする著作権、特許、特許出願、またはその他の専有的権利が存在する場合、いかなる関係者にもその情報をOpenIDへ提供するよう求める。

Authors' Addresses

Daniel Fett

  • Authlete
  • Email: mail@danielfett.de

Dave Tonge

  • Moneyhub Financial Technology
  • Email: dave@tonge.org

Joseph Heenan

  • Authlete
  • Email: joseph@authlete.com