FAPIを中心とするAPI標準化の動向

Prepared for オープンバンキング/API 勉強会 https://www.authlete.com/ja/news/20240109_open_banking/

銀行APIのセキュリティ仕様として広く普及している「FAPI」を中心とする技術動向を紹介

Transcript

1. FAPIを中心とするAPI標準化の動向 工藤達雄 Japan Country Manager, Authlete
2. 2 • 日本のAPIセキュリティスタートアップ • OAuth & OpenID Connect サーバーを実装するための機能をAPIとして提供 About Authlete 楽天銀行 DPG Media NTT Docomo Nubank
3. • Authleteを採用し、ブラジルのオープン バンキング指令に準拠した認可サーバーを 構築 • SaaS形式で利用可能な「コンポーネント」 であること、技術と製品の品質、専門家の 知識とサポートを評価 • 別の新たな決済サービス「NuPay」にもAuthlete を採用 Nubank Chose Authlete Source: https://building.nubank.com.br/open-finance-challenges-how-nubank-protects-customer-data-and-optimizes-operations/ 3
4. 4 • 銀行 → 金融サービス → 通信、エネルギー、医療、小売、… • 対象領域が広がるにつれて、APIの種類も増える Open Banking to Open Finance (to Open “X”) Source: https://bankingblog.accenture.com/unlock-the-promise-of-open-banking-market-infrastructure, https://www.openbanking.org.uk/open-finance/
5. Areas of Standardizing Open Finance APIs • 標準化による接続性向上と、独自化による付加価値向上 • 「セキュリティ & 同意 API」は標準化の対象にしやすい • 高付加価値のサービス • 先行する銀行やアライアンスによる独自API • e.g., eKYC、与信 Premium API • 銀行サービスの基本的な機能 • 国や地域にて統一化されたAPI • e.g., 残高照会、取引参照、送金、決済 Business API • 金融サービスに向けた高水準の セキュリティ & 同意管理機能 • 地域・業界を横断した共通API • e.g., API認可、ID連携 Security & Consent API 5
6. 6 • APIが「利用者の意図通り使われる」ための基礎 • セキュリティ – API提供側からAPI利用側へのアクセス権限付与の最小化 – API提供側・利用側の間でのユーザー認証情報共有の防止 – 攻撃者によるアクセス権限の窃取・盗用の防止 • 同意 – アクセス権限定義の細粒化 – アクセス権限付与に関するユーザー同意の取得 – ユーザーによる同意管理 Security and Consent API as a Foundation Premium API Business API Security & Consent API
7. 7 • API認可のフレームワーク – 認可に必要な「アクセストークン」の授 受・利用を規定 • API提供側が直接ユーザーを認証 – エンドユーザーのパスワードがAPI利 用側に渡らない上、さらに生体認証な どを用いた高度な認証も可能 • エンドユーザー本位のAPI連携 – API利用側によるアクセスの許諾を、 API提供側がエンドユーザーに確認し た上で実施 OAuth 2.0 (“OAuth”) for Security & Consent API エンドユーザー API提供側 API利用側 4. アクセストークン を含むAPIリクエスト 3. アクセス トークンを 発行 2. ユーザー認証と APIアクセス認可 1. 認可プロセス開始
8. 8 • OAuth仕様はAPI認可の事実上の標準 – ソーシャルから金融、コンシューマーからエンタープライズ、 WebからIoT、… • しかし、ほぼすべてのOAuthは独自仕様 – OAuth仕様自体は「フレームワーク」 – 「プロトコル」にするためにはユースケースに合わせた詳細 仕様化（プロファイリング）が必要 – 多数のOAuthの拡張仕様・プラクティスを取捨選択 • オープンバンキング共通のOAuthの詳細仕様は? – アクセストークンの不正授受・不正利用の防止 What Does Your OAuth Look Like? Source: https://tools.ietf.org/wg/oauth
9. 9 • 高度な API セキュリティを実現するための OAuth の 詳細仕様（セキュリティプロファイル） – OAuth および OpenID Connect (OIDC) のオプションや拡張 仕様の用法を定義 – Financial API -> Financial-grade API -> FAPI • 米国 OpenID Foundation の FAPI WG が策定 • 2021年3月にFAPI 1.0が確定 FAPI for High-Value Use Cases Source: https://openid.net/wg/fapi/
10. FAPI Prevents Obtaining and Using Access Tokens by Attackers API利用側 攻撃者 API提供側 OAuthアクセス認可リクエスト 認可レスポンス・トークン付与 トークン付きAPIリクエスト（参照・更新） r不正なトークン授受の防止 トークン窃取 不正なトークン利用の防止 窃取したトークンを用いた 「なりすましアクセス」を 検知しリクエストを拒否 10
11. 11 • FAPI認定プログラム (FAPI Certification Program) – 実装（ソフトウェアや運用環境）がFAPIに対応しているかを テスト・公表するしくみ – OpenID Foundationが運営 – 認定実装一覧 (Certified Implementations): セキュリティ と相互運用性が保証されているソリューションを公開 – 適合性テストスイート (Conformance Test Suite): テスト の効率化・自動化 • Formal Security Analysis – FAPIが企図するセキュリティ特性を証明 Assuring Security of FAPI Source: https://openid.net/wp-content/uploads/2023/12/OIDF_FAPI-Certification- Overview_CAMARA_2023-12-20.pdf
12. 12 • FAPI 1.0が実現したセキュリティを、より実装しやすいように整 理 – FAPI 1.0確定後にRFC Proposed Standardになった仕様を採用 • RAR (Rich Authorization Requests):アクセス権限定義の細粒化 • PAR (Pushed Authorization Requests): よりセキュアな認可リクエ ストの送受信 • DPoP (Demonstrating Proof of Possession): アクセストークン 盗用防止の新手法 – FAPI 1.0 Advancedの「メッセージ署名」を再構成・拡張 • FAPI 2.0 MS (Message Signing) • 「認可リクエスト」「認可レスポンス」「イントロスペクションレスポン ス」「リソースリクエスト・レスポンス」に関する署名・検証 • FAPI 1.0からの移行を考慮 – いくつかのエコシステムでは FAPI 2.0への将来の移行を念頭に FAPI 1.0を適用 (“FAPI 1 Advanced with PAR”) FAPI 2.0 Resource Owner User Agent Client Authorization Server Resource Server 「リクエストURI」を 含む認可リクエスト 認可レスポンス トークン リクエスト (DPoP/mTLS) トークン レスポンス リソースリクエスト (DPoP/mTLS) リソースレスポンス （完了） ユーザー認証・ アクセス承認 認可リクエストの内 容 (RAR)を登録 「リクエスト URI」返却 PAR EP Authz EP Token EP (スタート) イントロスペクションリク エスト イントロスペクションレス ポンス
13. 13 • FAPI 2.0 Security Profile (SP) – 実装者向けドラフト第2版 – 2024年前半に最終版の投票（標準仕様化）が実施される見込み • FAPI 2.0 Message Signing (MS) – 実装者向けドラフト第1版 • FAPI Certification Programにてサポート済み • 一部のエコシステムではすでにFAPI 2.0を採用、または移行 予定 – FAPI 2.0を採用 • 豪州ConnectID • ノルウェー Norsk Helsenett – FAPI 1.0からの移行を計画 • 豪州Consumer Data Right Current Status of FAPI 2.0 Source: https://openid.net/certification/#FAPI2-SECURITY
14. 14 • FAPI 1.0: 同意管理はスコープ外 – 一部のエコシステムでは独自に拡張 • 例: 豪州CDRの “cdr_arrangement_id” • FAPI 2.0: Grant Management 仕様を策定中 – ユーザーはAPI提供側からAPI利用側に権限 (grant) を 与えることに同意 (consent) – API利用側は権限 (grant) に関し以下を実施 • 付与されている既存の権限 (grant) の照会・取り消し • 同意 (consent) の範囲内で既存の権限 (grant)を更新 （e.g., 追加の権限を要求） • 同一ユーザーに、client_idは共通だが複数に分かれる サービスごとに権限 (grant) を管理 FAPI and Consent Management Source: https://cx.cds.gov.au/overview/about-consent/the-consent-model
15. 15 • 英国 – 上位9行に、FAPIを基盤とする共通APIを義務化 – 他の銀行も自発的に採用し、 APIの統一が実現 • 豪州 – 銀行だけではなく通信やエネルギー分野まで含めた 統一的なAPIの基盤としてFAPIを採用 • ブラジル – Open Banking & Open Insurance においてFAPIを採用 • 米国 & カナダ – 業界団体のFinancial Data Exchange がセキュリティ プロファイルとしてFAPIを採用 • その他 – ナイジェリア、ニュージーランド、ロシア、ノルウェー、 ドイツ、サウジアラビア、日本、 … FAPI Adoption Source: https://openid.net/wp-content/uploads/2023/12/OIDF_FAPI-Certification-Overview_CAMARA_2023-12-20.pdf Source: https://openid.net/wp-content/uploads/2023/12/OIDF_FAPI-Certification- Overview_CAMARA_2023-12-20.pdf
16. 16 • FAPI対応済みの事業者 – OP (API提供側): みんなの銀行 *1、auじぶん銀行 *2 – RP (API利用側): マネーフォワード、三井住友海上プライマリー生命保険、ピクシブ、ユナイ テッド・スーパーマーケット・ホールディングス、弥生 *3 • FAPI認定を取得済みの国内ソフトウェアベンダー & サービス事業者 *4 – OP (API提供側): Authlete、NEC、NRIセキュアテクノロジーズ、 NTTテクノクロス、沖電気、ゼ ロバンク・デザインファクトリー – RP (API利用側): 日立 • その他、複数の金融・非金融サービス事業者がFAPI対応を準備中 FAPI Adoption in Japan Source: (*1) https://corporate.minna-no-ginko.com/information/corporate/2022/11/08/243/, (*2) https://www.authlete.com/ja/news/20231020_jibunbank/, (*3) https://faq.minna-no-ginko.com/s/article/MNG-1164, (*4) https://openid.net/certification/
17. 17 • FAPI: セキュリティ・同意APIの基礎 • FAPI 1.0: 多くのエコシステムが採用 • FAPI 2.0: 2024年に最終版確定の見込み • 日本: 複数の事業者・ソリューションがFAPIに対応 Takeaways
18. Thank You www.authlete.com info@authlete.com Palo Alto, Tokyo, Dubai