MS_FAPIPart1 - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

FAPI Part 1 (Read Only API Security Profile)

概要

  • Financial API (FAPI)の「Read Only API 用セキュリティ・プロファイル」
  • 金融データへの読み取り専用アクセスに適した OAuthプロファイル
    • OpenID Connect（OIDC）を使用して顧客（ユーザ）を識別
    • トークンを使用して、エンドポイントから保護データを読取
    • エンドポイントは、JSONデータを提供する REST API

※ ドラフト 4 を参考にして作成。その後、ドラフト 6 を再度完読して加筆・修正。

補足（Part 1 と Part 2 の違い）: 同じ FAPI でも要求水準が大きく違う。

Part 1（Read Only） Part 2（Read & Write）
想定 参照系（残高照会など） 更新系（送金など）
ユーザー認証 LoA 2 LoA 3（多要素）
トークン Bearer（持参人切符） 記名式（mTLS / DPoP）
response_type code code id_token（Hybrid）
認可リクエストの署名 不要 必須（JAR）
認可レスポンスの保護 不要 必須（s_hash / JARM）

「お金が動くかどうか」で要求が跳ね上がるという設計になっている。
参照系に Part 2 を課すのは過剰であり、
更新系に Part 1 では不足、という切り分けである。

要約

フロー

このプロファイルを簡単に説明すると、クライアントごと、以下のようになる。

Confidentialクライアント

  • Authorization Codeを使用して、
  • ＋ Token エンドポイントにクライアント認証が必要（以下の何れかが必要）。

Publicクライアント

OAuth PKCE を使用する。

  • 「ハッシュ関数」には、S256 を使用する。
  • 「アプリケーション間通信」には
    **「Claimed Https Scheme URI Redirection」**を使用する
    （OAuth 2.0 for Native Appsを参照）。

要件

通信

  • SSL/TLS（TLS 1.2 以降）
  • redirect_uri（完全一致）

認証

  • ユーザ: LoA 2
    • パスワードは 1024 以上の組み合わせがあること。
    • ID は公的な証明書を確認して作成する。
  • クライアント: 追加のクライアント認証の実装が必要（何れか）

トークン種類

Bearer Token（持参人切符）（トークンを参照）

補足（Part 1 が Bearer で良い理由）: 記名式トークンは実装負荷が高い。
Part 1 は読み取り専用なので、

  • トークンが漏れても書き換えられない
  • 被害は情報漏洩に限定される

という前提で、Bearer を許容している。
逆に Part 2（更新系）では「盗まれたトークンで送金される」ため、
記名式が必須になる。リスクに応じた要求水準という設計思想が明確である。

役割

Authorization Server

認証・認可

  • LoA 2
  • 認可画面が必要（ここで scope の一覧を表示する）。

クライアント認証

クライアント種別 要否
Confidential Authorization Codeで必要
Public OAuth PKCE (S256) では不要
  • 使用する鍵
    • OIDC の要件に準拠
    • 共通鍵を使用する場合、client_secret の UTF-8 オクテットは
      128 ビット以上が必要。
    • 公開鍵を使用する場合、RSA は 2048 ビット以上、
      Elliptic Curve は 160 ビット以上。

redirect_uri

  • 事前登録が必要
  • 認可リクエストに必須
  • 完全一致が必要
  • https の URI スキーマであること。

codeとtoken

  • code: 未使用であること（≒ 一度だけ有効にする）。
  • token
    • scope のリストを含む
    • 有効時間は一度の利用に十分な、若しくは、非常に短い期間に限定
    • 最小 128 ビットの推測不可能な値
      （構造化アクセストークンを妨げるものではない）

追加の機能

Client

  • Confidential クライアントをサポートする。
  • また、Public クライアントをサポートすべき。

Confidentialクライアント

  • クライアント認証が必要。
  • 暗号要件
    • RSA 暗号: 最小 2048 ビットの RSA 鍵
    • Elliptic Curve 暗号: 最小 160 ビットの楕円曲線キー
    • 対称鍵暗号: クライアントの秘密鍵が 128 ビット以上

Publicクライアント

  • クライアント認証は不要。
  • この代替として、S256 の OAuth PKCE をサポート
    • Authorization Server 毎に redirect_uri を変える
      （対応が一致しない場合は、この認証・認可プロセスを中止する）
    • 必要に応じて PKCE 中で ID トークンを取得する（併用可能）。
    • ただし「アプリケーション間通信」に要件がある。
      • Private-Use URI Scheme Redirection はダメ
      • Loopback Interface Redirection もダメ
      • Claimed Https Scheme URI Redirection のみ利用可
  • OAuth 2.0 for Native Appsのベストプラクティスを遵守する。

補足（Claimed Https Scheme のみ許される理由）: OAuth 2.0 for Native Appsで
述べたとおり、3 方式には安全性の差がある。

方式 弱点 FAPI 1
Private-Use URI Scheme（myapp://） 他アプリが同じスキームを登録できる（上書き攻撃） 不可
Loopback（127.0.0.1） 同一端末の他プロセスが横取りしうる 不可
Claimed Https Scheme OS がドメイン所有を検証する 可

金融水準では「アプリのなりすまし」を許容できないため、
OS がドメイン所有権を検証する方式だけが認められている。

Resource Server

HTTP

  • リクエスト
    • Date ヘッダ（サーバ日付を送信）
    • HTTP GET メソッドの使用をサポート
    • Client ≠ Resource Server の場合、必要に応じて CORSをサポート
  • レスポンス
    • UTF-8 でエンコード
    • Content-Type: application/json; charset=UTF-8
    • x-fapi-interaction-id ヘッダ
      • iss か、金融機関のルーティング番号
      • Request にある場合、Response にも設定。
      • Request にない場合、GUID を生成して設定。
      • この id 値は、ログに出力する。

補足（x-fapi-interaction-id は分散トレースの先取り）: この
ヘッダは、1 つの取引を Client / AS / RS の 3 者のログで
突き合わせるための識別子である。

「どの取引で問題が起きたか」を組織を跨いで追跡できるため、
障害調査と監査で決定的に効く。
現在の W3C Trace Context（traceparent ヘッダ） や
OpenTelemetry の相関 ID と同じ発想であり、
金融 API がこれを早くから必須にしていた点は注目に値する。

Accessトークン

  • 認証ヘッダを使用し、QueryString は使用しない。
  • 期限切れ、失効、スコープ等の検証を行う。
  • OAuth 2.0 Token Introspectionを併用可能。

セキュリティに関する考慮事項

  • Request オブジェクト（JAR）を使用すべき場合、
    Part 2を使用する。
    • メッセージソース認証 / メッセージ整合性保護
    • メッセージの封じ込め（WWW ブラウザ・WWW ログからの漏洩）
  • ISO / IEC 29100 のプライバシー原則に従う。

考察

プロファイル

プロファイルの識別

Dynamic Client Registrationの
メタデータを使用するのでは？と。

  • 公式には以下の様に識別するらしい。
    • AuthZ: Client の Metadata 登録で伝える
    • Client: Client 自身は自身の Profile を解っている

他のプロファイルの抑止

他のプロファイルで同じトークンが発行されるので、
OAuth2 / OIDC 標準の Flow は拒否しないといけない？

  • OpenID Connectのように、
    「scope="* openid *"」などの識別方法が提供されていないため。
  • プロファイルで定義された以外のトークン発行を抑止する。

補足（この論点は FAPI 2.0 で整理された）: 「同じ Authorization Server が
FAPI 準拠のフローと標準の緩いフローを両方受け付けると、
緩い方を通せば保護を迂回できる」というのは的確な指摘である。

FAPI 2.0 では、

  • クライアントごとに適用プロファイルを固定する
  • クライアント メタデータで宣言する（require_pushed_authorization_requests 等）

という形で、サーバー側が強制する設計になっている。
「Client が自主的に守る」のではなく
「サーバーが緩いフローを拒否する」ことが要点である。

参考

関連仕様

Tags: 移行, IT国際標準, 認証基盤, クレームベース認証, OAuth

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

⚠️ **GitHub.com Fallback** ⚠️