More Related Content Similar to 英国オープンバンキング技術仕様の概要 (20) More from Tatsuo Kudo (20) 英国オープンバンキング技術仕様の概要4. 関連する仕様・ガイドライン
4
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
サードパーティ
5. 5
• API Access
– FAPI/CIBA
– R/W Data API
• Customer Experience
– CEG
• API Onboarding
– Open Banking Directory
– Dynamic Client Registration
• Solution Example for Implementation
Agenda
User
ASPSPAPI Access
API Onboarding
• Open Banking Directory
• Dynamic Client
Registration
• Security Profile (OpenIDFAPI / CIBA)
• Read / Write Data API
• Customer Experience
Guidelines
• Customer Experience
Guidelines (CEG)
TPP
9. 9
• 2005~2007: 黎明期
– 2005: OpenID 誕生 / 2006: OAuth 誕生
• 2007: OpenID 2.0 / OAuth 1.0 仕様化
• 2008~2012: 変革期
– OAuth 1.0 → 1.0a → WRAP
– OpenID 2.0 → Contract Exchange / Artifact Binding (AB)
/ 旧 OpenID Connect → AB/Connect
• 2012: OAuth 2.0 仕様化
• 2014: OpenID Connect (OIDC) 1.0 仕様化
• …
• 2019: 引き続き活発に仕様策定が続いている
OAuth / OpenID Connect (OIDC) の標準化状況
Source: https://twitter.com/blhjelm/status/1055551254401736704
10. セキュアな “OAuth Dance” を踊るには
1. 「認可リクエスト」
「認可コード返却」の
真正性の担保
2. 「アクセストークン」
取得時における
リクエスト元の確認
3. APIアクセスにおける
「アクセストークン」
行使者の限定
10
利用者 Fintech企業 金融機関
ユーザー Webブラウザ Webサイト
認可
サーバー
APIサーバー
認可
リクエスト
認可
コード
認可
コード アクセス
トークン
アクセス
トークン
APIレスポンス
ログインして
連携を許可
金融機関との
連携を開始
連携完了
11. Financial-grade API
(FAPI)
金融APIにOAuth/OIDCをどう使うか
11
• APIセキュリティの要である “OAuth 2.0” は仕様の解釈のブレや実装の不備を生みやすい
→ 不正アクセス発生の原因となることが少なくない
• 従来はAPIを提供する各事業者(金融機関など)がOAuth 2.0適用にかかるセキュリティ対策を行っていた
→ 事業者ごとの独自仕様が乱立してしまっている
• 加えてその「セキュリティ対策」の水準が各社各様である
→ 過剰・冗長なケースや、逆に対策としては有意ではないケースもある
→ 結果的に、API提供事業者が「オープン標準ではない独自仕様」かつ「不十分なセキュリティ対策」をサード
パーティ(API利用事業者)に押し付ける構図になり、サードパーティによるAPI活用の阻害要因になっている
APIセキュリティの課題
12. Financial-grade API (FAPI)
• 金融API向けのOAuth 2.0適用プラクティス
• さまざまな立場の専門家が仕様策定に集結
– OAuth / OpenID Connect仕様策定者
– 金融機関
– サードパーティ(Fintech事業者)
– セキュリティ研究者
– ソリューションベンダー
– …
12
Source: https://openid.net/wg/fapi/
13. FAPIセキュリティ・プロファイル
• Part 1 (Read Only)
– OAuth 2.0 適用のプラクティス
– OAuth 2.0 拡張仕様
– OIDC によるユーザー識別子の授受
• Part 2 (Read & Write): OIDC の積極的な
活用 + 新たな拡張仕様
– RequestObject,Hybrid Flow, MTLS, OAUTB
– JARM
13
OIDC拡張仕様
OIDCプラクティス
OAuth2拡張仕様
OAuth2プラクティス
Part1(ReadOnly)
Part2(Read&Write)
15. • 認可リクエスト / レスポンスの送信者
詐称・改ざん防止
– Request Objectの利用
– Hybrid FlowもしくはJARMの利用
• 認可コードの漏洩・盗用防止
– redirect_uriの厳密な管理
• クライアントのなりすまし防止
– Mutual TLSもしくはJWTによる
クライアント認証
• トークンの漏洩・盗用防止
– OAUTB(トークン・バインディング)
もしくはMTLS(双方向TLS接続への
バインド)の利用
FAPIにおける “OAuth Dance” の改善・改良
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
認可
リクエスト
認可
コード
認可
コード
アクセス
トークン
アクセス
トークン
APIレスポンス
15
18. “Decoupled Flow”
• 「アレクサ、お店に
5,000円払って」
→ 手元のケータイに
決済サービスAppから
通知
18Source: https://www.europeanpay mentscouncil.eu/document-library /minutes-and-agendas/authentication-sca-guidance-key -topic-clarif ication-api
19. “Decoupled Flow”
• TVショッピングとかで、
– 視聴者が電話で購入希望を伝える
– オペレーターに「ではお客さまの
スマートフォンに注文内容をお送り
します。ご確認をお願いします」と
言われる
– 視聴者は手元のスマートフォンにきた、
決済サービスAppからの通知をみて
承認する
Source: https://www.linkedin.com/pulse/decoupled-authentication-moto-tatsuo-kudo/ 19
20. “Decoupled Flow”
• 仮に Ponta の ID と決済できるとこのIDが紐づいてたら
– コンビニ店員「Pontaカードカモン」
– 客「はい」
– 店員「XXX円です」
– 客「CIBA Pay(ダッサ)」
– 店員「はい(ポチ)」
– 客のスマホ「(XXX円をローソンに支払います。
よろしいですか?)」
– 客「おk」
– 店員「支払いおわた。レシートどぞ」
ぐらいは出来そうです
Source: https://ritou.hatenablog.com/entry /2018/12/29/224452 20
21. 21
• OpenID Foundation 傘下のWGにて策定中の新たなオープン仕様
– 「サービスを利用するデバイス」と「認証を行うデバイス」を分離
• より良い顧客体験 (CX) の提供とセキュリティ強化に有用
CIBA Client Initiated Backchannel Authentication
22. CIBA のフロー
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
(リライング・
パーティ)
認可・APIサーバー
(アイデンティティ・
プロバイダー)
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint
BA EP
API
(*) Access Token
(**) Refresh Token
(4)
(4) トークン
を使ってAPI
アクセス
(4)
(4) 認証結果を
利用して処理を
実行
1
1. 認証
リクエスト
User
Identif ier
2
2. 受付応答
AuthN Req ID
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)
バックチャネル認証
エンドポイント
2’
2’. ユーザー
認証
22
23. 23
• FAPI (Financial-grade API) and CIBA (Client Initiated
Backchannel Authentication)
https://www.slideshare.net/tkudo/fapi-ciba-2019-03-28
• 世界最先端の API セキュリティー技術、実装者による
『FAPI(Financial-grade API)』解説
https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744
• 世界最先端の認証認可技術、実装者による『CIBA』
解説
https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3
FAPI/CIBAの参考情報
25. Read/Write Data API Specification
各種 Read/Write Data API (Accounts and Transactions,Paymentsなど)のベースとなる仕様
25Source: https://standards.openbanking.org.uk/api-specif ications/red-write-specs/latest/
26. Security & Access Control
FAPI/CIBAをOpenBanking Standardにどう適用するか(プロファイル)の規定
26Source: https://standards.openbanking.org.uk/api-specif ications/red-write-specs/latest/
27. 27
• リソースオーナー(ユーザー)
がクライアントに移譲する権限
の粒度
– APIによってアクセス可能な
データの種類・範囲
(e.g. 口座情報、取引履歴)
– APIによって実行可能な機能の
範囲(e.g.参照、決済、送金)
• 「ある特定の取引」「同意した
範囲でのデータ取得」のような
粒度を表現するにはどうするか?
OAuth における「スコープ」 (scope)
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
(スタート)
(OAuth) 認可リクエスト
(OAuth) 認可レスポンス
(OAuth)
トークン
リクエスト
(OAuth)
トークン
レスポンス
(OAuth)
API
リクエスト
(OAuth)
API
レスポンス
(完了)
ユーザー認証・
アクセス承認
GET /authorize?
response_type=code&
client_id=287560982&
redirect_uri=https://
client.example.org/cb&
scope=payment&…
30. 例: 「インテント」登録
30
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
POST /domestic-payment-consents HTTP/1.1
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
x-idempotency-key: FRESCO.21302.GFX.20
x-jws-signature:
TGlmZSdzIGEgam91cm5leSBub3QgYSBkZXN0aW5hdGlvbiA=..
T2ggZ29vZCBldmVuaW5nIG1yIHR5bGVyIGdvaW5nIGRvd24gPw==
x-fapi-auth-date: Sun, 10 Sep 2017 19:43:31 GMT
x-fapi-customer-ip-address: 104.25.212.99
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Content-Type: application/json
Accept: application/json
{
"Data": {
"Initiation": {
"InstructionIdentification": "ACME412",
"EndToEndIdentification": "FRESCO.21302.GFX.20",
"InstructedAmount": {
"Amount": "165.88",
"Currency": "GBP"
},
"CreditorAccount": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Identification": "08080021325698",
"Name": "ACME Inc",
"SecondaryIdentification": "0002"
},
"RemittanceInformation": {
"Reference": "FRESCO-101",
"Unstructured": "Internal ops code 5120101"
}
}
},
"Risk": {
"PaymentContextCode": "EcommerceGoods",
"MerchantCategoryCode": "5967",
"MerchantCustomerIdentification":
"053598653254",
"DeliveryAddress": {
"AddressLine": [
"Flat 7",
"Acacia Lodge"
],
"StreetName": "Acacia Avenue",
"BuildingNumber": "27",
"PostCode": "GU31 2ZZ",
"TownName": "Sparsholt",
"CountySubDivision": [
"Wessex"
],
"Country": "UK"
}
}
}
31. 例: 「インテントID」返却
31
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
HTTP/1.1 201 Created
x-jws-signature:
V2hhdCB3ZSBnb3QgaGVyZQ0K..aXMgZmFpbHVyZSB0byBjb21tdW5pY2F0Z
Q0K
x-fapi-interaction-id: 93bac548-d2de-4546-b106-880a5018460d
Content-Type: application/json
{
"Data": {
"ConsentId": "58923",
"Status": "AwaitingAuthorisation",
"CreationDateTime": "2017-06-05T15:15:13+00:00",
"StatusUpdateDateTime": "2017-06-05T15:15:13+00:00",
"Initiation": {
"InstructionIdentification": "ACME412",
"EndToEndIdentification": "FRESCO.21302.GFX.20",
"InstructedAmount": {
"Amount": "165.88",
"Currency": "GBP"
},
"CreditorAccount": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Identification": "08080021325698",
"Name": "ACME Inc",
"SecondaryIdentification": "0002"
},
"RemittanceInformation": {
"Reference": "FRESCO-101",
"Unstructured": "Internal ops code 5120101"
}
}
},
"Risk": {
"PaymentContextCode": "EcommerceGoods",
"MerchantCategoryCode": "5967",
"MerchantCustomerIdentification":
"053598653254",
"DeliveryAddress": {
"AddressLine": [
"Flat 7",
"Acacia Lodge"
],
"StreetName": "Acacia Avenue",
"BuildingNumber": "27",
"PostCode": "GU31 2ZZ",
"TownName": "Sparsholt",
"CountySubDivision": [
"Wessex"
],
"Country": "UK"
}
},
"Links": {
"Self":
"https://api.alphabank.com/open-
banking/v3.1/pisp/domestic-payment-
consents/58923"
},
"Meta": {}
}
32. 例: 認可リクエスト
32
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
GET /authorize?
response_type=code id_token
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&scope=openid payments
&nonce=n-0S6_WzA2Mj
&redirect_uri=https://api.mytpp.com/cb
&request=CJleHAiOjE0OTUxOTk1ODd.....JjVqsDuushgpwp0E.5leGFtcGxlI
iwianRpIjoiM....JleHAiOjE0.olnx_YKAm2J1rbpOP8wGhi1BDNHJjVqsDuushgpwp0E
{
"alg": "",
"kid": "GxlIiwianVqsDuushgjE0OTUxOTk"
}
.
{
"iss": "https://api.alphabank.com",
"aud": "s6BhdRkqt3",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://api.mytpp.com/cb",
"scope": "openid payments accounts",
"state": "af0ifjsldkj",
"nonce": "n-0S6_WzA2Mj",
"max_age": 86400,
“claims”: {
“userinfo”: {
"openbanking_intent_id": {"value":
"urn:alphabank:intent:58923", "essential": true}
},
“id_token”: {
"openbanking_intent_id": {"value":
"urn:alphabank:intent:58923", "essential": true},
"acr": {"essential": true,
"values": ["urn:openbanking:psd2:sca",
"urn:openbanking:psd2:ca"]}}}
}
}
}
.
<<signature>>
33. 33
• FAPI WG が “Lodging Intent Pattern” に注目
https://bitbucket.org/openid/fapi/issues/142/standardising-lodging-intent
– 事前にクライアントが認可サーバーに “intent” を
登録し、その “intent” のハンドルを認可リクエストに
付加
– 同様のパターンはUK Open BankingだけではなくBerlin
Group NextGenPSD2などにも存在
• OAuth 2.0の認可リクエストを拡張する仕様として
今後IETF OAuth WGにて議論される見込み
– OAuth 2.0 Rich Authorization Requests
https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-02
– OAuth 2.0 Pushed Authorization Requests
https://tools.ietf.org/html/draft-lodderstedt-oauth-par-00
「インテント」の標準化
Source: https://www.slideshare.net/tkudo/osw2019/7
Source: https://medium.com/oauth-2/rich-oauth-2-0-
authorization-requests-87870e263ecb
35. 35
• 連携開始の同意
• ユーザー認証
• 連携内容の同意
• 連携完了の通知
• ユーザーへの告知内容
• …
「API連携仕様」だけでは決まらないもの
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
処理開始を指示
「インテントID」を含む
認可リクエスト
認可レスポンス
トークン
リクエスト
「インテント」に
のみ行使可能な
トークンを返却
API
リクエスト
API
レスポンス
(完了)
取引内容への
承認を確認
「インテント」登録
「インテントID」返却
37. 37
• 「カスタマージャーニー」
の指針
• 各種規制(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/
38. 38
• TPP/ASPSP間の連携プロセス
– TPP側のアプリ/ブラウザから開始
– ASPSP側でのユーザー認証
– TPP側での連携完了
• 「TPPのサービス (AIS, PIS,
CBPIIs) に共通の認証方式」と
「各サービス固有の要素」とを
整理
Open Banking カスタマージャーニー
Source: https://standards.openbanking.org.uk/customer-experience-
guidelines/introduction/section-b/latest/
39. 39
• “Redirection based”
– HTTP リダイレクトによるサービス間の認証リクエスト/レスポンス連携
• “Decoupled”
– 「サービスを利用するデバイス」と「ユーザー認証に用いるデバイス」との分離
• 原則
– ASPSP(銀行)による認証: TPPのリクエストに応じて
PSU(ユーザー)のSCA (確実な本人認証) を直接行う
– 同等の認証方式: ASPSPを直接利用するときと同じユーザー認証の
しくみが利用できる
– 同等の体験: ASPSPを直接利用するときと変わらないステップ・時間で利用できる
– SCA: 単一の連携セッション中に2回以上SCAを実施しない
– 障害物の排除: TPPとの連携にあたり不要なディレイやフリクションを生じさせない
認証方式
Source:
https://twitter.com/UKOpenBanking/status/
1068548338679717889
40. 40
1. [PISP] 決済口座選択 (MUST)
2. [PISP] 決済内容通知 (MUST)
3. [PISP] サイト移動と決済内容の明示 (SHOULD)
4. [ASPSP] 認証ページへの遷移 (MUST) とASPSP直接利用時と同等の画面遷移
(MUST)
5. [ASPSP] 必要最小限に絞った決済内容表示 (MUST)
6. [ASPSP] ASPSP直接利用時と同等の認証ステップ(MUST)
7. [ASPSP] サイト移動と決済内容の明示(SHOULD)
8. [ASPSP] 決済完了ページへの遷移 (MUST)
9. [PISP] 決済完了ページへの遷移
例: Browser based redirection – PIS
PISP (Web) からASPSP(Web)に連携するケース
Source: https://standards.openbanking.org.uk/customer-experience-guidelines/authentication-methods/redirection/browser-based-redirection-pis/latest/
41. 41
1. [PISP] 決済口座選択 (MUST)
2. [PISP] 決済内容通知 (MUST)
3. [PISP] サイト移動と決済内容の明示 (SHOULD)
4. [ASPSP] ASPSPアプリ直接利用時と同等の画面遷移(MUST)
5. [ASPSP] 必要最小限に絞った決済内容表示 (MUST)
6. [ASPSP] ASPSP直接利用時と同等の認証ステップ(MUST)
7. [ASPSP] アプリ移動と決済内容の明示(SHOULD)
8. [ASPSP] 決済完了ページ/画面への遷移(MUST)
9. [PISP] 決済完了ページ/画面への遷移
例: App based redirection – PIS
モバイル端末内で、PISP(Mobile App / Web) から ASPSP(Mobile App)に連携するケース
Source: https://standards.openbanking.org.uk/customer-experience-guidelines/authentication-methods/redirection/app-based-redirection-pis/latest/
43. “Open Banking (OB) Directory” による管理
• 参加する全ての事業者(銀行と
サードパーティ事業者)が自組織
の情報をOBディレクトリに登録
• OBディレクトリはSSA(後述)
の発行や各行APIのメタデータ
(接続に必要な設定情報)を管理
→ サードパーティ事業者と銀行との
連携にかかる設定を効率化
43
Source: https://f inopolis.ru/materials-of -forum/2018/OpenBankingUpdate.pdf
44. 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に
接続可能に
44
Source:
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/
1078034771/Dy namic+Client+Registration+-+v 3.2
48. 48
• OpenID Foundation (OIDF) による、
FAPI セキュリティ・プロファイル
を適切に実装しているかを検証す
るしくみ
• Authleteはプログラム開始と同時
に認定を取得
– OIDFはこのAuthleteの設定を「今後
認定取得を行うベンダー向けの参考
情報」として紹介
• [New!] FAPI-CIBA OP認定も取得
– 2019-09-27時点で世界唯一の認定
FAPI認定プログラムによる適切な実装の担保
Source: https://openid.net/certif ication/, https://openid.net/certification/fapi_op_testing/
50. まとめ
• UK Open Bankingでは:
– OpenID FAPI/CIBAだけを使うだけではない
→ Read/Write DataAPIをその上に定義
– 「 APIと電文仕様」を定義するだけではない
→ 「顧客体験のガイドライン」を規定
– 自動API接続設定の仕様 (DCR) だけではない
→ Directoryシステムを運用し信用を仲介
50
Source: https://standards.openbanking.org.uk/
52. • API セキュリティの
“B2D” (Business-to-Developer)
SaaS プロバイダー
BackupSlides
Who is Authlete?
52
2015/09 🔵 Authlete 社設立
2016/09 🔵 Authlete UK 設立
2016/11 🔵 FINOLAB に入居
2017/03 🔵 FIBC 2017 大賞受賞
2017/05 🔵 Level39 に入居
2017/05 🔵 資金調達(シード)
2017/07 🔵 OpenID Certification 取得
2017/09 🔵 Tech in Asia Tokyo 2017 決勝
2018/02 🔵 資金調達(プレシリーズA)
2018/04 🔵 Draper Nexus B2B Summit 2018 にて IBM 賞受賞
2018/07 🔵 Japan/UK Open Banking and APIs Summit 2018 開催
2018/07 🔵 Financial-grade API (FAPI) サポート
2018/08 🔵 Open Banking Security Profile テスト合格
2019/01 🔵 『OAuth 徹底入門』 監修
2019/02 🔵 CIBA サポート
2019/04 🔵 OpenID FAPI Certification 取得
2019/09 🔵 OpenID FAPI-CIBA OP Certification 取得