銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
1 like890 views
Prepared for OpenID BizDay #13 https://peatix.com/event/1675619
銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday
- 1. 2020-11-12OpenIDBizDay #13 銀行 API における OAuth 2.0 / FAPI の動向 工藤達雄 Authlete, Inc.
- 2. 2 • 「銀行 API」と OAuth 2.0 • Financial-grade API (FAPI) • 英国オープンバンキングにみる FAPI の活用 Agenda
- 3. 3 • サン・マイクロシステムズ、 野村総合研究所、NRI セキュア を経て、2018年 Authlete に入社 • 20数年間、デジタルアイデン ティティを中心とするプリセー ルス・コンサルティング・事業 開発・エバンジェリズムに従事 About Me
- 4. 「銀行 API」と OAuth 2.0
- 5. • 「オープンデータ」の提供 – 支店の住所情報など • コア機能のホワイトレーベル提供 – “Bank as a Service” • お客さまに関わるデータ・機能の提供 – 口座情報・契約情報・取引履歴などの データ、取引の実行機能など 「銀行API」とは 約2.4万API中、Bankingカテゴリに登録されているのは590種類 Source: https://www.programmablew eb.com/category/banking 5
- 6. API 提供をユーザーが制御するための “OAuth” クレジット 株・年金 口座情報 送金機能 与信情報 複数の口座を一括管理 アプリから直接送金 サードパーティ （例：フィンテック企業） API公開 （例：銀行） ユーザー ユーザーが認可アプリ XYZ - 利便性アップ - 新たな消費行動 の促進 APIアクセス認可 どのユーザーが どのサードパーティに どのような権限を与えるか OAuth 2.0 6
- 7. 7 • オープンAPIのあり方に関する検討会報告書 （2017年７月13日） https://www.zenginkyo.or.jp/abstract/council/openapi/ – “「認可プロトコル」として、OAuth2.0認可フレーム ワーク（以下「OAuth2.0」という。）を推奨する。” • 金融機関とAPI接続先のためのAPI接続チェック リスト（2019年９月27日一部改訂） https://www.fisc.or.jp/document/fintech/004194.php – “OAuth2.0の仕組みを理解しており、それに関連する 項目の意味を説明することができる。” 国内の「銀行 API」における OAuth の位置づけ
- 8. 8 • OAuth 2.0 は「フレームワーク」 – 厳密な接続手順を定めた「プロトコル」ではない • API 提供側による「詳細仕様化」が必要 – 例: スコープ（APIアクセス権の範囲・種別）の設 計、アクセストークン（APIアクセス権を表現す る文字列）のライフサイクル管理、… • 仕様やプラクティスが次々に追加・更新 – 要件に応じて適切な仕様を取捨選択しなくてはな らない What Does Your OAuth Look Like? Source: https://tools.ietf.org/wg/oauth/, https://openid.net/wg/fapi/
- 9. 9 • 各行が独自の判断に基づき OAuth 2.0 を詳細仕様化 – 詳細仕様のさまざまな点が銀行ごとにバラバラ – API利用側は各行ごとの詳細仕様の差異の把握 ・実装が負担に • 詳細仕様化のコストは各行が負担 – オープンAPI提供に際しての高いセキュリティー水準の担保は 必須 – しかしセキュリティー対策自体は直接的な収益をもたらさない OAuth が銀行 API の進展を阻む（かも）
- 10. • 高付加価値のサービスを、先行する銀行やア ライアンスが独自APIとして提供 • eKYC、与信など プレミアム API • 銀行サービスの基本的な機能を、国や地域に て統一化されたAPIとして提供 • 残高照会、取引参照、送金、決済など ビジネスAPI • 金融サービスに向けた高水準のセ キュリティ機能を、地域・業界を 横断して共通のAPIとして提供 • API認可（OAuth 2.0）、ID連携 （OpenID Connect）など セキュリティAPI 「セキュリティ API」の標準化・共通化 10 FAPI
- 12. 12 • 金融サービス API のセキュリティーに適したOAuth 2.0 の詳細仕様 (セキュリティープロファイル) ・API 仕様・実装ガイドライン • 米国 OpenID Foundation が 2016年設置した「Financial-grade API (当初はFinancial API) ワーキンググループ(FAPI WG)」にて検討 • 現在（2020 年11月）、仕様確定に向けて公開レビュー中 – パート1 (Baseline): 基本的なセキュリティー対策 – パート 2 (Advanced): より高度な対策 Financial-grade API (FAPI) https://fapi.openid.net/
- 13. 13 • 一般的な OAuth 2.0 の詳細仕様化では対応できていないセキュリティリスクに 対し、OpenID Connect (OIDC) や拡張仕様を積極的に取り込んで対応 – 例: トークンの不正な授受 • トークン授受手順において、エンドユーザーの端末 (Web ブラウザーなど)を経由する箇所が あり、攻撃者がそのやりとりを改ざん・ 偽造してトークンを不正取得できる可能性がある • → リクエストオブジェクト、ハイブリッドフロー、JARM – 例: トークンの不正使用 • 一般的に用いられている「持参型」のトークン はその利用主体を限定できないため、なんら かの方法でトークンを入手した攻撃者がそれを用いてAPIへ不正アクセスできるようになる • → クライアント証明書に結びつけたアクセストークン FAPI Part 2 (Advanced)
- 15. 15 • 独自詳細仕様の設計・実装・ 運用に伴うコストの増大を抑え つつ、高度なセキュリティー対策を備えたOAuth 2.0 基盤の 確立が可能となる • FAPI 実装の「認定プログラム」も有用 – OAuth 2.0 基盤構築時にFAPI準拠のソフトウェアを選定できる – 自行のFAPI実装に対してテストスイートを継続的に実行し、サード パーティに対する信頼を高められる 銀行における FAPI 採用の利点
- 17. 17 • 英国では政府主導のもと銀行業界共 通のAPI技術標準を策定し上位9行に 義務化 – 他の銀行にも自主的な採用を促進 • 2020年8月には、API提供側 (銀行) 77行、API利用側(サードパーティー) 196社が参加 英国オープンバンキング Source: https://www.openbanking.org.uk/
- 18. 18 • 英国「オープンバンキング」仕様ではOAuth 2.0を採用 – ただしその詳細仕様については当初（2017年）、FAPI仕様の初期案 をベースに独自の取捨選択を行ったものだった • しかし、FAPI仕様の策定が進み、同時に英国からのフィー ドバックが取り込まれたこともあり、現在では独自仕様を 廃止し、FAPIを改変せず、そのまま自国の標準として採用 – Client Initiated Backchannel Authentication (CIBA)も採用 • 結果的にすべての事業者(API提供側・利用側の双方)が、グ ローバルに 入手可能な実装とノウハウ蓄積の恩恵を受けら れる段階に 英国オープンバンキングと FAPI Source: https://openid.net/2020/09/29/the-openid- f oundation-and-the-uk-open-banking-implementation- entity -hosting-a-workshop-f ocused-on-f inancial-grade- api-f api-and-third-party -prov iders-tpps/
- 19. エンドユーザー・銀行・サードパーティの関係 19 User エンドユーザー API Onboarding （API接続設定） API Access（APIアクセス） ASPSP 銀行 TPP サードパーティ
- 20. FAPI を基盤に各種仕様を整備 20 API Access API Onboarding • Open Banking Directory • Dynamic Client Registration • Security Profile (OpenID FAPI / CIBA) • Read / Write Data API • Customer Experience Guidelines • Customer Experience Guidelines (CEG) User エンドユーザー ASPSP 銀行 TPP サードパーティ
- 21. Read/Write Data API Specification 各種 Read/Write Data API (Accounts and Transactions,Paymentsなど)のベースとなる仕様 21Source: https://standards.openbanking.org.uk/api-specif ications/red-write-specs/latest/
- 22. Security & Access Control FAPI/CIBAをOpenBanking Standardにどう適用するか（プロファイル）の規定 22Source: https://standards.openbanking.org.uk/api-specif ications/red-write-specs/latest/
- 23. 23 • サードパーティが銀行のAPIに、 口座情報取得や決済指図伝達な どの「インテント」を事前登録 • 登録された内容を利用者が 銀行のWebサイトや アプリにて確認・承認 • 承認後、サードパーティが「イ ンテント」の内容の実行を銀行 のAPIにリクエスト インテントによる「取引単位」のアクセス認可 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス （完了） 取引内容への 承認を確認 「インテント」登録 「インテントID」返却
- 24. 24 • 「カスタマージャーニー」の 指針 • 各種規制（PSD2, RTS on SCA & CSC, CMA Order） への適合 • チェックリスト (CEG Checklist) を併せて提供 Customer Experience Guidelines (CEG) https://standards.openbanking.org.uk/customer-experience-guidelines/ Source: https://standards.openbanking.org.uk/customer-experience-guidelines/
- 25. 25 • TPP/ASPSP間の連携プロセス – TPP側のアプリ/ブラウザから開始〜ASPSP側でのユーザー認証〜TPP側での連携完了まで • 「TPPに共通の認証方式」と「各サービス固有の要素」を整理 Open Banking カスタマージャーニー Source: https://standards.openbanking.org.uk/customer-experience-guidelines/introduction/customer-journey /latest/, https://standards.openbanking.org.uk/customer-experience-guidelines/authentication-methods/redirection/browser-based-redirection-pis/latest/
- 26. “Open Banking (OB) Directory” による管理 • 参加する全ての事業者（銀行と サードパーティ事業者）が自組織 の情報をOBディレクトリに登録 • OBディレクトリはSSA（後述） の発行や各行APIのメタデータ （接続に必要な設定情報）を管理 → サードパーティ事業者と銀行との 連携にかかる設定を効率化 26 Source: https://f inopolis.ru/materials-of -forum/2018/OpenBankingUpdate.pdf
- 27. Dynamic Client Registration (DCR) • Open Banking DirectoryなどがTTPに “Software Statement Assertion” (SSA) を発行 – Software Statement (SS): APIクライアントの メタデータ。署名もしくはMAC付きのJWT形式 – SSA: 発行者（≠ TPP）によって署名されたSS • TPPはそのSSAを用いて、ASPSPに対し、 自身のAPIクライアントの動的登録を試行 • ASPSPは信頼する発行者のSSAであることを確 認し、その内容を元にクライアントを登録 → サードパーティ事業者が容易に複数行のAPIに接 続可能に 27 Source: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/ 1078034771/Dy namic+Client+Registration+-+v 3.2
- 28. 28 • 各国における標準のひな形として – オーストラリア (CDR)、ニュージーランド、 米国 (FDX)、スロバキア、ナイジェリア、 バーレーン、… • 各行独自の実装として – 国内外の銀行、および銀行向けソリューショ ンプロバイダーからの引き合いが増えている (Authlete 社の状況) 世界に波及する FAPI / OBUK プラクティス Source: https://consumerdatastandards.gov .au/, https://pay mentsdirection.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/ov erview, https://f inancialdataexchange.org/, https://www.sbaonline.sk/projekt/slovak-banking-api-standard/, https://openbanking.ng/, https://bahrainob.atlassian.net/wiki/spaces/BH/overview
- 29. • “FAPI1” – 2021年1月に確定の見込み • “FAPI2” – リファクタリング+新機能 29 FAPI の今後 Source: https://y outu.be/LOha4RLt9eI
- 30. まとめ
- 31. 31 • 収益拡大のためには利用者数・取引数 の増大が必須 • 業界共通のセキュリティAPI として FAPI を採用し、相互接続のハードル 低下と実装・運用コストの低減を目指 すべきではないか FAPI が銀行 API の成否を分ける プレミアム API ビジネスAPI セキュリティAPI
- 32. 32 • 週刊 金融財政事情 2020 年 2 月 3 日号（3341 号） – https://www.authlete.com/ja/resources/publications/kinzai/ • 米国オープンバンキングの近況 – Qiita – https://qiita.com/TakahikoKawasaki/items/59bafa8383ed8afe2006 • Financial-grade API – Authlete – https://www.authlete.com/ja/developers/fapi/ Resources