Weitere ähnliche Inhalte Ähnlich wie 銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday (20) Mehr von Tatsuo Kudo (19) 銀行 API における OAuth 2.0 / FAPI の動向 #openid #bizday2. 2
• 「銀行 API」と OAuth 2.0
• Financial-grade API (FAPI)
• 英国オープンバンキングにみる FAPI の活用
Agenda
5. • 「オープンデータ」の提供
– 支店の住所情報など
• コア機能のホワイトレーベル提供
– “Bank as a Service”
• お客さまに関わるデータ・機能の提供
– 口座情報・契約情報・取引履歴などの
データ、取引の実行機能など
「銀行API」とは
約2.4万API中、Bankingカテゴリに登録されているのは590種類
Source: https://www.programmablew eb.com/category/banking
5
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 の進展を阻む(かも)
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)
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/
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/
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
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