FAPI 2.0 解説 - API セキュリティの最新動向解説

Last updated at 2024-05-01Posted at 2024-04-15

はじめに

FAPI とは、安全かつ相互運用可能な API 通信を実現するための標準規格を指しており、とりわけ医療分野・金融業界・電子政府といった高セキュリティが要求される業界において重要な役割を果たしています。OAuth 2.0 と OpenID Connect を基礎に置く FAPI 1.0 に始まり、今日ではその最新版である FAPI 2.0 にまで発展を遂げました。FAPI 2.0 では、最新のプロトコルを採用することでよりセキュアなデータ保護を可能とする一方で、従来よりも更にシンプルな実装が可能となりました。

構成要素

FAPI 2.0 は API セキュリティの向上を目的とし、包括的なフレームワークを導入しました。FAPI 2.0 は、大きく以下の 4 つの要素に分類されます:

Security プロファイル

FAPI 2.0 の中核を成すプロファイルで、"PAR" や "DPoP" といった最新のセキュリティ仕様群を活用しています。このプロファイルは、かつて「Baseline プロファイル」と呼ばれていました。

Message Signing プロファイル

OAuth 2.0 をベースとしたリクエスト・レスポンスに対して、「否認防止 (non-repudiation)」のメカニズムをサポートするためのプロファイルです。このプロファイルは、かつて「Advanced プロファイル」と呼ばれていました。

攻撃者モデル

API セキュリティを実現する上での潜在的リスクとその防止策を詳細に説明しています。

グラントマネジメント

OAuth 2.0 を拡張し、クライアントアプリケーションに付与された権限を管理するための仕組みを定義しています。

FAPI の歴史

FAPI 1.0 Final Version (2021 年 3 月)

FAPI 1.0 に関する詳細については、「実装者による Financial-grade API (FAPI) 解説」が参考になります。

FAPI 2.0 Implementer’s Draft 1 (ID 1)

FAPI 2.0 Baseline Profile (2021 年 7 月)
FAPI 2.0 Attacker Model (2021 年 7 月)
Grant Management for OAuth 2.0 (2021 年 7 月)
FAPI 2.0 Message Signing Profile (2023 年 3 月)

NOTE: 「Advanced プロファイル」は「Message Signing プロファイル」に改名されました。

FAPI 2.0 Implementer’s Draft 2 (ID 2)

FAPI 2.0 Security Profile (2022 年 12 月)
FAPI 2.0 Attacker Model (2022 年 12 月)

NOTE: 「Baseline プロファイル」は「Security プロファイル」に改名されました。

認定プログラム

2024 年 4 月時点で、OpenID Certification プログラムは、OpenID プロバイダーおよびクライアントアプリケーションに向けて、以下の FAPI 2.0 認定プログラムを提供しています。

前提知識

FAPI 2.0 を理解するにあたって、以下の仕様群について目を通しておくことを推奨します。

RFC 6749 — OAuth 2.0 Authorization Framework
RFC 6750 — OAuth 2.0 Authorization Framework: Bearer Token Usage
RFC 7636 — Proof Key for Code Exchange by OAuth Public Clients (PKCE)
RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (MTLS)
RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)
RFC 9126 — OAuth 2.0 Pushed Authorization Requests (PAR)
RFC 8414 — OAuth 2.0 Authorization Server Metadata
RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification
OpenID Connect Core 1.0

また、上記仕様群の理解のために以下の記事が参考になります。

クライアント認証

FAPI 2.0 Security プロファイルにおいては、以下のクライアント認証方式が利用できます。

MTLS を用いたクライアント認証

これは、RFC 8705 のセクション 2 に定義される以下の認証方式を指します。

`tls_client_auth`
この認証方式では、クライアントは TLS ハンドシェイク中に証明書 (X.509 証明書) を提示し、その後認可サーバーはその証明書の検証を行い、Subject Distinguished Name (DN) または Subject Alternative Name (SAN) の値を用いてクライアントを識別します。これにより認可サーバーは、クライアントが有効な証明書を保持していること、また、正当な秘密鍵を保持していることを確認できます。

tls_client_auth

この認証方式では、クライアントは TLS ハンドシェイク中に証明書 (X.509 証明書) を提示し、その後認可サーバーはその証明書の検証を行い、Subject Distinguished Name (DN) または Subject Alternative Name (SAN) の値を用いてクライアントを識別します。これにより認可サーバーは、クライアントが有効な証明書を保持していること、また、正当な秘密鍵を保持していることを確認できます。

`self_signed_tls_client_auth`
この認証方式では、クライアントは自己署名による証明書を用いて認証されます。`tls_client_auth` とは異なり、クライアントの証明書チェーンは検証されませんが、クライアントは認可サーバーに対して証明書を登録しておく必要があります。TLS ハンドシェイク中に提示された証明書が登録されたものに合致した場合に限り、クライアント認証は成功します。

self_signed_tls_client_auth

この認証方式では、クライアントは自己署名による証明書を用いて認証されます。tls_client_auth とは異なり、クライアントの証明書チェーンは検証されませんが、クライアントは認可サーバーに対して証明書を登録しておく必要があります。TLS ハンドシェイク中に提示された証明書が登録されたものに合致した場合に限り、クライアント認証は成功します。

X.509 証明書の詳細については「図解 X.509 証明書」が参考になります。

Private Key Signed JWT を用いたクライアント認証

これは、OIDC Core のセクション 9 に定義される以下の認証方式を指します。

`private_key_jwt`
この認証方式では、クライアントは JSON Web Token (JWT) を生成し、それを秘密鍵で署名します。この JWT は `issuer` や `audience` 等のクレームを含み、クライアントアサーションとして認可サーバーに送信されます。その後認可サーバーは、クライアントの公開鍵を用いて JWT の署名検証を行い、クレーム値の検証処理を行います。

private_key_jwt

この認証方式では、クライアントは JSON Web Token (JWT) を生成し、それを秘密鍵で署名します。この JWT は issuer や audience 等のクレームを含み、クライアントアサーションとして認可サーバーに送信されます。その後認可サーバーは、クライアントの公開鍵を用いて JWT の署名検証を行い、クレーム値の検証処理を行います。

アクセストークンの送信者制限メカニズム

FAPI 2.0 Security プロファイルを採用する場合、認可サーバーは MTLS または DPoP (OAuth 2.0 Demonstrating Proof-of-Possession) を用いて、アクセストークンの送信者を制限しなければなりません。これはアクセストークンが漏洩した際の不正使用を防止するために必要となります。

MTLS を用いたアクセストークン送信者制限

RFC 8705 のセクション 3 は、MTLS を利用した送信者制限メカニズムを定義しています。概要は以下のようになります。

クライアントはトークンエンドポイントに対してアクセストークンを要求する。
認可サーバーは MTLS 通信を確立する過程で、クライアント証明書を取得する。
認可サーバーは、アクセストークン発行時に、クライアント証明書とアクセストークンの紐付けを行う。
クライアントはリソースサーバーに対して当該アクセストークンとクライアント証明書を送信する。
リソースサーバーは、当該アクセストークンに対して提示されたクライアント証明書が紐づいていることを確認する。

DPoP (RFC 9449: OAuth 2.0 Demonstrating Proof of Possession)

もう一つのアクセストークン送信者制限メカニズムは、DPoP (RFC 9449: OAuth 2.0 Demonstrating Proof of Possession) です。概要としては以下のようになります。

クライアントは DPoP proof JWT と呼ばれる JWT を生成します。この JWT はクライアントの秘密鍵で署名されていなければなりません。
クライアントは DPoP proof JWT を含めてトークンリクエストを送信します。
認可サーバーはクライアントの公開鍵を利用して、受け取った DPoP proof JWT の署名を検証します。
認可サーバーは当該公開鍵の thumbprint を生成したアクセストークンに紐付けます。
認可サーバーはアクセストークンを発行します。
クライアントはリソースサーバーにアクセスする前に、先ほどの秘密鍵を使って新たな DPoP proof JWT を生成します。
クライアントはアクセストークンとその DPoP proof JWT を含めてリソースサーバーにリクエストを送信します。
リソースサーバーは DPoP proof JWT に含まれる公開鍵を利用して、DPoP proof JWT の署名検証を行います。
リソースサーバーはアクセストークンが当該公開鍵に紐づいていることを確認します。これにより、「リソースサーバーにアクセスしてきたクライアント」が「アクセストークンを発行したクライアント」であることを確認できます。

DPoP に関する詳細ついては、「図解 DPoP (OAuth アクセストークンのセキュリティ向上策の一つ)」が詳しいです。

認可コードと DPoP キーの紐付け

RFC 9449 は、認可リクエストパラメーターの一つとして dpop_jkt を定義しています。本パラメーターを利用することで、認可コードに対してクライアントの公開鍵 (の thumbprint) の紐付けが可能となり、結果として認可コードの所有者証明が可能となります。本メカニズムを利用することで、認可フロー全体を通じた end-to-end のバインディングが可能となります。以下はその概要です。

クライアントは公開鍵の thumbprint を計算します。
クライアントは thumbprint の値を dpop_jkt としてリクエストに含め、認可リクエストを行います。
認可サーバーは dpop_jkt の値を認可コードに含めます。
認可サーバーは認可コードを発行します。
クライアントは自身の秘密鍵で JWT を署名し、DPoP proof JWT を生成します。
クライアントは DPoP proof JWT を含めてトークンリクエストを送信します。
認可サーバーは、DPoP proof JWT に含まれるクライアントの公開鍵を利用し、DPoP proof JWT の検証を行います。
認可サーバーは DPoP proof JWT に含まれる公開鍵の thumbprint が認可コードと紐づいていることを確認します。
認可サーバーは公開鍵の thumbprint を発行されるアクセストークンに紐付けます。
認可サーバーはアクセストークンを発行します。
クライアントはリソースサーバーにアクセスする前に、先ほどの秘密鍵を使って新たな DPoP proof JWT を生成します。
クライアントはアクセストークンとその DPoP proof JWT を含めてリソースサーバーにリクエストを送信します。
リソースサーバーは DPoP proof JWT に含まれる公開鍵を利用して、DPoP proof JWT の署名検証を行います。
リソースサーバーはアクセストークンが当該公開鍵に紐づいていることを確認します。これにより、「リソースサーバーにアクセスしてきたクライアント」が「アクセストークンを発行したクライアント」であることを確認できます。

DPoP Nonce

DPoP Nonce のメカニズムは DPoP proof JWT の有効性を制限するための仕組みです。これにより、漏洩した DPoP proof JWT が攻撃者に使い続けられてしまうリスクを回避できます。概要は以下の通りです。

クライアントはサーバーに提供された nonce の値を含めた DPoP proof JWT を生成します。
クライアントは DPoP proof JWT を含めてトークンリクエストを送信します。
認可サーバーは DPoP proof JWT の署名検証を行います。
認可サーバーは DPoP proof JWT に含まれる nonce の値がサーバーから提供された値と合致することを確認します。
攻撃者は、何らかの手法でクライアントから DPoP proof JWT を不正に取得します。
攻撃者は取得した DPoP proof JWT を含めて認可サーバーにリクエストを送信します。
認可サーバーは DPoP proof JWT の署名を検証します。
認可サーバーは DPoP proof JWT に含まれる nonce 値の有効性を (有効期限、使用回数等をチェックして) 検証します。もしそれが無効と認められた場合、そのリクエストは拒否されます。

Security プロファイル

以下のセクションでは、FAPI 2.0 Security プロファイル (ID2) を詳細に解説していきます。

イントロダクション

「5.1. Introduction」にあるように、FAPI 2.0 Security プロファイルは OAuth 2.0 (RFC 6749) に基づいており、Attacker Model に詳述されるセキュリティ要件を満足するように策定されたものです。本プロファイルは FAPI 2.0 のベースとなる仕様であり、関連する (し得る)仕様群として以下のものが挙げられます。

ネットワークレイヤーの保護

「5.2. Network Layer Protections」はネットワークレイヤーの保護について言及しており、その概要は以下の通りです。

5.2.1. 全エンドポイントに対する要件

全てのエンドポイントは、ネットワーク攻撃への対抗策として、TLS 1.2 以降が必須となります。TLS 1.2 を使用する場合は、RFC 7525 の「Secure Use of Transport Layer Security」の推奨事項に従うものとします。
DNS スプーフィングは、DV (ドメイン認証) TLS 証明書の不正発行につながる可能性があるため、DNSSEC を使用すべきです。
RFC 6125 に従い、TLS サーバー証明書の検証が必須となります。
エンドポイントが OV (実在証明型) または EV (実在証明拡張型) TLS証明書のみを使用していても、不正なDV (ドメイン認証) 証明書を使用したエンドポイントのなりすまし、中間者攻撃 (MiTM 攻撃) は可能です。CAAレコード (RFC 8659) は、これらのリスクを軽減できる有効な手段となります。

5.2.2. Web ブラウザによって使用されないエンドポイントへの要件

TLS 1.2 を利用しており、Web ブラウザによって使用されないエンドポイントについては、以下の要件が挙げられます。

サーバーは以下に列挙された暗号スイートのみを許容しなければなりません
クライアントは以下に列挙された暗号スイートのみを許容すべきです
暗号スイート TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 および TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 については、2048 ビット以上のキー長が必須となります。

TLS 1.2 対して許容される暗号スイートは以下の通りです。

TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

5.2.3. Web ブラウザを使用するエンドポイントの要件

ブラウザが利用するエンドポイントでは、TLS ストリッピング攻撃を防ぐために、RFC 6797 規定される HTTP Strict Transport Security (HSTS) といった対策が必要である。一部のトップレベルドメイン、例えば .bank や .insurance は、HSTS のような対策が有効となっており、それ以下のセカンドレベルドメインもすべて同様に保護されます。
TLS 1.2 が使用されている場合には、RFC 7525 で推奨される暗号スイートのみが許可されます。

認可サーバーの要件

「5.3.1. Requirements for Authorization Servers」は、認可サーバーに対する要件を列挙しています。

全般的な要件

「5.3.1.1. General Requirements」は、認可サーバーに対する全般的な要件を列挙しています。

1. shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OIDD] and [RFC8414]
1. [OIDD] および RFC8414 で指定されているように、メタデータドキュメントを通じてディスカバリーメタデータ (認可エンドポイント等) を公開するものとする

認可サーバーは OpenID Connect Discovery 1.0 incorporating errata set 1 と RFC 8414 に従い、well-known URI (e.g. https://as.example.com/.well-known/openid-configuration) を通じてサーバーメタデータを公開する必要があります。

以下のサーバーメタデータの一例です。

{
  "issuer": "https://as.example.com",
  "authorization_endpoint": "https://as.example.com/authz",
  "token_endpoint": "https://as.example.com/token",
  "token_endpoint_auth_methods_supported": ["client_secret_basic", "private_key_jwt"],
  ...
}

2. shall reject requests using the resource owner password credentials grant or the implicit grant described in [RFC6749] or the hybrid flow as described in [OIDC]
2. RFC6749 に記載されているリソースオーナーパスワードクレデンシャルグラントやインプリシットグラント、または OIDC に記載されているハイブリッドフローを使用しているリクエストは拒否しなければならない

以下のテーブルは、全てのレスポンスタイプと各々が本要件によって許容されるかどうかを示したものです。

none の使用は、本要件によって明示的に否定されていませんが、「5.5. Main Differences to FAPI 1.0」が code の使用を強制しているため、none の使用は間接的に禁止されます。

結論として、FAPI 2.0 Security プロファイルにおいて許容されるレスポンスタイプは code のみとなります。

また本要件は、リソースオーナーパスワードクレデンシャルグラントやインプリシットグラントの使用を禁止していますが、以下のグラントタイプ (grant_type) などの使用は禁止されておりません。

authorization_code (認可コードグラント)
refresh_token (リフレッシュトークンフロー)
client_credentials (クライアントクレデンシャルグラント)
urn:openid:params:grant-type:ciba (CIBA)

3. shall support confidential clients as defined in [RFC6749]
3. [RFC6749] に規定されるコンフィデンシャルクライアントをサポートしなければならない)

認可サーバーは RFC 6749 に規定されるコンフィデンシャルクライアントをサポートしなければなりません。

4. shall only issue sender-constrained access tokens, 5. shall use one of the following methods for sender-constrained access tokens: • MTLS as described in [RFC8705] • DPoP as described in [I-D.ietf-oauth-dpop]
4. 送信者制限されたアクセストークンのみを発行しなければならない、 5. 送信者制限のメカニズムとして、以下のいずれかを利用しなければならない: • [RFC8705] に定義される MTLS • [I-D.ietf-oauth-dpop] に定義される DPoP

認可サーバーは、漏洩したアクセストークンの使用を防止するため、アクセストークンの送信者制限メカニズムとして MTLS (RFC 8705) または DPoP (RFC 9449) を利用しなければなりません。

6. shall authenticate clients using one of the following methods: • MTLS as specified in section 2 of [RFC8705] • private_key_jwt as specified in section 9 of [OIDC]
6. クライアント認証は以下のいずれかを利用しなければならない: • [RFC8705] のセクション 2 に規定される MTLS • [OIDC] のセクション 9 に規定される private_key_jwt

具体的には、以下のクライアント認証方式が許容されます。

tls_client_auth (RFC 8705 のセクション 2.1)
self_signed_tls_client_auth (RFC 8705 のセクション 2.2)
private_key_jwt (OIDC Core のセクション 9)

以下のテーブルは、FAPI 1.0 と FAPI 2.0 のクライアント認証方式における違いをまとめたものです。

詳細は、クライアント認証のセクションを参照してください。

7. shall not expose open redirectors (see section 4.10 of [I-D.ietf-oauth-security-topics])
7. オープンリダイレクトを許容してはならない。 ([I-D.ietf-oauth-security-topics] のセクション 4.10 を参照のこと)

本要件は、「OAuth 2.0 Security Best Current Practice のセクション 4.10」を参照しています。すなわち、認可サーバーとクライアントはオープンリダイレクトを許容してはならないということです。オープンリダイレクトとは、悪意のあるユーザーが正当なウェブサイトを使用して、あるユーザーを別の危険なサイトに誘導する攻撃方法です。この攻撃手段はフィッシング攻撃の手法としてよく利用される方法です。

8. shall accept its issuer identifier value (as defined in [RFC8414]) in the `aud` claim received in client authentication assertions.
8. クライアントアサーションの `aud` クレームとして、 ([RFC8414] に規定されているように) 認可サーバー自身の発行者識別子の値を受け入れなければならない。

認可サーバーが private_key_jwt によりクライアント認証する場合、認可サーバーはクライアントアサーションに含まれる aud クレームとして、自身の発行者識別子 (issuer) の値を受け入れる必要があります。この場合、クライアントアサーションに含まれる aud クレームの値は、認可サーバーの発行者識別子と一致する文字列 (例："https://as.example.com") か、発行者識別子値を含む文字列配列 (例：["https://as.example.com"]) のいずれかとなります。

9. shall not use refresh token rotation unless, in the case a response with a new refresh token is not received and stored by the client, retrying the request (with the previous refresh token) will succeed.
9. リフレッシュトークンのローテーションを使用してはならない。ただし、新しいリフレッシュトークンがクライアントによって受信または保存されなかった場合に、 (以前のリフレッシュトークンを用いた) トークンリフレッシュが成功するメカニズムを認可サーバーが備えている場合、本要件は必須とはならない。

9. shall not use refresh token rotation unless, in the case a response with a new refresh token is not received and stored by the client, retrying the request (with the previous refresh token) will succeed.

9. リフレッシュトークンのローテーションを使用してはならない。ただし、新しいリフレッシュトークンがクライアントによって受信または保存されなかった場合に、 (以前のリフレッシュトークンを用いた) トークンリフレッシュが成功するメカニズムを認可サーバーが備えている場合、本要件は必須とはならない。

認可サーバーがリフレッシュトークンのローテーション (アクセストークンのリフレッシュの度に新しいリフレッシュトークンが発行される仕組み) を採用する場合、それはフォールバックメカニズムを備えて実装されなければなりません。つまり、クライアントが新しいリフレッシュトークンを受け取ることや保存することに失敗した場合、以前のリフレッシュトークンでアクセストークンを再度リフレッシュできるようになっていなければなりません。

10. if using DPoP, may use the server provided nonce mechanism (as defined in section 8 of [I-D.ietf-oauth-dpop]).
10. DPoPを使用する場合、サーバー提供の nonce ([I-D.ietf-oauth-dpop] のセクション 8 にて定義) を使用してもよい。

DPoP が送信者制約アクセストークンメカニズムとして使用される場合、認可サーバーは DPoP nonce メカニズムを採用して、リプレイアタック (攻撃者が有効な DPoP proof を盗み、それを再利用して認可を得る攻撃) 等の攻撃を防ぐことができます。

11. shall issue authorization codes with a maximum lifetime of 60 seconds
11. 認可コードの有効期限は 60 秒以下としなければならない。

認可コードの有効期限は 60 秒を超えてはなりません。

12. if using DPoP, shall support “Authorization Code Binding to DPoP Key” (as required by section 10.1 of [I-D.ietf-oauth-dpop]).
12. DPoPを使用する場合、「Authorization Code Binding to DPoP Key」をサポートしなければならない ([I-D.ietf-oauth-dpop] のセクション 10 によって要求)。

認可サーバーがアクセストークンの送信者制約メカニズムとして DPoP をサポートする場合、「Authorization Code Binding to DPoP Key」をサポートする必要があります。このメカニズムにより、クライアントは認可コードの所有者証明が可能となり、認可プロセス全体を通じて end-to-end のバインディングを実現することができます。

注意：ただし、これはクライアントが「Authorization Code Binding to DPoP Key」を使用しなければならないという意味ではないです。

NOTE: In order to facilitate interoperability the authorization server should also accept its token endpoint URL or the URL of the endpoint at which the assertion was received in the `aud` claim received in client authentication assertions.
注釈: 相互運用性を考慮し、認可サーバーは、クライアント認証時に受け取ったクライアントアサーションに含まれる `aud` クレームの値として、「トークンエンドポイントの URL」または「アサーションが受け取られたエンドポイントの URL」も受け入れるべきである。

上記の通り、クライアントアサーションの aud クレームの値が以下の値である場合も、認可サーバーは許容すべきです。

「トークンエンドポイントの URL」
「アサーションが受け取られた URL」
これらの URL を含む文字列配列

以下の表は、この注釈および項目 8 の要件をまとめたものです。

NOTE: Refresh token rotation is an optional feature defined in [RFC6749] section 6 where the Authorization Server issues a new refresh token to the client as part of the `refresh_token` grant. This specification discourages the use of this feature as it doesn't bring any security benefits for confidential clients, and can cause significant operational issues. However to allow for operational agility, Authorization Servers may implement it providing they meet the requirement in clause 20.
注釈: リフレッシュトークンのローテーションは、RFC6749 のセクション 6 で定義されたオプショナルなメカニズムであり、認可サーバーは refresh_token グラントの一部としてクライアントに新しいリフレッシュトークンを発行します。しかし、このメカニズムはコンフィデンシャルクライアントに対してセキュリティ上のメリットをもたらさないため、本仕様はリフレッシュトークンローテーションの使用を推奨しません。また、本機能の使用は運用上の重大な問題を引き起こす可能性があります。しかし、運用の柔軟性を考慮し、項目 20 に記載された要件を満たす場合に限り認可サーバーはこれを実装することができます。

NOTE: Refresh token rotation is an optional feature defined in [RFC6749] section 6 where the Authorization Server issues a new refresh token to the client as part of the refresh_token grant. This specification discourages the use of this feature as it doesn't bring any security benefits for confidential clients, and can cause significant operational issues. However to allow for operational agility, Authorization Servers may implement it providing they meet the requirement in clause 20.

注釈: リフレッシュトークンのローテーションは、RFC6749 のセクション 6 で定義されたオプショナルなメカニズムであり、認可サーバーは refresh_token グラントの一部としてクライアントに新しいリフレッシュトークンを発行します。しかし、このメカニズムはコンフィデンシャルクライアントに対してセキュリティ上のメリットをもたらさないため、本仕様はリフレッシュトークンローテーションの使用を推奨しません。また、本機能の使用は運用上の重大な問題を引き起こす可能性があります。しかし、運用の柔軟性を考慮し、項目 20 に記載された要件を満たす場合に限り認可サーバーはこれを実装することができます。

FAPI 2.0 Security プロファイルは、「リフレッシュトークンのローテーション」の使用を推奨しません。これはコンフィデンシャルクライアントには不要と考えられ、運用上問題を引き起こす可能性があるからです。ただし、項目 9 で説明されているフォールバックメカニズムを使用する場合に限り、認可サーバーはこれを実装することができます。 (上記の注釈では最後に「項目 20」と記載されていますが、これは誤りで「項目 9」が正しいです)

NOTE: Other grants as appropriate may be supported, for example the client credentials grant, the Client Initiated Backchannel Authentication grant, etc.
注釈: 適切であれば、他のグラントもサポートすることができます。例えば、クライアントクレデンシャルグラント、CIBA (Client Initiated Backchannel Authentication) グラントなどです。

認可サーバーは、項目 2 で禁止されたグラントに含まれないグラント (例えば CIBA グラントなど) をサポートすることができます。

認可コードフローの要件

次に、「5.3.1.2. Authorization Code Flow」に記載されている認可サーバーの要件について説明します。

1. shall support the authorization code grant (`response_type=code` & `grant_type=authorization_code`) described in [RFC6749]
1. [RFC6749]で説明されている認可コードグラント (`response_type=code` & `grant_type=authorization_code`) をサポートしなければならない。

認可サーバーは RFC 6749 で定義される認可コードグラントをサポートしなければなりません。

2. shall support client-authenticated pushed authorization requests according to [RFC9126]
2. [RFC9126] に従って、クライアント認証される pushed 認可リクエストをサポートしなければならない。

認可サーバーは「RFC 9126, OAuth 2.0 Pushed Authorization Requests」 (PAR)をサポートし、pushed 認可リクエストエンドポイントで、指定されたクライアント認証方式を用いてクライアント認証を行う必要があります。

PAR についての詳細は、「図解 PAR : OAuth 2.0 Pushed Authorization Requests」が参考になります。

3. shall reject authorization requests sent without [RFC9126]
3. RFC9126 を使用せずに送信された認可リクエストを拒否しなければならない

認可サーバーは PAR を使用せずに送信された認可リクエストは拒否しなければなりません。

4. shall reject pushed authorization requests without client authentication
4. クライアント認証なしの pushed 認可リクエストは拒否しなければならない

項目 2 で述べたように、認可サーバーは PARエンドポイントにおいて、項目 6 にリストされたクライアント認証方法のいずれかを使用してクライアントを認証しなければなりません。

5. shall require PKCE [RFC7636] with `S256` as the code challenge method
5. PKCE [RFC7636] を必須とし、 code challenge method は `S256` を使用しなければならない

認可サーバーは RFC 7636, PKCE (Proof of Key for Code Exchange) を使用を必須とし、code_challenge_method パラメータの値として S256 を要求しなければなりません。

6. shall require the `redirect_uri` parameter in pushed authorization requests
6. pushed 認可リクエストに `redirect_uri` パラメータを要求しなければならない

認可サーバーは PAR リクエストに redirect_uri パラメータを含めることを要求しなければなりません。

7. shall return an `iss` parameter in the authorization response according to [RFC9207]
7. 認可応答に `iss` パラメータを RFC9207 に従って、返すべきである

認可サーバーは、RFC 9207 に従い、認可レスポンスに iss パラメータとして自身の発行者識別値を含めなければなりません。これは mix-up アタックを防ぐのに役立ちます。

注釈: 発行者識別値は、クエリやフラグメント成分を含まない「https」スキームのURLでなければならない (e.g. https://as.example.com)。

8. shall not transmit authorization responses over unencrypted network connections, and, to this end, shall not allow redirect URIs that use the “http” scheme except for native clients that use Loopback Interface Redirection as described in [RFC8252], Section 7.3,
8. 暗号化されていないネットワーク接続を介して認可レスポンスを送信しないこと、及びこの目的で http スキームを使用するリダイレクトURIを許可しないこと、ただし [RFC8252] セクション7.3 に記述されたループバックインターフェースリダイレクションを使用するネイティブクライアントについてはこの限りではない

8. shall not transmit authorization responses over unencrypted network connections, and, to this end, shall not allow redirect URIs that use the “http” scheme except for native clients that use Loopback Interface Redirection as described in [RFC8252], Section 7.3,

8. 暗号化されていないネットワーク接続を介して認可レスポンスを送信しないこと、及びこの目的で http スキームを使用するリダイレクトURIを許可しないこと、ただし [RFC8252] セクション7.3 に記述されたループバックインターフェースリダイレクションを使用するネイティブクライアントについてはこの限りではない

リダイレクト URI が http スキームを使用する場合、クライアントはネイティブクライアントでなければならず、リダイレクトURIはループバックリダイレクト URI でなければなりません。ループバックリダイレクト URI は RFC 8252 のセクション7.3 において以下のように定義されています。

注意: ループバックリダイレクト URI の要件として、「リクエスト時に任意のポートを指定できる」というものがあります。これは、クライアントによってはリクエスト時にオペレーティングシステムから利用可能なエフェメラルポートを取得する場合があり、そのようなクライアントを許容するためです。

詳細については、「Loopback Interface Redirection」を参照してください。

9. shall reject an authorization code (section 1.3.1 of [RFC6749]) if it has been previously used
9. 以前に使用された認可コード (RFC6749 のセクション 1.3.1)を拒否しなければならない

認可コードが以前に使用されたことを検出した場合、認可サーバーはその認可リクエストを拒否しなければなりません。

10. shall not use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see section 4.11 of [I-D.ietf-oauth-security-topics]);
10. ユーザーの資格情報を含むリクエストをリダイレクトする際に HTTP 307 ステータスコードを使用しないこと ([I-D.ietf-oauth-security-topics] のセクション 4.11 を参照);

HTTP 307 を使用すると、オリジナルの POST リクエストが新しい場所 (URI) に再度 POST 送信 (リダイレクト) されるため、リダイレクト先が信頼できない場合には機密データが意図しない第三者に漏洩してしまう可能性があります。例えば、ユーザーが https://example.com/login にログインフォームを提出し、サーバーが https://otherdomain.com/process に307 リダイレクトを返した場合、ブラウザは元のログインリクエストを新しい URL に再送し、そのリクエストにはユーザーのクレデンシャル情報 (ID、パスワード等) が含まれます。もし otherdomain.com にクレデンシャル情報を渡すことが想定外である場合や、otherdomain.com の安全性が低い場合には、これは問題となり得ます。

11. should use the HTTP 303 status code when redirecting the user agent using status codes;
11. ユーザーエージェントをリダイレクトする際にHTTP 303ステータスコードを使用すべきである;

HTTP 303 ステータスコードは特に POST または PUT リクエストの後に使用され、クライアントはリダイレクト先に GET リクエストでアクセスすることになります。これにより、ユーザーがページを更新した場合に、オリジナルの POST または PUT リクエストが再送されるのを防げます。例えば、https://example.com/submit にフォームを提出した後、サーバーが 303 ステータスコードと https://example.com/thank-you を指す Location ヘッダーで応答すると、クライアントのブラウザは自動的に thank-you ページへの GET リクエストを発行します。これによって、ページの更新によるフォームデータの再送を防止することができます。

12. shall issue pushed authorization requests `request_uri` with `expires_in` values of less than 600 seconds.
12. pushed 認可リクエストに対して発行される request_uri は expires_in の値が 600 秒未満でなければならない。

PAR エンドポイントによって発行されるリクエスト URI は、リプレイアタック等のセキュリティリスクを軽減するために、有効期限が 600 秒未満でなければなりません。

NOTE: If replay identification of the authorization code is not possible, it is desirable to set the validity period of the authorization code to one minute or a suitable short period of time. The validity period may act as a cache control indicator of when to clear the authorization code cache if one is used
注釈: 認可コードの再利用の検知が難しい場合、認可コードの有効期間を 1 分または適切な短い期間に設定することが望ましい。この有効期間は、「いつ認可コードキャッシュをクリアすべきか」を示すキャッシュコントロール指標として活用できる。

認可コードのリプレイアタックを防止できない場合、その有効期間を 1 分またはその他の短い期間に限定することが推奨されます。この値は、「使用中のキャッシュからいつ認可コードを削除すべきか」を示す指標として利用できます。

NOTE: The `request_uri` `expires_in` time must be sufficient for the user's device to receive the link and the user to complete the process of opening the link. In many cases (poor network connection or where the user has to manually select the browser to be used) this can easily take over 30 seconds.
注釈: `request_uri` の `expires_in` の値は、ユーザーのデバイスがリンクを受信し、リンクを開くまでのプロセスを完了するのに十分な長さでなければなりません。大抵の場合 (ネットワーク接続が悪い、またはユーザーが使用するブラウザーを手動で選択する必要があるなどの理由で)、これには 30 秒以上かかることがよくあります。

NOTE: The request_uri expires_in time must be sufficient for the user's device to receive the link and the user to complete the process of opening the link. In many cases (poor network connection or where the user has to manually select the browser to be used) this can easily take over 30 seconds.

注釈: request_uri の expires_in の値は、ユーザーのデバイスがリンクを受信し、リンクを開くまでのプロセスを完了するのに十分な長さでなければなりません。大抵の場合 (ネットワーク接続が悪い、またはユーザーが使用するブラウザーを手動で選択する必要があるなどの理由で)、これには 30 秒以上かかることがよくあります。

リクエストURIの有効期限は、遅いネットワーク接続やユーザーが手動でブラウザを選択する必要があるなど、潜在的な遅延を考慮して十分な長さでなければなりません。これにより、そのような遅延が 30 秒を超えるケースも補うことができます。

クライアントの要件

「5.3.2. Requirements for Clients」は、クライアントアプリケーションに対する要件を列挙しています。

全般的な要件

本セクションでは、「5.3.2.1. General Requirements」に挙げられるクライアントへの要件を見ていきます。

1. shall support sender-constrained access tokens using one of the following methods: • MTLS as described in [RFC8705] • DPoP as described in [I-D.ietf-oauth-dpop]
1. 以下の方法のいずれかを使用して送信者制約付きアクセストークンをサポートしなければならない: • [RFC8705]の MTLS • [I-D.ietf-oauth-dpop] の説明されているDPoP

この要求についての詳細は、認可サーバーの全般的な要件の項目 5 を参照ください。
以下は DPoP を使用したトークンリクエストの例です。DPoP リクエストヘッダーには DPoP proof JWT が含まれています。

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

grant_type=authorization_code\&client_id={CLIENT_ID}\&code={AUTHORIZATION_CODE}\&redirect_uri={REDIRECT_URI}\...

2. shall support client authentication using one of the following methods: • MTLS as specified in section 2 of [RFC8705] • `private_key_jwt` as specified in section 9 of [OIDC]
2. 以下の方法のいずれかを使用してクライアント認証をサポートしなければならない: • [RFC8705] のセクション 2 で指定された MTLS • [OIDC] のセクション 9 で指定された `private_key_jwt`

具体的には、クライアントは以下の認証方法をサポートする必要があります。

tls_client_auth (RFC 8705 のセクション 2.1)
self_signed_tls_client_auth (RFC 8705 のセクション 2.2)
private_key_jwt (OIDC Core のセクション 9)

3. shall send access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]
3. RFC6750 のセクション 2.1 に記載されている通り、HTTP ヘッダーでアクセストークンを送信しなければならない

クライアントは、RFC 6750 で指定された Bearer トークン形式を使用し、HTTP Authorization リクエストヘッダーにアクセストークンを含めて送信しなければなりません。以下は Authorization ヘッダーでの Bearer トークンの例です。

Authorization: Bearer {Access Token}

4. shall not expose open redirectors (see section 4.10 of [I-D.ietf-oauth-security-topics])
4. オープンリダイレクトを許可しない ([I-D.ietf-oauth-security-topics] のセクション 4.10 参照)

認可サーバーの全般的な要件の項目 7 を参照してください。

5. if using `private_key_jwt`, shall use the Authorization Server's issuer identifier value (as defined in [RFC8414]) in the `aud` claim sent in client authentication assertions. The issuer identifier value shall be sent as a string not as an item in an array.
5. `private_key_jwt`を使用する場合、認可サーバーの発行者識別子の値 (RFC8414 で定義) をクライアントアサーションの `aud` クレームに使用しなければならない。発行者識別子の値は文字列として送るべきで、配列内の要素であってはならない。

クライアントが private_key_jwt によってクライアント認証を行う場合、クライアントアサーションの aud クレームの値は、認可サーバーの発行者識別子 (issuer) を文字列 (例："https://as.example.com") として設定しなければなりません。これは文字列配列内の要素であってはなりません。

6. shall support refresh tokens and their rotation
6. リフレッシュトークン及びそのローテーションをサポートしなければならない

クライアントはリフレッシュトークンフロー (RFC 6749) とそのローテーションをサポートしなければなりません。詳細は、認可サーバーの全般的な要件の項目 9 を参照ください。

7. if using MTLS client authentication or MTLS sender-constrained access tokens, shall support the mtls_endpoint_aliases metadata defined in [RFC8705]
7. MTLS クライアント認証または MTLS によって送信者制限されたアクセストークンを使用する場合、RFC8705 で定義された `mtls_endpoint_aliases` メタデータをサポートしなければならない

MTLS クライアント認証または MTLS によって送信者制限されたアクセストークンが使用される場合、クライアントはサーバーメタデータに定義されたエンドポイントエイリアス (mtls_endpoint_aliases メタデータ) を認知し、利用できなければなりません。これはサーバーの well-known URL 内に定義されています。

8. if using DPoP, shall support the server provided nonce mechanism (as defined in section 8 of [I-D.ietf-oauth-dpop])
8. DPoP を使用する場合、[I-D.ietf-oauth-dpop] のセクション 8 で定義される、「サーバーによって提供される nonce」のメカニズムをサポートしなければならない

クライアントがアクセストークンの送信者制約メカニズムとしてDPoPを使用する場合、DPoP nonce のメカニズムをサポートしなければなりません。

9. shall only use authorization server metadata (such as the authorization endpoint) retrieved from the metadata document as specified in [OIDD] and [RFC8414]
9. 認可サーバーのメタデータ (例えば認可エンドポイント) は、[OIDD] および [RFC8414] で指定されたメタデータドキュメントから取得したもののみを使用しなければならない

クライアントが利用できる認可サーバーのメタデータは、認可サーバーの well-known URI (e.g. https://as.example.com/.well-known/openid-configuration) から見つかるメタデータに限定されます。well-known URI は、サーバーメタデータを OpenID Connect Discovery 1.0 errata set 1 および RFC 8414 で規定された通りに公開するものです。

10. shall ensure that the issuer URL used as the basis for retrieving the authorization server metadata is obtained from an authoritative source and using a secure channel, such that it cannot be modified by an attacker
10. 認可サーバーのメタデータを取得するためのベースとして使用される発行者 URL は、攻撃者による改竄を防止するため、信頼できる情報源から安全なチャネルを通じて取得されなければならない

認可サーバーの発行者 URL (例：https://as.example.com) は、正当な URL でなければならず、かつその情報源は信頼性があるものでなければなりません。また、発行者 URL は HTTPS のような安全なチャネルを通じて取得されなければなりません。

11. shall ensure that this issuer URL and the `issuer` value in the obtained metadata match
11. 取得したメタデータの `issuer` 値とこの発行者 URL が一致することを確認しなければならない

クライアントは、認可サーバーのメタデータに規定される issuer 値と、認可サーバーの発行者 URL が一致することを確認しなければなりません。

NOTE: This profile may be used by Confidential Clients on a user-controlled device where the system clock may not be accurate, this may cause `private_key_jwt` client authentication to fail. In such circumstances a Client should consider using the HTTP Date header returned from the server to synchronise it's own clock when generating client assertions.
注釈: このプロファイルは、システムクロックが正確ではないかも知れないデバイス上のコンフィデンシャルクライアントによって使用される場合があり、これが原因で `private_key_jwt` によるクライアント認証は失敗するかも知れません。そのような場合、クライアントは、アサーションの生成時に、サーバーから返却された HTTP Date ヘッダーの値を使用して、自身のクロックを同期させることを考慮すべきです。

NOTE: This profile may be used by Confidential Clients on a user-controlled device where the system clock may not be accurate, this may cause private_key_jwt client authentication to fail. In such circumstances a Client should consider using the HTTP Date header returned from the server to synchronise it's own clock when generating client assertions.

注釈: このプロファイルは、システムクロックが正確ではないかも知れないデバイス上のコンフィデンシャルクライアントによって使用される場合があり、これが原因で private_key_jwt によるクライアント認証は失敗するかも知れません。そのような場合、クライアントは、アサーションの生成時に、サーバーから返却された HTTP Date ヘッダーの値を使用して、自身のクロックを同期させることを考慮すべきです。

コンフィデンシャルクライアントの中には、ユーザー制御下のデバイス上に存在するものもあります。そのようなクライアントの場合、システムクロックの不正確さが原因となり private_key_jwt を用いたクライアント認証が失敗する可能性があります。この場合、クライアントはサーバーから返却される HTTP Date ヘッダーを参照して、自身のクロックを同期することが推奨されます。これはクライアントアサーションの exp クレーム等の値を生成する際などに重要となってきます。

NOTE: Although Authorization Servers are required to support “Authorization Code Binding to DPoP Key” (as defined by section 10.1 of [I-D.ietf-oauth-dpop]), clients are not required to use it.
注釈: 認可サーバーは、「Authorization Code Binding to DPoP Key」 ([I-D.ietf-oauth-dpop] のセクション 10.1 にて定義) のサポートが必要ですが、クライアントがそれを使用することは必須ではありません。

認可サーバーの全般的な要件の項目 12 に記載されているように、認可サーバーが DPoP をアクセストークンの送信者制限メカニズムとして使用する場合、「Authorization Code Binding to DPoP Key」のサポートが必要ですが、これは「クライアントが『Authorization Code Binding to DPoP Key』を使用しなければならない」という意味ではありません。

認可コードフローでの要件

このセクションでは、「5.3.2.2 認可コードフロー」に記載されているクライアント要件について説明します。

1. shall use the authorization code grant described in [RFC6749]
1. [RFC6749] で説明されている認可コードグラントを使用しなければならない

クライアントは RFC 6749 で指定された認可コードグラント (response_type=code および grant_type=authorization_code)を使用しなければなりません。

2. shall use pushed authorization requests according to [RFC9126]
2. [RFC9126] に従って pushed 認可リクエストを使用しなければならない

クライアントは PAR (RFC 9126, Pushed Authorization Requests) を使用しなければなりません。 PARについての詳細は、「図解 PAR : OAuth 2.0 Pushed Authorization Requests」が参考になります。

3. shall use PKCE [RFC7636] with `S256` as the code challenge method
3. PKCE [RFC7636] を使用し、code challenge method として `S256` を設定しなければならない

認可コードの漏洩を防ぐために、クライアントは PKCE (RFC 7636) を使用しなければなりません。また、code_challenge_method パラメーターの値は S256 に設定しなければなりません。

4. shall check the `iss` parameter in the authorization response according to [RFC9207] to prevent Mix-Up attacks
4. mix-up アタックを防ぐため、認可レスポンスの `iss` パラメータを [RFC9207] に従ってチェックしなければならない

mix-up アタックは、セキュリティリスクの一種であり、クライアントが正当な認可サーバーではなく、悪意のある認可サーバーに認可コードやアクセストークンなどの機密情報を送信してしまうものです。この攻撃は、クライアントが複数の認可サーバーとやり取りしており、そのうち少なくとも一つの認可サーバーが攻撃者によって乗っ取られている場合に発生します。攻撃者の目的は、クレデンシャルを傍受して保護されたリソースへの不正アクセスを行うことです。「OAuth 2.0 Security Best Current Practice のセクション 4.4.1」も、具体的に攻撃がどのように実行されるかを説明しています。以下はその概略図です。

mix-up アタックを防ぐため、クライアントは認可レスポンスに iss パラメータが含まれており、かつその値が RFC 9207 の通り、認可サーバーの発行者 URL と一致することをチェックしなければなりません。

リソースサーバーの要件

「5.3.3 リソースサーバーの要件」にはリソースサーバーに対する要件が記載されています。一つ一つ確認しましょう。

1. shall accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]
1. OAuth 2.0 Bearer Token Usage [RFC6750] のセクション 2.1 に記載されている通り、HTTP ヘッダーでアクセストークンを受け入れなければならない

RFC 6750 は、Bearer トークン形式を使用して、アクセストークンを HTTP Authorization リクエストヘッダーに含める方法を提示しています。リソースサーバーはこの方式に従ってアクセストークンを受け入れなければなりません。以下は Authorization ヘッダーに含まれる Bearer トークンの例です。

Authorization: Bearer {Access Token}

2. shall not accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750]
2. OAuth 2.0 Bearer Token Usage [RFC6750] のセクション 2.3 で規定されるクエリパラメータで指定されたアクセストークンは受け入れてはならない

RFC6750 のセクション 2.3 では、クエリパラメータにアクセストークンを含める方法が規定されていますが、リソースサーバーはセキュリティ上の理由からそのようなアクセストークンを拒否しなければなりません。

3. shall verify the validity, integrity, expiration and revocation status of access tokens
3. アクセストークンの有効性、完全性、有効期限、および失効状態をチェックしなければならない

これはリソースサーバーがアクセストークンに関して以下を確認する必要があることを意味します：

有効性: アクセストークンが正当な認可サーバーによって発行されたものであることを確認する。
完全性: アクセストークンが転送中に改竄されたり、変更されていないことを確認する。
有効期限: アクセストークンの有効期限が切れていないことを確認する。
失効状態: アクセストークンが有効期限前に失効または無効化されていないかを確認する。

4. shall verify that the authorization represented by the access token is sufficient for the requested resource access and otherwise return errors as in section 3.1 of [RFC6750]
4. アクセストークンに付与された権限が、リクエストされたリソースへのアクセスに対して十分であるかをチェックし、そうでない場合は [RFC6750] のセクション 3.1 に規定されている通りにエラーを返さなければならない

リソースサーバーはアクセストークンのスコープが、「リクエストされたリソースのアクセスに必要なスコープ」を含んでいるのかをチェックしなければなりません。もし不十分な場合、RFC 6750 のセクション 3.1 に指定されている通り、エラーを返さなければなりません。

5. shall support and verify sender-constrained access tokens using one of the following methods: • MTLS as described in [RFC8705] • DPoP as described in [I-D.ietf-oauth-dpop]
5. 以下の方法のいずれかを使用して送信者制限されたアクセストークンをサポートし、検証しなければならない: • [RFC8705] で説明されているMTLS • [I-D.ietf-oauth-dpop] で説明されているDPoP

これに関する詳細は、認可サーバーの全般的な要件の項目 5 を参照ください。

暗号化とシークレット

「5.4 Cryptography and Secrets」のセクションには、暗号操作とシークレットに関する要件が列挙されています。

1. Authorization Servers, Clients, and Resource Servers when creating or processing JWTs shall 1. adhere to [RFC8725]; 2. use `PS256`, `ES256`, or `EdDSA` (using the `Ed25519` subtype) algorithms; and 3. not use or accept the `none` algorithm.
1. JWT を作成または処理する際、認可サーバー・クライアント・リソースサーバーは、 1. [RFC8725] に従うべきである; 2. `PS256`、`ES256`、または `EdDSA` (`Ed25519` サブタイプを使用) アルゴリズムを使用すること; そして 3. `none` アルゴリズムを使用または受け入れを禁止する。

RFC 8725 は、JWT に関するベストプラクティスを解説したものです。概要は以下の通りです。

アルゴリズムの検証: ライブラリは、ユーザーがサポートされているアルゴリズムを選択できるように設計されていなければならず、サポート外のアルゴリズムを使用した暗号操作を禁止しなければなりません。
適切なアルゴリズムの使用: アプリケーションは、そのセキュリティ要件に合致し、現時点で安全とされる暗号アルゴリズムを使用する必要があります。使用するアルゴリズムは、既存のアルゴリズムの脆弱性等により時間と共に変化するため、アプリケーションは柔軟に設計されていなければなりません。
暗号化操作の検証: JWT に関する全ての暗号化操作の結果は検証しなければならず、そのいずれかが失敗した場合はその JWT を拒否しなければなりません。
暗号化のインプットの検証: 暗号化処理のインプットは検証されなければなりません。
鍵のエントロピー: 脆弱な対称鍵を避ける等の理由で、鍵のエントロピーは十分でなければなりません。
UTF-8エンコーディングの使用: JSON 仕様に準拠し、エンコーディングおよびデコーディングに UTF-8 を使用しなければなりません。
issuer と subject の検証: アプリケーションは issuer と subject を検証し、期待値と合致しない場合はその JWT を拒否しなければなりません。
audience の検証: アプリケーションは JWT の audience を検証し、合致しない場合はその JWT を拒否しなければなりません。
暗号化前の圧縮: 情報漏洩を防ぐため、データの暗号化前の圧縮は避けるべきです。
受け取ったクレームに関する注意: アプリケーションは kid やヘッダーの URL などの受け取ったクレームの脆弱性に注意しなければなりません。
JWT の明示的なタイプ: 異なる種類の JWT の混同を防ぐため、typ ヘッダーパラメータの使用が推奨されます。
別個の検証ルール: 同一の発行元が異なる種類の JWT を発行する場合、それらの JWT の誤用を防ぐために、それぞれに対して別個の検証ルールを使用することが推奨されます。

また、クライアントアサーションなどの JWT に対して検証可能な署名を生成するために、安全かつ現代的な署名アルゴリズムーPS256、ES256、 EdDSA (Ed25519 サブタイプを使用)ーを使用することが要求されます。

また、none アルゴリズムの使用は許可されていません。

2. RSA keys shall have a minimum length of 2048 bits. 3. Elliptic curve keys shall have a minimum length of 160 bits.
2. RSAキーは最低 2048 ビットの長さでなければならない。 3. 楕円曲線キーは最低160ビットの長さでなければならない。

RSA キーは 2048 ビット以上の長さでなければなりません。
EC キーは 160 ビット以上の長さでなければなりません。

4. Credentials not intended for handling by End-Users (e.g., access tokens, refresh tokens, authorization codes, etc.) shall be created with at least 128 bits of entropy such that an attacker correctly guessing the value is computationally infeasible. Cf. Section 10.10 of [RFC6749].
4. エンドユーザーによって取り扱われることが想定されていないクレデンシャル (例えば、アクセストークン、リフレッシュトークン、認可コードなど) は、計算困難性を保証するために、少なくとも 128 ビットのエントロピーで作成しなければならない。[RFC6749]のセクション 10.10 参照。

アクセストークンや認可コードなど、エンドユーザーに直接取り扱われない想定のクレデンシャルは、少なくとも 128 ビットのエントロピーを用いて生成されることが推奨されます。これにより、これらの値の計算困難性が保証され、不正なアクセスや攻撃のリスクを回避できます。

エンドポイントの MTLS 保護

「5.5. MTLS Protection of all endpoints」は、TLS を利用して特定のエンドポイント間の相互運用性を高める方法論を概説しています。

Some ecosystems are choosing to require clients accessing their endpoints to supply a TLS client certificate at endpoints that would not otherwise require a TLS client certificate (for example, the PAR endpoint when using private_key_jwt authentication).

This is outside of the scope of both [RFC8705] and the FAPI standards, however in the interests of interoperability this document states that when using TLS as a transport level protection in this manner, authorization servers should expect clients to call the endpoints located in the root of the server metadata, and not those found in mtls_endpoint_aliases.

一部のエコシステムでは、エンドポイントにアクセスする際に TLS クライアント証明書を要求するが、別の文脈ではそれらのエンドポイントは TLS クライアント証明書を要求しないケースがある。 (例えば、private_key_jwt 認証を行う PAR エンドポイントなど)

これは RFC8705 および FAPI の規格の範囲外となるが、相互運用性の向上のため、本ドキュメントでは次の通りとする: このような形で通信レベルを保護することを目的として TLS を使用する場合、認可サーバーはクライアントに対して、「サーバーメタデータの mtls_endpoint_aliases に定義されるエンドポイントを呼び出すこと」を期待するのではなく、「サーバーメタデータのルートレベルで定義されるエンドポイントを呼び出すこと」を期待すべきである。

一部のエコシステムは、特定のエンドポイントへのアクセスに TLS クライアント証明書を要求しますが、特定のケースにおいてそれらのエンドポイントは TLS クライアント証明書を要求しません。 (例: private_key_jwt 認証を要求する PAR エンドポイントなど)。RFC 8705 や FAPI の仕様に含まれる事項ではありませんが、相互運用性を向上させるため TLS をこのように使用する場合、認可サーバーがクライアントに期待すべき動作は「サーバーメタデータの mtls_endpoint_aliases に定義されるエンドポイントを呼び出すこと」ではなく、「サーバーメタデータのルートレベルで定義されたエンドポイントを呼び出すこと」となります。

以下は、mtls_endpoint_aliases を含む認可サーバーのメタデータの例です。

{
  "issuer": "https://as.example.com",
  "authorization_endpoint": "https://as.example.com/authz",
  "token_endpoint": "https://as.example.com/token",
  "introspection_endpoint": "https://as.example.com/introspect",
  "revocation_endpoint": "https://as.example.com/revo",
  "jwks_uri": "https://as.example.com/jwks",
  "token_endpoint_auth_methods_supported": ["tls_client_auth","client_secret_basic"],
  "tls_client_certificate_bound_access_tokens": true,
  ...
  "mtls_endpoint_aliases": {
    "token_endpoint": "https://mtls.example.com/token",
    "revocation_endpoint": "https://mtls.example.com/revo",
    "introspection_endpoint": "https://mtls.example.com/introspect"
  }
}

FAPI 1.0 との主要な違い

「5.5. Main Differences to FAPI 1.0」では、FAPI 1.0 Read/Write (Advanced プロファイル) と FAPI 2.0 の間の主な違いを解説し、セキュリティ・プライバシー・相互運用性の向上を強調しています。FAPI 1.0 についての詳細については、「実装者による Financial-grade API (FAPI) 解説」が参考になります。

セキュリティ考慮事項

「5.5. Main Differences to FAPI 1.0」では、いくつかのセキュリティリスクとそれらの対抗策を解説しています。概要は以下の通りです。

5.7.1. アクセストークンの寿命

リスク: 有効期限の長いトークンは脆弱性が大きい。
対抗策: トークンの有効期限を短くする。また、リフレッシュトークンフローを活用し、所有者証明 (DPoP proof JWT など) をローテーションさせる。

5.7.2. DPoP proof の再利用

リスク: 攻撃者による DPoP proof の再利用。
対抗策: 有効期限が短い DPoP Nonce を使用する。

5.7.3. JWKS URI のリスク

リスク: OAuth および OpenID Connect の鍵管理における潜在的な脆弱性。
対抗策: 公開鍵を配布するための JWKS URI を使用し、jwks_uri エンドポイントを TLS で保護する。JOSE ヘッダーの x5u および jku の使用を避け、JWK セット内で同じ kid を持つ複数の鍵の使用を避ける、等。

5.7.4. 鍵の識別子の重複

リスク: 複数の鍵が同一の識別子 (kid) を共有することによる問題。
対抗策: JWK セットを慎重に管理し、重複する kid を避ける。存在する場合は、alg、use、kty、crv の値が目的の値に合致するものを使用する、等。

5.7.5. 盗まれたアクセストークンの悪用

リスク: 攻撃者が盗んだアクセストークンを悪用する。
対抗策: 認可サーバー毎に異なる DPoP proof JWT または MTLS 証明書を使用する。リソースサーバーはトークンの発行者識別子を検証する、等。

5.7.6. 認可リクエストの漏洩

リスク: 攻撃者が改竄した認可リクエストを使用する CSRF 攻撃。
対抗策: 一度使用したリクエスト URI は無効とする、等。

5.7.7. ブラウザスワップ攻撃

リスク: 攻撃者がブラウザの入れ替えをして、認可レスポンスを傍受する。
対抗策: オープンリダイレトを禁止する。リダイレクト URI が安全なチャネルを通じて取得されたものである確認する。PAR を使用する、等。

プライバシーの考慮

「6. Privacy Considerations」では、プライバシーリスクに対処する重要性を強調しています。概要は以下の通りです。

適切なプライバシー通知を行う。
ユーザーにとって十分な同意メカニズムを設ける。
データの誤用を防ぎ、データ最小化原則に則る。
リソースサーバーから不要な個人データの送信しないようにする。
認可サーバーとクライアントによるエンドユーザーのトラッキングを減らす。
クライアントの詳細とデータアクセス権限をエンドユーザーに対して明確にする。
認可リクエスト・認可レスポンスに含まれる個人データを最小化する。
認可サーバー、リソースサーバー、およびクライアントからの個人データの漏洩を防ぐ。

プライバシー影響評価のために、ISO 29100 や ISO 29134 などの標準を参照することが奨励されています。

最後に

最後に、私が共同創業した Authlete, Inc. が提供する Web API は、FAPI 1.0 および FAPI 2.0 の両者をサポートし、かつ FAPI OpenID Provider Certification Program に認定されております。

ご興味がある場合、こちらのウェブフォームまたは以下のメールアドレスよりお気軽にお問い合わせください。

ライセンスおよび契約: sales@authlete.com
パートナーシップ: bizdev@authlete.com
技術サポート: support@authlete.com

また、下記のチェックも是非よろしくお願い致します。

最後までご拝読いただきありがとうございます。FAPI 2.0 に関する今後のアップデートにご期待ください。

更新情報

2024 年 4 月 16 日: FAPI 2.0 セキュリティプロファイル (ID2) に関する解説を公開。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up