FAPI 2.0は、従来のFAPI 1.0が抱えていた「実装の複雑さ」や「相互運用性」の課題を解消し、よりシンプルかつセキュアに設計された次世代のAPIセキュリティ標準規格です。
昨今、自社のAPIを外部に公開し、他社サービスと連携させることで新たな価値を創出する動きがさまざまな業界で広がっています。その一方で、個人情報や決済情報などの機密データを安全にやり取りするためのAPIセキュリティの担保は、企業にとって重要な課題です。
以前のブログ記事「FAPIとは？｜高度なセキュリティレベルのAPIガイドラインを徹底解説」で解説した「FAPI 1.0」は、世界中のオープンバンキング等で採用されましたが、実装の難易度が高いことが課題でした。
本記事では、最新仕様として公開された「FAPI 2.0」の登場した背景と概要、1.0との具体的な違い、安全性を担保する主要技術について解説します。「高度なセキュリティは担保したいが、実装の複雑さに悩んでいる」という開発者やアーキテクトの方、必見の内容です。
Webアプリケーションやモバイルアプリケーションの普及に伴って、ユーザデータへのアクセスが異なるアプリケーション間で共有される機会が増えてきています。それを受けて、ユーザの認証や認可をセキュアに行うためのオープンスタンダードとしてOAuth 2.0 や OpenID Connectといった認証・認可フレームワークは広く利用されるようになりました。
そのOAuth 2.0 や OpenID Connectをベースに、金融業界等のより高いAPIセキュリティレベルを要求されるシステムへのガイドラインとして、OpenID Foundation の FAPIワーキンググループが策定した技術仕様がFAPIです。FAPIは「FAPI 1.0 Final [1][2]」（以下、本記事では「FAPI 1.0」と記載）が2021年3月に公開され、その後、2025年2月と9月に「FAPI 2.0 Final [3][4][5]」（以下、本記事では「FAPI 2.0」と記載）が公開されました。本記事では、FAPI 2.0に焦点を当ててご説明します。
FAPI 2.0は以下の3つが最終仕様として公開されています。
FAPI 2.0 Security Profile [3] （公開日：2025年2月22日）
FAPI 2.0の基本となるAPIセキュリティプロファイルです。OAuth 2.0やOpenID Connectをベースとし、最新のOAuth Security Best Current Practice（OAuth Security BCP）の推奨事項に従って、金融や医療、政府系サービスなどの高リスク・高価値なAPIを保護するための要件を定義しています。具体的には、送信者制約付きアクセストークン（MTLSやDemonstrating Proof-of-Possession（DPoP））の安全な取得や、リソースサーバでのセキュアな利用プロセスなどが規定されており、後述の「FAPI 2.0 Attacker Model[4]」で定義されたセキュリティ目標を達成するように設計されています。
FAPI 2.0登場の背景としては、FAPI 1.0は、英国のオープンバンキングやブラジルなどで採用され、広く普及しました。しかし、実際に世界中で実装や運用が進むにつれて、いくつかの課題も浮き彫りになりました。例えば、高いセキュリティを担保するために複雑なメッセージ署名（Message Signing）が求められ、開発者にとって実装のハードルが高いという課題がありました。また、仕様内にオプションが多く残されていたため、異なるシステム間での相互運用性（互換性）を確保しづらいケースもありました。 そこで、これらの課題を解決し、より使いやすく安全な仕様へとアップデートするためにFAPI 2.0が登場しました。FAPI 2.0の策定には、主に以下の4つの背景と目的があります。
実装の簡素化
セキュリティレベルを低下させることなく、メッセージ署名の要件などを減らし、開発者がより簡単に実装できるようになりました。
FAPI 2.0は、FAPI 1.0の高度なセキュリティレベルを維持しつつ、開発者にとってよりシンプルで実装しやすく、相互運用性の高い仕様へと進化しました。主な違いは以下の通りです。
FAPI 1.0とFAPI 2.0の比較表
| 観点 | FAPI 1.0（Part 2: Advanced） | FAPI 2.0 | 変更の背景・ポイント |
| プロファイルの構成 | Baseline / Advanced 中程度の固有リスク向け（Baseline）と、より高い固有リスク向け（Advanced）として分類。 |
Security Profile / Message Signing 基本のセキュリティプロファイルと、否認防止を求めるオプションプロファイルに分離。 |
脅威モデルに対応する基本要件（Security Profile）がすでに強力であり、トランザクションの否認防止が必要な場合のみメッセージ署名を追加する形に整理。 |
| 認可リクエストの送信 | JAR必須 / PARはオプション リクエストオブジェクト（JWT）をフロントチャネルで送信（request / request_uri）。改ざん検知に署名を利用。 |
PARの必須化 認可リクエストをバックチャネルで直接送信するPushed Authorization Requests（PAR）が必須。 |
認可リクエストの完全性保護と互換性を向上させるため。PARを必須化することで、認可リクエストのパラメータがブラウザを経由しなくなり機密性も向上。 |
| 認可レスポンスの返却 | ID Token as detached signature または JARM IDトークンによるDetached署名（c_hash, s_hash等を利用）、またはレスポンス全体をJWT化するJARMを利用。 |
response_type=code のみ フロントチャネルでのIDトークン返却を廃止（メッセージ署名時を除きJARMも不要）。 |
フロントチャネルにIDトークンを含めないことによるプライバシー向上。また、クライアント側で省略される恐れのある署名検証などを、省略不可能なProof Key for Code Exchange（PKCE）に置き換えることによるセキュリティ向上のため。さらに、IDトークンがバックチャネルのみで交換されるようになり、暗号化が不要。 |
| 認可リクエスト・レスポンスの紐づけ | state や s_hash の利用 CSRF対策などで利用。 |
PKCEの必須化 S256アルゴリズムを用いたPKCEの利用が必須。 |
state による保護（特にCSRF対策）がPKCEによってカバーされるようになったため。なお、state パラメータ自体の完全性はPARによって部分的に保護される。 |
| トークン要求（クライアント認証と紐づけ） | 送信者制約付きアクセストークン（MTLS） クライアント証明書を用いたMTLSが中心。 |
MTLS または DPoP MTLSに加えて、DPoPも代替手段としてサポート。 |
TLSレイヤーとの密接な統合が不要であり、特定のシナリオにおいてDPoPの方が展開しやすいため、公式な選択肢としてDPoPが追加された。 |
| セキュリティ設計の基盤 | 特定の脅威に基づく防御 BCMの原則に基づく。 |
明確な攻撃者モデルの定義 強力な攻撃者を定義し、形式的な解析を実施。 |
特定の脅威に基づく防御から、明確な攻撃者モデルとセキュリティ目標、OAuth Security BCPのベストプラクティスに基づく形に変更することで、より明確な設計ガイドラインを設け、形式的な解析を行いやすくした。 |
本章では、FAPI 2.0の基盤となる主要な技術要素について解説します。
認可リクエストのパラメータを、ユーザのブラウザ（フロントチャネル）経由ではなく、クライアントと認可サーバ間の直接通信（バックチャネル）で事前に送信する仕組みです。FAPI 2.0ではPARの利用が必須化されており、リクエストパラメータの改ざんや漏洩を防止し、機密性と完全性を保護します。
PKCE利用時のシーケンス図
送信者制約付きアクセストークン（MTLS / DPoP）
発行されたアクセストークンを特定のクライアントに紐づけ、万が一トークンが漏洩しても正当なクライアント以外による悪用を防ぎます。
FAPI 2.0では以下のいずれかの手法の利用が必須とされています。
DPoP利用時のシーケンス図
FAPI 1.0では、既知の特定の脅威に基づく防御アプローチがとられていましたが、複雑なプロトコルにおいては、未知の脅威や既存の脅威の新たな変種が出現する可能性があります。そのためFAPI 2.0では、特定の狭い脅威だけに対処するのではなく、非常に強力な能力を持つ攻撃者のモデルを定義し、それに基づき形式的に解析を実施するアプローチが採用されました。
攻撃者モデルでは、防御のレベルを引き上げるため、以下のような強力な攻撃者が存在し、場合によってはこれらが互いに協力してシステムを狙うことを想定しています。
A1（Web攻撃者）
悪意のあるWebサイトを運営し、一般ユーザにリンクを踏ませて誘導したり、自身の端末のブラウザやプロキシツール等を用いてメッセージを操作・改ざんしたりできる攻撃者。
一方で、以下の行為はできない。
FAPI 2.0は、上記に挙げたような強力な能力を持つ攻撃者が存在する環境下であっても、「権限のないリソースへの不正アクセス」「他ユーザへのなりすましログイン」「不正なセッションの強制（CSRFやセッションスワッピング攻撃）」を確実に防げるように設計・証明されています。この厳密な証明があるからこそ、金融や医療などの重要インフラでも安心して採用できる基準となっています。
ただし、このモデルではシステム基盤自体が正常に動作していることを前提としており、以下の脅威はスコープ外（FAPI 2.0単体では防げない範囲）として明確に切り分けられています。
FAPI 2.0は、FAPI 1.0の高度なセキュリティを維持しながら、「よりシンプルで実装しやすい仕様」と「システム間の完全な相互運用性」を両立させた次世代のAPIセキュリティ規格です。これまで開発者にとって複雑であったメッセージ署名の要件が軽減され、認可リクエストの安全性を高めるPARや認可コード横取りを防ぐPKCEが標準採用されました。また、送信者制約のための技術として「DPoP」が導入された意義も大きく、従来のMTLSの運用が困難な環境においても、トークンの盗用を防止する強固なセキュリティを実現できるようになりました。これにより、堅牢でありながらも格段に扱いやすい仕様へと進化を遂げました。これまで金融業界を中心に普及してきたFAPIですが、実装コストが下がり相互運用性が高まったことで、今後は医療、政府系インフラなど高リスクなデータを扱うあらゆる領域での活用が期待されています 。
高度なセキュリティを維持しながら、ビジネスのスピードを落とさない。FAPI 2.0は、これからのAPIエコシステムにおいて不可欠なガイドラインとなるでしょう。自社サービスのセキュリティレベル向上や、グローバルな標準への準拠を検討されている方は、ぜひこの機会に導入に向けた具体的な検討を進めてみてはいかがでしょうか。
当社には、FAPIをはじめOAuth 2.0/OpenID Connectに精通したスペシャリストが多数在籍しており、要件定義から実装まで幅広くご支援可能です。また、FAPI対応を強力に支援するAPIゲートウェイ「Kong Gateway」などのソリューションも提供しております。APIセキュリティに関する課題がございましたら、ぜひお気軽にご相談ください。
[1]Financial-grade API Security Profile 1.0 - Part 1: Baseline https://openid.net/specs/openid-financial-api-part-1-1_0.html
[2]Financial-grade API Security Profile 1.0 - Part 2: Advanced https://openid.net/specs/openid-financial-api-part-2-1_0.html
[3] FAPI 2.0 Security Profile https://openid.net/specs/fapi-security-profile-2_0-final.html
[4] FAPI 2.0 Attacker Model https://openid.net/specs/fapi-attacker-model-2_0-final.html
[5] FAPI 2.0 Message Signing https://openid.net/specs/fapi-message-signing-2_0-final.html