FAPI 2.0 の認定取得しました

はじめに

ゼロバンクデザインファクトリーの豊島です。

弊社が開発・運用している みんなの銀行 BaaS API が FAPI 2.0 認定されたので報告かねてレポートを記載します。

ご存知の方もいらっしゃるかもしれませんが、みんなの銀行は FAPI 1.0 Advanced のプロバイダーとして 2021年7月に認定されました。

本投稿では なぜ我々が FAPI 2.0 移行をするのか、FAPI 1.0 との違いについて触れます。(個人的見解多々あります)

FAPI 1.0 との違い

まず前提として、FAPI 2.0 には二つの Profile があります。

• Security Profile
• Message Signing

弊社は両方とも認定取得しました。

Security Profile (SP)

FAPI 2.0 SPのdraftページに分かりやすい表があります。

PAR必須化と署名の廃止

OAuth 2 の前提知識が多少必要ですが、この中で最も興味深いのは

• PAR (Pushed Authorization Request)の必須化
• JAR (JWT-Secured Authorization Request), JARM (JWT-Secured Authorization Response Mode) の廃止 = 認可リクエスト/レスポンスの署名不要

です。

FAPI 1.0 ではPARはオプショナルかつ認可リクエスト署名は必須なのが特徴です。

今回、FAPI 2.0 ではPARの必須化と同時に認可リクエストの署名が不要になりました。

さらに認可レスポンスも同様で、JARMである必要がなくなったのでクライアントに署名検証を要求しなくて良くなります。

この変更は当事者としてはとても嬉しい事です。なぜなら、クライアントの Developer Experience が向上する。これに尽きます。

FAPI 1.0 では 、「クライアントにとって接続難易度が高い」という課題感がありました。

いくらセキュアさが売りになるとはいえインテグレーションコストが高いと、ビジネス観点でスケールさせずらい面があったりします。

では FAPI 1.0 に比べて FAPI 2.0 がセキュアではないわけはなくFAPI 2.0 Attacker Model が定義されておりしっかり立証されています。

その他の違い

• PKCE : 驚きかもしれませんが、FAPI 1.0 AdvancedではPKCEが必須ではありませんでした。(弊社のBaaS APIでは FAPI 1.0 であっても PKCE 必須の設定です)
• code id_token の廃止：JARの方を採用していたので正直無関心です。
• x-fapi-interaction-id : 現段階では未確定なのでまだ残している。FAPI2のtest suiteではまだ必要だった。TraceId は別途あるので冗長だなとは思っていた。
• mTLS or DPoP : 現状 みん銀 BaaS API に繋ぐにはmTLS前提なので現状維持。しかし、mTLS前提という制約を課すとこれもまたクライアントのDeveloper Experienceに関わる話なので要検討課題ではある。mTLSの代替として、例えば HMAC認証 + DPoP との組み合わせは有りかも？

以上が変更に関する要点ですが、他にもアクセストークンの有効期限10分の明記がなくなった事やリフレッシュトークンローテーションの廃止など細かい重要ポイントがあるので公式ページを参照ください。

Message Signing

こちらは FAPI 2.0 SP とは反対で認可リクエスト・レスポンスの署名を FAPI 1.0 Advanced に引き続き必要とするプロファイルです。それ以外は FAPI 2.0 Security Profile のルールに準じます。

個人的見解ですが、Message Signing は FAPI 2.0 のメリットが薄まるのではないかと考えています。

クライアントにとっては署名検証・署名がなくなるだけで相当負荷が減るんじゃないかと思ってます。3rd party library を使えば署名も検証も実装はそんなに難しいものではないのですが、やっぱりJWKSの管理とか、前提知識とかお互い面倒があるものです。

とはいえ、接続のしやすさよりより断固として強いセキュリティを求めるニーズとか、FAPI 1.0 Advanced との互換性維持とか Message Signing 自体の存在意義はあると思います。

ということで、基本路線は FAPI 2.0 Security Profileを推していきたいと考えています。既存のクライアントが FAPI2に移行したい希望がある場合はMessage Signingも選択可なのでそういう意味では互換性維持なのは Developer-Friendlyかも。

オプショナルな推奨仕様

• FAPI CIBA
• Grant Management
• OAuth 2.0 Rich Authorization Requests (RAR)

CIBA (Client Initiated Backchannel Authentication) は今のところ必要なユースケースがないので実装検討もしていませんので割愛します。

Grant Management はほぼ実装しています。ほぼというのは既存の我々の Consent API が同等の機能を提供しています。このRESTful APIによってクライアントは認可期間を確認できたり、リフレッシュトークンを有効期限前にRevokeしたり、認可期間延長をしたりすることができます。
Grant Management for OAuth2 のdraft が final化されたら OAuth2 APIの一部として Grant Management にリブランディングしようと勝手に想像している段階です。(後方互換性のために Consent API自体は残します)

RAR は最近匂わせ案件があるので近いうちに実装するかもです。Scopeだけでは表現できない粒度の細かいリソースの認可などユーティリティ性が高い仕様です。

FAPI 1.0 から FAPI 2.0 サポートの実装と認定

実装作業

色々違いがあるとはいえ、FAPI 1.0 Advanced の仕様が継承されているのでベースのところは変わらないです。したがって実際の作業は PAR をフローに取り込んだ後、署名系はオプショナルに修正し、あとは OpenID Foundation が提供する FAPI 2 のConformance test を流してFailしたところをちょこちょこ修正してゴールって感じでサクッと対応できました。

Conformance test の画面

我々の認可サーバー自体を修正する箇所もありましたが、ほぼ裏側で使っているAuthleteのconfigを正しく設定し直すことで解決できたので思ったより簡単でした。

他案件と並行で片手間気味で作業していたのですが、認定までの作業には2週間くらい要しました。

以下、出来上がった外部向けに公開しているフローです。

認定について

FAPI 2.0 Security Profile Second Implementer’s Draft & Message Signing First Implementer’s Draft において以下の4つのプロファイルの認定を取得しました。

• FAPI2SP MTLS + MTLS
• FAPI2SP OpenID Connect
• FAPI2MS JAR
• FAPI2MS JARM

Conformance test でカバーするのは基本的に必須要件のみなので、前述の推奨されるオプショナルな仕様は対象外です。正直、Grant Management あたりのテストケースも期待していたのですがオプショナルでおそらくまだドラフトということもありスコープ外でした。FAPI 2.0 Final化されたときにGrant ManagementやRARのテストケースもあると嬉しいと思いました。

まとめ

FAPI 1.0からFAPI 2.0への移行は、クライアント側の開発者としての経験をさらに向上させると同時にセキュリティの厳格さも維持しているという点が優れています。

既存、FAPI 1.0 はセキュアで問題ないので引き続き使用可能としつつ、来年初旬頃からFAPI 2.0の実用化を開始していきたいと計画しています。