英国オープンバンキング技術仕様の概要
10 likes2,584 views
Prepared for Open Banking / API Study Meetup https://obie.peatix.com/
![例: 「インテント」登録
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"
}
}
}](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-30-320.jpg)
![例: 「インテント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": {}
}](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-31-320.jpg)
![例: 認可リクエスト
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>>](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-32-320.jpg)
![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/](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-40-320.jpg)
![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/](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-41-320.jpg)
![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/](https://image.slidesharecdn.com/ukopenbankingtechoverview-190927050221/85/-48-320.jpg)
More Related Content
What's hot (20)
Similar to 英国オープンバンキング技術仕様の概要 (20)
More from Tatsuo Kudo (16)
英国オープンバンキング技術仕様の概要
- 2. The Open Banking Standard https://standards.openbanking.org.uk/ 2
- 3. エンドユーザー・銀行・サードパーティの関係 3 User エンドユーザー API Onboarding （API接続設定） API Access（APIアクセス） ASPSP 銀行 TPP サードパーティ
- 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
- 6. API Access (OpenID FAPI / CIBA, Read / Write Data API)
- 7. FINANCIAL-GRADE API (FAPI) API Access
- 8. OAuth: トークンを用いたアクセス権移譲の仕様 8 ユーザー 当人確認と同意確認を 直接行うことができる （ID/PW,モバイルApp, 専用デバイス、…） 銀行 「アクセストークン」を用いたAPIアクセス Fintech 事業者 銀行のログイン情報を 渡さずに利用できる ✓ 口座情報 ✓ 送金機能 ✓ 与信情報 ✓ 口座一括管理 ✓ 入金・送金 ✓ 決済 API公開 ⇒ 売上・集客拡大 API利用 ⇒ 新サービス創出 ユーザーに関する口座情報や 決済機能を活用できる ✓ 複数口座をまとめ て管理したい ✓ 振込処理をかんた んにしたい ✓ 銀行口座を決済に 使いたい
- 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
- 16. CIBA API Access
- 17. 17 “Redirect Flow” Source: マネーフォワード, Google ユーザー ユーザー・エージェント 1. 「外部サイトで ログイン」 2. リダイレクト 4. リダイレクト 3. 認証
- 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の参考情報
- 24. READ/WRITE DATA API API Access
- 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&…
- 28. 「インテント」の導入 28 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス （完了） 取引内容への 承認を確認 「インテント」登録 「インテントID」返却 Resource Owner User Agent Client Authorization Server Resource Server （スタート） (OAuth) 認可リクエスト (OAuth) 認可レスポンス (OAuth) トークン リクエスト (OAuth) トークン レスポンス (OAuth) API リクエスト (OAuth) API レスポンス （完了） ユーザー認証・ アクセス承認
- 29. 29 • サードパーティが銀行のAPI に、口座情報取得や決済指図 伝達などの「インテント」を 事前登録 • 登録された内容を利用者が 銀行のWebサイトや アプリにて確認・承認 • 承認後、サードパーティが 「インテント」の内容の実行 を銀行のAPIにリクエスト インテントによる「取引単位」のアクセス認可 Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス （完了） 取引内容への 承認を確認 「インテント」登録 「インテントID」返却
- 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」返却
- 36. 連携の組み合わせごとにバラバラな顧客体験 36 Source: https://blog.scottlogic.com/2018/08/24/the-ux-of-consent-models-in-open-banking.html (日本語訳: https://dodosuke0920.hatenablog.com/entry /20190121-the-ux-of -consent-models-in-open-banking) Bank of Scotland & Yolt RBS & Yolt Monzo & Yolt
- 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/
- 42. Directory / Dynamic Client Registration
- 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
- 45. Solution Example for Implementation
- 46. Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス （完了） 取引内容への 承認を確認 「インテント」 登録 「インテントID」 返却 FAPI (+ Open Banking) が求めるOAuth/OIDC実装 46 動的なクライ アント登録 クライアント 登録完了 動的なクライアント登録 ・Dynamic ClientRegistration w/ Software StatementAssertion (SSA) トークンリクエスト処理+ アクセストークン検証 ・OAuth ClientCredentials Grantw/ MTLS ・Token Introspection 認可リクエスト処理 ・RequestObject 認可コード発行 ・OIDC Hybrid Flow / JARM トークンリクエスト処理 ・ClientAuthentication w/ MTLS ・Sender-constrained Token アクセストークン検証 ・ClientAuthentication w/ MTLS ・Sender-constrained Token ・Token Introspection
- 47. Resource Owner User Agent Client Authorization Server Resource Server 処理開始を指示 「インテントID」を含む 認可リクエスト 認可レスポンス トークン リクエスト 「インテント」に のみ行使可能な トークンを返却 API リクエスト API レスポンス （完了） 取引内容への 承認を確認 「インテント」 登録 「インテントID」 返却 動的なクライ アント登録 クライアント 登録完了 47 OAuth/OIDCソリューションを用いた実装例 Authlete API 動的な クライアント登録 認可リクエスト 処理 アクセス トークン 検証 認可サーバーと リソースサーバーに おける複雑な処理を 外部サービス （Authlete）に委託 トークンリクエスト処理 + アクセストークン検証 認可コード発行 トークン リクエスト処理
- 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/
- 49. まとめ
- 50. まとめ • UK Open Bankingでは: – OpenID FAPI/CIBAだけを使うだけではない → Read/Write DataAPIをその上に定義 – 「 APIと電文仕様」を定義するだけではない → 「顧客体験のガイドライン」を規定 – 自動API接続設定の仕様 (DCR) だけではない → Directoryシステムを運用し信用を仲介 50 Source: https://standards.openbanking.org.uk/
- 51. Backup Slides
- 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 取得
- 53. API認可・公開基盤 APIクライ アント 既存システム BackupSlides Authleteを活用した認可サーバーの構築 53 Webサイト 携帯端末 ネットワーク デバイス 認可サーバー 認可ロジック （認可判定） ユーザー 認証 同意確認 権限管理 APIサーバー /data /function /transaction Authlete 認可 バック エンド API 認可情報 DB API認可リクエスト （トークン取得） APIアクセス (トークン利用) 認可状態確認 （トークン検証など） OAuth/OIDC処理リクエスト（認可コード/トークン発行など） 認可 フロント エンド 既存の認証/同意/ 権限等と認可 サーバーとを分離 Authleteに依存することなく 自由に認可ロジックを実装可能 APIサーバと 認可サーバの 構築・運用を分離 面倒なOAuth/OIDC処理 と認可情報（トークン） 管理を外部化 /… 認可サーバー 構築に必要な ライブラリを OSSにて提供