Skip to content

MS_FAPI

Jump to bottom
nishi_74322014 edited this page Aug 12, 2026 · 1 revision

Financial API (FAPI)

概要

Financial API ---> Financial-grade API と名称が変わった。

  • OpenID Financial API (FAPI) WG において、

    • EU 決済サービス指令（Payment Services Directive／PSD）
    • Open Banking Standard

    を考慮し、ISO/TC 68（Financial services）への提出も視野に入れながら、
    金融 API の標準仕様群の策定作業が進められている。

Part Title 説明
1 Read Only API Security Profile 参照系 API（向けの）セキュリティー要件
2 Read & Write API Security Profile 更新系 API（向けの）セキュリティー要件
3 Open Data API 公開データ API 仕様
4 Protected Data API and Schema - Read only 参照系 API（向けの）仕様
5 Protected Data API and Schema - Read and Write 更新系 API（向けの）仕様

移行メモ（名称変更の含意）: 「Financial API」→「Financial-grade API」
という改称は、単なる言い換えではない。

  • 金融専用ではなく、「金融水準の（＝高セキュリティが要る）API」
    全般に適用できる、という位置づけへ広げたもの。

実際、現在の FAPI は医療・公共・電力など、
高い保証レベルを求める分野で広く参照されている。
日本でも金融庁の「電子決済等代行業者」向けの
API ガイドラインが FAPI を参照している。

目的

セキュアな OAuth プロファイルで保護された REST / JSON データモデルを
開発することにより、金融サービスの具体的な実装ガイドラインを提供する。

勧告を提供する。

下記に関する勧告を提供（チェックリスト）

  • セキュリティ＋プライバシー・プロファイル
  • JSON data schema, REST APIs

以下を可能にする。

銀行・証券口座およびクレジットカード口座を考慮対象とする。

  • アプリケーションが口座を参照
  • アプリケーションが口座を更新
  • 利用者がセキュリティとプライバシー設定をする

背景

金融向けセキュリティ・プロファイルが必要

OAuth 2.0 はフレームワークなので
用途に合わせたセキュリティ・プロファイルが必要。

  • 基本実装で OK
    • ソーシャルアプリにおけるデータ共有
    • 閉回路の産業アプリケーション
  • 金融機関 API のセキュリティ・プロファイル

補足（ここが FAPI を理解する起点）: OAuth 2.0 は
「フレームワーク」であって「プロトコル」ではない。
選択肢が多く、組み合わせ次第で安全にも危険にもなる。

OAuth 2.0（RFC 6749） FAPI
位置づけ フレームワーク（選択肢の集合） プロファイル（選択肢を絞った規定）
response_type 多数から選べる code id_token 等に限定
クライアント認証 client_secret_basic でも可 private_key_jwt or mTLS のみ
署名アルゴリズム 何でも PS256 / ES256 のみ
適合性 判定基準が無い OpenID Foundation の認定試験がある

「何を禁止するか」を決めるのがプロファイルの役割であり、
FAPI の価値の中心はここにある。

金融のIdentity Federation APIの使用例

  1. 口座開設（KYC を含む）
  2. 個人資産管理
  3. 支払い、送金
  4. 融資申し込み
  5. AI によるポートフォリオ管理

様々な団体からの後押し

  • INDUSTRY PUSH: FS-ISAC の定める継続的データ API（Durable Data API）
  • REGULATORY PUSH: EU 決済サービス指令（PSD2）が
    2017年末までに API の可用性を要求。
  • Regulatory Pressures（規制圧力）: Open Banking の段階的リリース
    （読み取り専用 → 完全な読み書きアクセス）

考慮事項

金融機関 API 向けのプロファイルは全てを解決する必要がある。

1 Client・1 Authorization Server

  • 1 Client は、1 Authorization Server とのみ関係を持つ。
    （リダイレクト・エンドポイントを分け、クライアントの論理分割）
  • 個人財務管理ソフトウェア/クライアントの場合、
    • 複数の Authorization Server が必然的に必要。
    • バーチャル・セパレーションを行う。
      Authorization Server 毎に異なる Redirect エンドポイントを設ける。

補足（IdP Mix-Up 攻撃への対策）: この制約は
IdP Mix-Up 攻撃を防ぐためのものである。

複数の Authorization Server を 1 つの redirect_uri で受けると、

  1. 攻撃者が「悪意ある AS」を選ばせる
  2. 攻撃者が正規 AS の認可リクエストにすり替える
  3. Client はどの AS から返ってきたか判別できず、
    正規 AS の code を攻撃者の AS に送ってしまう

という攻撃が成立する。
AS ごとに redirect_uri を分けるか、
ID トークンの iss を検証する（OAuth 2.1では
認可レスポンスに iss を含める RFC 9207 が推奨）ことで防ぐ。

メッセージに関する各種の認証

  • UserAgent（ブラウザなど）を介した通信は、
    UserAgent が TLS 終端になり、保護されない。
  • メッセージは変更される恐れがあり、
    また、メッセージは汚染チェックされずに使われることが多い。
  • このため、FAPI では、メッセージに関する各種の認証を必要としている。
種類 送信者 受信者
認可リクエスト Client Authorization Server
認可レスポンス Authorization Server Client
アクセストークン・リクエスト Client Authorization Server
アクセストークン・レスポンス Authorization Server Client
  • メッセージ自体の認証: 各種パラメタが改ざんされないようにする。
  • メッセージ送信者の認証: Redirect で中継するメッセージの送信元の認証。
  • メッセージ受信者の認証: Redirect で中継するメッセージの受信先の認証。
    特にスマホ端末では以下に注意が必要。
    • Public クライアントによる「Access トークン横取り攻撃」
    • Private-Use URL Scheme 上書きによる「認可コード横取り攻撃」
      （OAuth 2.0 for Native Appsを参照）

補足（「UserAgent が TLS 終端」という指摘の重要性）: SSL/TLSが
守るのは通信路であって、メッセージそのものではない。

Client ──TLS──> [ブラウザ] ──TLS──> Authorization Server
                   ↑
             ここで平文になる

ブラウザ上のマルウェア（MITB: Man in the Browser）や
悪意ある拡張機能は、リダイレクトの中身を読めるし書き換えられる。

だから FAPI は

  • リクエストを JWS で署名する（Request オブジェクト / JAR）
  • レスポンスも署名する（JARM or id_token の s_hash）

というアプリケーション層での署名を要求する。
これが FAPI と通常の OAuth の最大の実装差である。

ユーザーIDと認証の問題

  • 利用者（Resource Owner）の ID の概念がない。
  • ユーザー認証は「範囲外」である。
    → だから FAPI は OpenID Connectを前提とする。

メッセージ機密性の問題

  • UserAgent が TLS 終端であるが、
    アプリケーション層で暗号化されていないため、
    UserAgent 上でメッセージを見ることができる。
  • MITB（Man in the Browser）のマルウェア攻撃は、
    1. UserAgent を監視し、
    2. ログインが成功すると、
    3. UserAgent を乗っ取り、
    4. 情報を改ざんする。

トークンのフィッシング・リプレイ攻撃

  • エンドポイントが変更になったなどの偽メールを流す。
  • 若しくは、不正発行された TLS 証明書と DNS スプーフィングの組み合わせ。

補足（記名式トークンという答え）: リプレイ攻撃への FAPI の答えは
記名式トークン（Sender-Constrained Token / Proof-of-Possession） である。

Bearer トークン 記名式トークン
性質 持っている人が使える（現金） 本人しか使えない（記名式切符）
盗まれたら そのまま使われる 使えない（鍵が無い）
実現方式 － mTLS（RFC 8705）/ DPoP（RFC 9449）

mTLS 方式では、アクセス トークンを
クライアント証明書のハッシュに紐づける。
トークンだけ盗んでも、証明書の秘密鍵が無ければ使えない。

機能

基準

記号 基準 内容
(a) Unique Source Identifier 各種のソース識別子（Resource Owner / Authorization Server / Resource Server）が一意
(b) Protocol + version identifier プロトコル + バージョン + msg 識別子が明確に決められている
(c) Full list of actor/roles 人物/役割の完全なリスト
(d) Message Authentication メッセージ自体の認証による、改ざんされていないメッセージの実現

AS-IS（RFC 6749 の認証への対応状況）

# メッセージ メッセージ送信者の認証 メッセージ受信者の認証 メッセージ自体の認証
1 認可リクエスト Indirect（間接） None（なし） None（なし）
2 認可レスポンス None（なし） None（なし） None（なし）
3 アクセストークン・リクエスト Weak（弱い） Good（良い） Good（良い）
4 アクセストークン・レスポンス Good（良い） Good（良い） Good（良い）

補足（この表が FAPI の存在理由）: 表の 1・2 行目、
つまりブラウザを経由する認可リクエスト／レスポンスが
ほぼ無防備であることが読み取れる。
3・4 行目（Client ⇔ AS の直接通信）は TLS で守られているので問題ない。

FAPI が追加する仕様は、すべてこの 2 行を埋めるためにある。

埋めるもの 使う仕様
認可リクエストの署名 JAR/ PAR（MS_PAR.md）
認可レスポンスの署名 JARM/ id_token の s_hash
クライアント認証の強化 private_key_jwt / mTLS
トークンの記名式化 mTLS（RFC 8705）/ DPoP

Part

Part 内容
Part 1 Read Only API Security Profile
Part 2 Read and Write API Security Profile
Part X Client Initiated Backchannel Authentication Profile
Part 3 Open Data API
Part 4 Protected Data API and Schema - Read only
Part 5 Protected Data API and Schema - Read and Write

補足（最新化：FAPI 2.0 が出ている）: 本ページは FAPI 1.0（Part 1 / Part 2）の
時点の記述である。現在は FAPI 2.0 が策定されている。

FAPI 1.0 FAPI 2.0
構成 Part 1（Read Only）/ Part 2（Read & Write） Security Profile 1 本に統合
フロー code id_token（Hybrid）等 code + PKCE のみ（シンプル化）
認可リクエスト JAR PAR（MS_PAR.md）必須
認可レスポンス s_hash or JARM 不要（PAR + PKCE で担保）
トークン mTLS or OAUTB mTLS or DPoP

FAPI 2.0 は「攻撃者モデルを明示し、必要最小限の対策に絞る」方針で
大幅に簡素化されており、実装しやすくなっている。
新規に FAPI 準拠を目指すなら FAPI 2.0 を見るべきである。

参考

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth, セキュリティ

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally