📑

FAPI（Financial-grade API)を勉強する

に公開
FAPI
tech

はじめに

こんにちは！
オアシステクノロジーズの山本です。

今回の記事は、FAPI（Financial-grade API)について、その内容を整理したいと思いつらつらと書きたいと思います。細かい通信シーケンスや処理内容については各対策を深堀していく際に整理するとして、いったん概要確認から。

目次

  1. FAPI (Financial-grade API) とは？
  2. OAuth 2.0 に存在する代表的な脆弱性
  3. FAPI はどのように脆弱性を解決しているか
  4. PKCE (Proof Key for Code Exchange)
  5. mTLS (Mutual TLS)
  6. DPoP (Demonstration of Proof-of-Possession at the Application Layer)
  7. まとめ

1.FAPI (Financial-grade API) とは？

FAPI (Financial-grade API) は、その名の通り、金融グレードの高いセキュリティを要求されるAPIのための技術仕様です。
主に、オープンバンキング（銀行が持つ顧客データを、顧客の同意の元でサードパーティ企業と連携する仕組み）などで利用されています。

FAPIは、認証・認可の標準技術である OAuth 2.0 と OpenID Connect (OIDC) をベースに、金融取引のような機密性の高い情報を安全にやり取りするために、より厳格なセキュリティ要件を追加したプロファイル（仕様の組み合わせ）です。

基本的なOAuth 2.0の仕組みだけでは防ぎきれない巧妙なサイバー攻撃から、ユーザーの資産やデータを守ることを目的として整備された仕様です。

2. OAuth 2.0 に存在する代表的な脆弱性

  • 認可コード横取り (Authorization Code Interception)

Oauthは認可コードをURLに付与します。
スパイアプリ、悪意のあるブラウザ拡張機能などから、この認可コードが盗まれてしまうというものです。

  • 送信者のなりすまし (Sender Spoofing / CSRF)

本来の正規のユーザーかの確認がないため、ほかの第3者が不正に取得したアクセストークンが使えてしまうというものです。

※認可コードはアクセストークンを取得するためのもので、アクセストークンとは別物です。

認可コードが横取りされ、アクセストークンが不正に取得されるほか、
アクセストークン自体が漏洩した場合、不正に利用されるリスクがあるというのがOauth2.0に存在する代表的な脆弱性となります。

3. FAPI はどのように脆弱性を解決しているか

FAPIではこれらの脆弱性に対して、以下の解決策を定義しています。

  • 認可コード横取りの対策
    　PKCE (Proof Key for Code Exchange)

  • 送信者のなりすましの対策
    　mTLS (Mutual TLS)
    　または
    　DPoP (Demonstration of Proof-of-Possession at the Application Layer)

4. PKCE (Proof Key for Code Exchange)

認可コード横取りの対策はPKCEとなります。

認可コードをリクエストしたクライアントと、そのコードを使ってトークンをリクエストするクライアントが同一であることを暗号学的に証明する仕組みです。これにより、認可コードが横取り、利用されたとしても、アクセストークンの払い出しを行わないようになります。

5. mTLS (Mutual TLS)

PKCEは認可コードの横取りを防ぎますが、発行されたアクセストークン自体の漏洩には対応できません。この問題を根本的に解決するのが、送信者制約付きアクセストークンという考え方です。

mTLS (Mutual TLS) は、通常のTLS（サーバー証明書のみ検証）とは異なり、サーバーとクライアントが互いに証明書を提示して認証を行う仕組みです。このクライアント証明書をアクセストークンに紐付けます。

6. DPoP (Demonstration of Proof-of-Possession at the Application Layer)

mTLSは非常に強力ですが、クライアント証明書の管理・配布がインフラレベルで必要となり、ブラウザベースのSPAなど、証明書を安全に管理できない環境では利用が困難です。

DPoPは、この問題を解決し、アプリケーションレイヤーで同様の送信者制約を実現する仕組みです。

攻撃者がアクセストークンを盗んだとしても、リクエストごとに正しいDPoPプルーフ（＝秘密鍵による署名）ができないため、なりすましを防ぐことができます。

7. まとめ

PKCE、DPoP　について再度深堀していきたい。。。。

Discussion