Prepared for Open Banking / API Study Meetup https://obie.peatix.com/

1. 2019-09-27 オープンバンキング/API勉強会
英国オープンバンキング技術仕様の概要
工藤達雄
Authlete, Inc.

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)

14. 「不正なトークン授受」と「トークンの不正利用」の防止
14
Fintech事業者
攻撃者
金融機関
OAuth 2.0アクセス認可リクエスト
認可レスポンス・トークン付与
トークン付きAPIリクエスト（参照・更新）
r電子署名により真正性を担保し
不正なトークン授受を防止
トークン窃取
双方向TLS (SSL)により
リクエスト送信者を特定し
トークンの不正利用を防止
窃取したトークンを用いた
「なりすましアクセス」を
検知しリクエストを拒否

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

34. Customer Experience Guidelines

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にて提供

54. Thank You
www.authlete.com
www.linkedin.com/in/tatsuokudo