MS_FAPIPart2 - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

FAPI Part 2 (Read and Write API Security Profile)

概要

  • 金融データへのトランザクション・アクセスに適した OAuth プロファイル
    • OpenID Connect（OIDC）を使用して顧客（ユーザ）を識別
    • トークンを使用して、エンドポイントから保護データを読取
    • エンドポイントは、JSONデータを提供する REST API

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

要約

  • 送信者・受信者・メッセージ認証を強化
  • 以下の攻撃に対するコントロールを規定
    • 認可要求の改ざん
    • コードインジェクション
    • 状態インジェクション
    • トークン要求フィッシング
    • 認可応答の改ざん

フロー

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

クライアント種別 response_type
Confidential code id_token
Public（Native） code id_token（JARM）
Public（SPA） code id_token token（Hybrid Flow）

パラメタ

response_type

  • code id_token

    • Confidential クライアント
    • Native の Public クライアントの場合、S256 の OAuth PKCE

  • code id_token token（SPA 系の Public クライアント）

    • 8.3.3. Identity provider (IdP) mix-up attack の可能性がある。
    • 故に、Implicit Flow より Hybrid Flow

response_mode

JARMであれば Hybrid Flow でなくてもいい。
（OAuth 2.0 Form Post Response Modeも参照）

request or request_uri

補足（なぜ code id_token なのか）: Hybrid Flow の code id_token は
一見冗長だが、認可レスポンスの改ざんを検知するために選ばれている。

  1. 認可レスポンスに id_token（署名済み JWT）が含まれる。
  2. id_token の中に c_hash（code のハッシュ）、
    s_hash（state のハッシュ）が入っている。
  3. Client は署名を検証し、受け取った code / state と突き合わせる。

これにより「ブラウザ上で code をすり替えられた」ことを検知できる。
FAPIが指摘する「メッセージ自体の認証が無い」問題への直接の答えである。

ID トークン

JWT形式

  • JWS署名
    • ES256（ECDSA using P-256 and SHA-256, Recommended+）
    • PS256（RSASSA-PSS using SHA-256 and MGF1 with SHA-256, Optional）
  • JWE暗号化：アルゴリズムの指定は無し。

補足（RS256 が禁止されている）: JWAでは RS256 が
Recommended だが、FAPI では PS256 / ES256 のみに制限される。

方式 FAPI
RS256 RSASSA-PKCS1-v1_5 不可
PS256 RSASSA-PSS（確率的署名） 可
ES256 ECDSA（楕円曲線） 可

PKCS#1 v1.5 は形式的な安全性証明が無く、
パディング関連の実装ミスが歴史的に多い。
PSS は安全性証明があるため、高保証プロファイルではこちらが選ばれる。
ES256 は署名が短く高速という利点もある。

追加クレーム

切り離された署名

認可レスポンスが改ざんされていないことを検証する。

s_hash: クライアントは、at_hash と c_hash に加え、s_hash の値を検証する。

  • 値
    • state 値の ASCII 表現のオクテットのハッシュの左端の半分を
      base64url エンコーディング
    • ハッシュは ID トークンの JOSE ヘッダの alg パラメタで使用されるアルゴリズム。
  • 例：alg が HS512 の場合
    1. state 値を ASCII エンコードし、
    2. SHA-512 でハッシュ化し、
    3. 左端の 256 ビットを切り出し、
    4. base64url エンコードする。

この代替に「JARM」と言う仕様もある。

通信

SSL/TLS

  • TLS バージョン 1.2 以降
  • TLS サーバ証明書チェック
  • 暗号スイート
    • 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

redirect_uri

完全一致

認証

ユーザ

LoA 3（LoA(Level of Assurance)）

  • 特定される身元識別情報の信用度が「相当程度ある」。
  • パスワードだけではなく、2 要素以上を用いてユーザー認証をする。

クライアント認証

  • 認可エンドポイント: Request オブジェクト
  • Token エンドポイント（以下の何れかが必要）
    • JWT Client Assertion（private_key_jwt）
    • 紐付け（トークン・バインディング）
      FAPI クライアントが「mTLS」または「OAUTB」を使用する場合、
      認証コードは TLS チャネルにバインドされる。

補足（client_secret が使えない）: FAPI では
client_secret_basic / client_secret_post（共有秘密による認証）が
禁止されている。使えるのは次の 2 つのみ。

方式 内容
private_key_jwt クライアントが秘密鍵で署名した JWT を提示。AS は公開鍵で検証
tls_client_auth（mTLS） クライアント証明書で TLS 相互認証

共有秘密は「AS 側にも同じ値が保管される」ため、
AS が侵害されるとクライアントになりすませる。
公開鍵方式なら、AS は公開鍵しか持たないので、この問題が無い。

トークン種類

記名式トークン（Proof-of-possession Token）

  • 対象: code、token
  • 紐付け（トークン・バインディング）: mTLS / OAUTB

移行メモ（最新化：OAUTB は終了した）: Token Binding（OAUTB） は
ブラウザ ベンダの支持が得られず、
Chrome が 2018年に実装を撤回して事実上終了した。

現在の記名式トークンの選択肢は次の 2 つである。

方式 RFC 特徴
mTLS RFC 8705 クライアント証明書に紐づける。サーバー間通信向き
DPoP RFC 9449 アプリ層で署名。証明書基盤が不要。SPA / モバイル向き

FAPI 2.0 では mTLS と DPoP の両方が認められている。
証明書の配布・更新の運用負荷を避けたい場合、DPoP が現実的な選択になる。

役割ごとの要件

Authorization Server

  • 認証・認可、クライアント認証、redirect_uri（完全一致）、code / token の扱い

Client

  • 共通要件のほか、Confidential / Public で個別の要件がある。

Resource Server

  • 記名式トークンの検証。

Request オブジェクト

  • 登録リクエスト / 認可リクエストで JARを使用する。
  • 仕様の流れは JAR → PAR（RFC 9126）。

補足（JAR から PAR への流れ）: JAR は「リクエストを署名した JWT に
まとめてブラウザ経由で送る」方式だが、URL 長の制限という実務的な問題があった。

PAR（Pushed Authorization Requests、RFC 9126） は、

  1. Client がバックチャネルで認可リクエストを AS に POST する。
  2. AS が短い request_uri を返す。
  3. ブラウザは request_uri だけを持って認可エンドポイントへ。

という方式で、

  • URL が短くなる
  • リクエストがブラウザを一切通らない（改ざん・盗聴の余地が消える）

という二重の利点がある。
FAPI 2.0 では PAR が必須になっている。

考察

プロファイル

関連仕様

参考

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

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

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