FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication) #oauth #oidc #openbanking #api

2019-03-28 OAuth & OIDC 勉強会
FAPI (Financial-grade API) and
CIBA (Client Initiated Backchannel Authentication)
Tatsuo Kudo
Authlete, Inc.

Agenda
• OAuth 2.0
• FAPI
• CIBA
• Real World Use Cases
• Authlete
2

Prerequisites ;)
3
OAuth徹底入門セキュアな認可システムを適用するための原則と実践
https://www.shoeisha.co.jp/book/detail/9784798159294

About Me
• 工藤達雄 https://www.linkedin.com/in/tatsuokudo
– サン・マイクロシステムズ (1998-2008)
– 野村総合研究所 (2008-2018)
– OpenIDファウンデーション・ジャパン (2013-2014)
– NRIセキュアテクノロジーズ(2014-2018)
– Authlete (2018-)
• VP of Solution Strategy
4

OAuthの登場人物
6
User
API
Server
API Client
OAuth の「トークン」を用いたAPIアクセス
Resource
Owner
User
Agent
Authorization
Server
Resource
Server
Client

“OAuth Dance”
Authorization Code Grant Type
• 典型的には
– Resource Owner: エンドユーザー
– UserAgent: Webブラウザ
– Client: Webアプリケーション
（APIクライアント）
– Authorization Server:API認可サーバー
（兼ユーザー認証サーバー）
– Resource Server:APIサーバー
7
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server

“OAuth Dance”
0. リソースオーナーがクライアントとやりとり
8
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
エンドユーザーが
Webアプリケーションに
アクセス

“OAuth Dance”
1. クライアントが認可リクエストを開始
9
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可リクエスト
GET /authorize
?response_type=code
&client_id=s6BhdRkqt3
&scope=message.readonly
&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
Host: server.example.com

“OAuth Dance”
2. 認可サーバーがユーザー認証と同意確認
10
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
ユーザー認証
& 同意確認

“OAuth Dance”
3. 認可サーバーが認可レスポンスを返却
11
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可レスポンス
HTTP/1.1 302 Found
Location: https://client.example.com/cb
?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz

“OAuth Dance”
4. トークン取得
12
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
トークンリクエスト
POST /token HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
トークンレスポンス
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}

“OAuth Dance”
5. トークン利用
13
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
APIリクエスト
GET /resource HTTP/1.1
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
APIレスポンス

“OAuth Dance”
6. クライアントがリソースオーナーに返答
14
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
サービス提供

Naïve OAuth/API Server Does…
• 認可リクエストを受け付けたら
認可コードを返す
• 認可コードをもらったら
アクセストークンを返す
• アクセストークンつきの
APIリクエストを受け付けて
レスポンスを返す
• …もしかしてかんたん?
15
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可
リクエスト
認可
コード
認可
コードアクセス
トークン
アクセス
トークン
APIレスポンス

16Source: https://twitter.com/blhjelm/status/1055551254401736704

Financial-gradeAPI (FAPI)https://openid.net/wg/f api/
• 金融サービスのAPIに対応したOAuth適用規定と周辺仕様
• OpenID FoundationのFAPI WGにて現在策定中
– セキュリティ・プロファイル: 実装者向け草案
• Read Only API Security Profile, Read & Write API Security Profile
– 周辺仕様: ワーキングドラフト & 実装者向け草案
• JARM, CIBA
– API: 今後策定予定
• Open Data API, Read Only API, Read & Write API
18
Source: https://openid.net/wg/fapi/

FAPIセキュリティ・プロファイル
• Part 1 (Read Only)
– OAuth 2.0 適用のプラクティス
– OAuth 2.0 拡張仕様
– OIDC によるユーザー識別子の授受
• Part 2 (Read & Write): OIDC の積極的な
活用 + 新たな拡張仕様
– RequestObject,Hybrid Flow, MTLS, OAUTB
– JARM
19
OIDC拡張仕様
OIDCプラクティス
OAuth2拡張仕様
OAuth2プラクティス
Part1(ReadOnly)
Part2(Read&Write)

Security Provisions
• 認可サーバー、クライアント、
リソースサーバーそれぞれの
遵守事項チェックリスト
（のように見える）
20
Source: https://openid.net/specs/openid-financial-api-part-1.html#read-only-api-security-provisions

コンフィデンシャル・クライアントは対応必須（SHALL）、
パブリック・クライアントは対応すべき（SHOULD）
FAPI Part 1: 認可サーバー
サポートするクライアント
• 1. shall support confidential clients
• 2. should support public clients
22

Basic認証は使えない。「OAuthクライアント認証のためのMutual TLS」もしくは
「OAuth 2.0クライアント認証のためのJWTプロファイル」を用いなければならない
クライアント認証
• 3. shall provide a client secret that adheres to the
requirements in section 16.19 of [OIDC] if a symmetric key
is used
• 4. shall authenticate the confidential client at the token
endpoint using one of the following methods:
– 1. Mutual TLS for OAuth Client Authentication as
specified in section 2 of [MTLS]
– 2. client_secret_jwt or private_key_jwt as specified in
section 9 of [OIDC]
• 5. shall require a key of size 2048 bits or larger if RSA
algorithms are used for the client authentication
• 6. shall require a key of size 160 bits or larger if elliptic
curve algorithms are used for the client authentication
• 19. shall return an invalid_client error as defined in 5.2 of
[RFC6749] when mis-matched client identifiers were
provided through the client authentication methods that
permits sending the client identifier in more than one way
23

JWTを用いたOAuth 2.0クライアント認証の例
共通鍵暗号 or 公開鍵暗号により署名された情報（クレームセット）をもとに認証
24
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
クレームセット
{
"iss": "55f9f559-2496-49d4-b6c3-351a586b7484”,
"sub": "55f9f559-2496-49d4-b6c3-351a586b7484",
"aud": "https://idp-p.example.com/token",
"iat": 1418698788,
"exp": 1418698848,
"jti": "1418698788/107c4da5194df463e52b56865c5af34e5595"
}
Signed JWT
Host: idp-p.example.com
grant_type=authorization_code
&code=sedaFh
&scope=openid+email
&client_id=55f9f559-2496-49d4-b6c3-351a586b7484
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-
assertion-type%3Ajwt-bearer&
client_assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.
ew0KICAg[...omitted for brevity...].
t-_gX8JQ[...omitted for brevity...]
Signed JWT生成

MTLSを用いたOAuth 2.0クライアント認証の例
クライアントから提示されたX.509証明書の「サブジェクト識別名（DN）」をもとに認証
25
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
• TLS相互認証を行ってクライアントのX.509証明書を取得し、
その証明書のサブジェクトDNをもとにクライアントを認証
• リクエスト内のclient_idの値からクライアントを識別
• そのクライアント情報として事前登録されている「証明書の
サブジェクトDN」の値と照合し認証
• 証明書に結びつけた（バインドした）アクセストークンを返却
APIリクエスト
• TLS相互認証を行いクライアントのX.509証明書を取得
• 証明書とアクセストークンの結びつき（バインド）を確認
X.509 PKC +
client_id

redirect_uriは事前登録したリダイレクトURIと「厳密に一致」しなければならない。
またhttps以外のスキームを用いてはならない
リダイレクトURI
• 9. shall require the redirect_uri parameter in the authorization
request
• 10. shall require the value of redirect_uri to exactly match one
of the pre-registered redirect URIs
• 20. shall require redirect URIs to use the https scheme
26

認可リクエストのredirect_uri
認可サーバーはこの値をもとに認可コードなどの戻し先を決定する
27
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
GET /authorize
?response_type=code
&state=xyz
HTTP/1.1

redirect_uriチェックの不備をついた認可コードの窃取
被害者にひもづく認可コードが不正な戻し先に渡る
28
被害者
被害者の
Webブラウザ
攻撃者
Authorization
Server
Resource
Server
被害者の
認可コードを
入手
認可コード
GET /authorize
?response_type=code
&state=xyz
&redirect_uri=＜攻撃者の任意のURI＞
HTTP/1.1
偽サイトにアクセス
HTTP/1.1 302 Found
Location: ＜攻撃者の任意のURI＞
?code=＜被害者にひもづく認可コード＞
&state=xyz
ユーザー認証 & 同意確認

認可レスポンスにおける認可コードの差し替え
被害者にひもづく認可コードに差し替えることで、被害者のリソースにアクセスできるようになる
29
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
HTTP/1.1 302 Found
?code=＜攻撃者にひもづく認可コード＞
&state=xyz
認可コード
認可レスポンス（差し替え後）
GET /cb
&state=xyz
HTTP/1.1
被害者にひもづくトークンを返却
被害者にひもづくアクセストークンを
用いてAPIアクセス
被害者にひもづく認可コードを送信
認可コード
認可コード
トークン
トークン
リダイレクトを
中断して
認可コードを
差し替え

Resource
Server
Native Appsにおける戻し先の乗っ取り
カスタムURLスキームの上書きにより正当なAppではなく攻撃者Appに認可コードが渡る
30
被害者のスマートフォン
被害者
OS / 標準
ブラウザ
正当なApp
Authorization
Server
攻撃者の
App
カスタムURL
スキームを上書き
連携開始
GET /authorize
?response_type=code
&redirect_uri=＜AppのカスタムURLスキーム＞
HTTP/1.1
認可コード
HTTP/1.1 302 Found
Location: ＜AppのカスタムURLスキーム＞
&state=xyz
被害者の
認可コードを
入手
攻撃者の
Appに処理を
引き継ぎ

redirect_uriにまつわる事案の例
• Slack, Instagram
https://hackerone.com/reports/2575,http://breaksec.com/?p=6164
– redirect_uri のチェックが「前方一致」
だった
– たとえば https://google.com が設定
されていると
https://www.google.com.mx や
https://www.google.com.attacker.com も
許容していた
31
被害者
被害者の
Webブラウザ
攻撃者
Authorization
Serv er
Resource
Serv er
認可コード

ユーザー認証・認可
• 11. shall require user authentication at LoA 2 as defined in
[X.1254] or more
• 12. shall require explicit consent by the user to authorize the
requested scope if it has not been previously authorized
32
ユーザー認証の保証レベル（LoA）は2以上が必須（SHALL）。これまでに認可を受けて
いない権限（スコープ）については明示的に同意を求めることが必須（SHALL）

LoAの例
33Source: http://www.kantei.go.jp/jp/singi/it2/guide/kaisai_h20/dai2/siry ou2-2.pdf , http://www.meti.go.jp/committee/kenkyukai/shoujo/denshishomeihou/pdf /h27_002_s03_00.pdf

トークン交換
• 7. shall require [RFC7636] with S256 as the code
challenge method;
• 13. should verify that the authorization code (section 1.3.1
of [RFC6749]) has not been previously used;
– NOTE: Section 4.1.3 of [RFC6749] does not provide
guidance regarding code reuse, but this document
provides limitation on code reuse in Section 3.1.3.2 of
[OIDC].
– NOTE: If replay identification of the authorization code is
not possible, it is desirable to set the validity period of the
authorization code to one minute or a suitable short
period of time. The validity period may act as a cache
control indicator of when to clear the authorization code
cache if one is used.
• 14. shall return token responses that conform to section
4.1.4 of [RFC6749];
• 15. shall return the list of granted scopes with the issued
access token;
34
“PKCE” (Proof Key for Code Exchange by OAuth Public Clients) が必須（SHALL）

PKCEによる、認可コード差し替え攻撃対策
「認可リクエスト〜認可コード発行」と「トークンリクエスト」とをひもづけ
35
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可コード
認可コード
認可コード
中断して
認可コードを
差し替え
GET /authorize
?response_type=code
&state=xyz
&code_challenge=<code_verifierからcode_challenge_methodに従って生成した値>
&code_challenge_method=S256 HTTP/1.1
HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=＜攻撃者にひもづく認可コード＞
&state=xyz
認可レスポンス（差し替え後）
GET /cb
?code=＜被害者にひもづく認可コード＞&state=xyz HTTP/1.1
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
grant_type=authorization_code&code=＜被害者にひもづく認可コード＞
&code_verifier=<最初に生成したcode_verifierの値>
差し替えられた認可コードは
code_verifierにひもづかない
→ このトークンリクエストは不正
認可コード
発行時の
code_challenge
を記録
code_challenge
受け取り
code_challenge
code_verifier

トークン
• 16. shall provide opaque non-guessable access tokens with a
minimum of 128 bits of entropy where the probability of an
attacker guessing the generated token is less than or equal to
2^(-160) as per [RFC6749] section 10.10
– NOTE: The opaqueness requirement for the access token does not
preclude the server to create a structured access token.
36
トークンに十分なエントロピーが必須（SHALL）。ただしこれは
構造化されたアクセストークンの生成を禁止するものではないことに留意

同意管理
• 17. should clearly identify long-term grants to the user
during authorization as in 16.18 of [OIDC]
• 18. should provide a mechanism for the end-user to
revoke access tokens and refresh tokens granted to a
client as in 16.18 of [OIDC]
37
ユーザーに長期間のアクセス権限付与の許可を求める際にはそれを明確に示すべき
（SHOULD)。またトークンの取り消し機能をユーザーに提供するべき（SHOULD)

FAPI Part 1: クライアント
基本的なセキュリティ・プラクティス
• 1. shall support [RFC7636] or the mechanisms defined in
Financial-grade API - Part 2
• 2. shall use S256 as the code challenge method for the
[RFC7636]
• 3. shall use separate and distinct redirect URI for each
authorization server that it talks to
• 4. shall store the redirect URI value in the resource
owner's user-agents (such as browser) session and
compare it with the redirect URI that the authorization
response was received at, where, if the URIs do not match,
the client shall terminate the process with error
• 5. shall adhere to the best practice stated by [BCP212]
• 6. shall implement an effective CSRF protection
• If openid is not in the scope value, then it
– 9. shall include the state parameter defined in section
4.1.1 of [RFC6749].
38
PKCE, “IdP Mix-Up Attack” 対策, “OAuth 2.0 for Native Apps”, CSRF 対策の
すべてが必須（SHALL）

エンドユーザーサービスサイト「OAuth認証」サーバー
ありがちな「OAuth認証」
認可コード → アクセストークン → ユーザー識別子の順に交換してユーザーを特定
1. 「OAuth認証でログイン」をクリック
2. 「OAuth認証サーバー」にリダイレクト
3. 「ログインしてください」
4. ID/パスワードを送信
5. サービスサイトにリダイレクト
6. 認可コードを送信しアクセストークンを取得
7. アクセストークンを用いてユーザー情報APIに
アクセスし、ユーザー識別子を取得
8. 取得したユーザー識別子をもとにユーザーを
特定してログイン完了 39
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
1
2
3
4
5
6
7
8
認可コード
認可コード
トークン
トークン
ユーザー識別子

CSRF +「OAuth認証」
攻撃者にひもづく認可コードを生成
40
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
HTTP/1.1 302 Found
認可コード
中断して
認可コードを
取得
GET /authorize
?response_type=code
&redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
「IDひもづけ開始」

サービスサイトにログイン済みの被害者に「攻撃者にひもづく認可コード」を
送信させる
41
被害者
被害者の
Webブラウザ
Client
Authorization
Server
Resource
Server
認可コード
被害者に
認可レスポンスを
送信させる
認可コード
トークン
トークン
認可レスポンス（CSRF）
GET /cb
?code= ＜攻撃者にひもづく認可コード＞
HTTP/1.1
被害者はクライアントにログイン済
被害者のログイン
情報に攻撃者の
ID情報がひもづくID情報

攻撃者のID/パスワードで「OAuth認証」すると「被害者としてログイン」できる
42
攻撃者
攻撃者の
Webブラウザ
Client
Authorization
Server
Resource
Server
HTTP/1.1 302 Found
「OAuth認証開始」
認可コード
認可コード
トークン
トークン
ID情報
被害者としてログイン完了
攻撃者のID情報を返却攻撃者が被害者
のアカウントを
乗っ取る

stateパラメーターによるCSRF対策
認可リクエストの起点となるユーザーと、認可コードを送信してきたユーザーとの一致を確認
43
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
state +
認可コード
HTTP/1.1 302 Found
?code=＜エンドユーザーにひもづく認可コード＞
&state=3af23asl0989gnv
GET /authorize
?response_type=code
&state=3af23asl0989gnv
&redirect_uri= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1
state
stateの値がセッ
ションにひもづ
くかチェック
ユーザーのセッション
にひもづく値をセット

stateパラメーターにまつわる事案の例
• 某社 https://medium.com/@nahoragg/chaining-tricky -oauth-exploitation-to-stored-xss-b67eaea4aabd
(日本語による解説 https://dodosuke0920.hatenablog.com/entry /20190205-state-in-oauth)
– クラウドストレージサービス A
• API を公開していて、OAuth を実装し、state パラメーターにも対応している
• {{constructor.constructor(‘alert(1)’)()}}.jpg という名のファイルが保存可能な状態にある
– サードパーティアプリ B
• サービス A の API を呼び出してファイルを取り込む機能がある
• ファイル名の扱いにエスケープ漏れがあり、XSS 脆弱性がある
• 認可レスポンス中に state が含まれていれば検証するが、含まれていない場合は検証しない
– 攻撃パターン
1. 攻撃者が、サービス A の自身のアカウントに、細工した名前のファイルをアップロード
する。そしてアプリ B から「サービス A のファイル取り込み機能」（認可コードフ
ロー）を開始し、その過程の「認可レスポンス」を中断し、「認可コード」を取得する
2. 攻撃者が、アプリ B を利用している（ログイン済みの）被害者に、先ほど中断した
「サービス A のファイル取り込み機能」を再開するよう、CSRF 攻撃を仕掛ける
3. CSRF が成功すると、被害者はアプリ B の自身のアカウントと、サービス A の攻撃者の
アカウントとをひもづけてしまい、さらに攻撃者のファイルを取り込んでしまう
4. 被害者がアプリ B にアクセスすると、そこには攻撃者のファイルが置いてあり、XSS が
発動する
44
攻撃者被害者
1
2
3
4
アプリB
サービスA

stateパラメーターにまつわる事案の例
• Uber https://ngailong.wordpress.com/2017/08/07/uber-login-csrf-open-redirect-account-takeover/
– コールバック先 (redirect_uri) で state パラメーターをもとにリ
ダイレクトしていた
– さらに値を自由に指定できた
– state=%2Fsomewhere → state=%2F%2fgoogle.com
45

CSRF関連事案の例
• Pixiv https://inside.pixiv.blog/kobo/5962
– 攻撃者のアカウントで Weibo にログインさせる
– さらに Pixiv のアカウントひもづけフローを実行させる
– 攻撃者の Weibo アカウントで被害者になりすましてPixiv にロ
グイン可能に
46

ユーザー識別子の取得
• Further, if it is desired to obtain a persistent identifier of
the authenticated user, then it
– 7. shall include openid in the scope value
– 8. shall include nonce parameter defined in Section 3.1.2.1 of
[OIDC] in the authentication request
47
ユーザー識別子の取得にはOIDCを用いることが必須（SHALL）

クライアント認証（コンフィデンシャル・クライアント）
• In addition to the provisions for a public client, a confidential client
– 1. shall support the following methods to authenticate against the token endpoint:
• 1. Mutual TLS for OAuth Client Authentication as specified in section 2 of [MTLS]
• 2. client_secret_jwt or private_key_jwt as specified in section 9 of [OIDC]
– 2. shall use RSA keys with a minimum 2048 bits if using RSA cryptography
– 3. shall use elliptic curve keys with a minimum of 160 bits if using Elliptic Curve cryptography
– 4. shall verify that its client secret has a minimum of 128 bits if using symmetric key cryptography
48
Basic認証は使えない。「OAuthクライアント認証のためのMutual TLS」もしくは
「OAuth 2.0クライアント認証のためのJWTプロファイル」を用いなければならない

リソースへのアクセス
• 1. shall send access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750]
• 3. may send the last time the customer logged into the client in the x-fapi-auth-date header where the value is supplied as a HTTP-date as
in section 7.1.1.1 of [RFC7231]
– e.g., x-fapi-auth-date: Tue, 11 Sep 2012 19:43:31 GMT
• 4. may send the customer’s IP address if this data is available in the x-fapi-customer-ip-address header
– e.g., x-fapi-customer-ip-address: 198.51.100.119
• 5. may send the x-fapi-interaction-id request header whose value is a [RFC4122] UUID to the server to help correlate log entries between
client and server
– e.g., x-fapi-interaction-id: c770aef3-6784-41f7-8e0e-ff5f97bddb3a.
49
アクセストークンはHTTPヘッダーにて送信することが必須（SHALL）。
その他FAPI独自のヘッダーを用いてもよい（MAY）

FAPI Part 1: リソースサーバー
基本的なセキュリティ・プラクティス
• 1. shall support the use of the HTTP GET method as in Section 4.3.1 of [RFC7231];
• 2. shall accept access tokens in the HTTP header as in Section 2.1 of OAuth 2.0 Bearer Token Usage [RFC6750];
• 3. shall not accept access tokens in the query parameters stated in Section 2.3 of OAuth 2.0 Bearer Token Usage [RFC6750];
• 4. shall verify that the access token is neither expired nor revoked;
• 5. shall verify that the scope associated with the access token authorizes the reading of the resource it is representing;
• 6. shall identify the associated entity to the access token;
• 7. shall only return the resource identified by the combination of the entity implicit in the access and the granted scope and otherwise
return errors as in section 3.1 of [RFC6750];
50
アクセストークンをクエリパラメーターとして受け入れてはならない（SHALL NOT）

セキュリティ・プラクティス (cont.) + FAPI拡張
• 8. shall encode the response in UTF-8 if applicable
• 9. shall send the Content-type HTTP header Content-Type: application/json; charset=UTF-8 if applicable
• 10. shall send the server date in HTTP Date header as in section 7.1.1.2 of [RFC7231]
• 11. shall set the response header x-fapi-interaction-id to the value received from the corresponding fapi client request header
or to a [RFC4122] UUID value if the request header was not provided to track the interaction, e.g., x-fapi-interaction-id:
c770aef3-6784-41f7-8e0e-ff5f97bddb3a
• 12. shall log the value of x-fapi-interaction-id in the log entry
• 13. should support the use of Cross Origin Resource Sharing (CORS) [CORS] and or other methods as appropriate to
enable JavaScript clients to access the endpoint if it decides to provide access to JavaScript clients
51
x-fapi-interaction-id の付加が必須（SHALL）

FAPI Part 1のオープン・アイテム
(≒ Part 2への伏線)
• 7. Security Considerations
– 認可リクエスト/レスポンスの送信者認証
ができない (7.2)
– 認可リクエストの改ざん防止が十分では
ない (7.3) *
– 認可リクエストが平文のままブラウザを
経由する (7.4.1) *
– アクセストークンの盗用を防げない
(7.4.3)
52
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
認可
リクエスト
認可
コード
認可
コードアクセス
トークン
アクセス
トークン
APIレスポンス
* 認可レスポンスはIDトークンを組み合わせることにより対処可能

FAPIセキュリティ・プロファイル（再掲）
• Part 1 (Read Only)
– OAuth 2.0 適用のプラクティス
– OAuth 2.0 拡張仕様
– OIDC によるユーザー識別子の授受
• Part 2 (Read & Write): OIDC の積極的な
活用 + 新たな拡張仕様
– RequestObject,Hybrid Flow, MTLS, OAUTB
– JARM
54
OIDC拡張仕様
OIDCプラクティス
OAuth2拡張仕様
OAuth2プラクティス
Part1(ReadOnly)
Part2(Read&Write)

OpenID Connect も、かんたんそう!?
• OIDC認証リクエストを
受け付けたら
認可コードを返す
• 認可コードをもらったら
アクセストークンと
IDトークンを返す
• （クライアントは）
IDトークンを用いて
ユーザーを識別する
• アクセストークンつきの
APIリクエストを受け付けて
レスポンスを返す
55
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
OIDC認証
リクエスト
認可
コード
認可
コードアクセストークン
+ IDトークン
アクセス
トークン
APIレスポンス
IDトークン
{
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}
IDトークンに含まれる「クレーム」

• 1. shall require the request or request_uri parameter to be passed as a
JWS signed JWT as in clause 6 of [OIDC]
• 10. shall require that all parameters are present inside the signed
request object passed in the request or request_uri parameter
• 11. may support the request object endpoint as described in section 7
• 13. shall require the request object to contain an exp claim
56
認可リクエストに「リクエスト・オブジェクト」を要求することが必須（SHALL）

リクエストオブジェクト
OIDC認証リクエストへの署名や暗号化
57
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
OIDC認証リクエスト
• 値渡し
• 参照渡し
リクエストオブジェクトのクレーム
{
"iss": "s6BhdRkqt3",
"aud": "https://server.example.com",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://client.example.org/cb",
"scope": "openid",
"state": "af0ifjsldkj",
"max_age": 86400,
"claims":
{
"userinfo": { … "email": {"essential": true},…},
"id_token": { "gender": null, …
"acr": {"values": ["urn:mace:incommon:iap:silver"]}
}
}
}
GET /authorize?request=eyJhbGciOiJSUzI1NiIsImtpZCI6Imsy
YmRjIn0.ew0KICJpc3MiOiAiczZCaGRS…
GET /authorize?
request_uri=%3A%2F%2Fclient.example.org%2Frequest.jwt…
リクエストオブジェクト生成

• 2. shall require the response_type values code id_token or code id_token token
• 3. shall return ID Token as a detached signature to the authorization response
• 4. shall include state hash, s_hash, in the ID Token to protect the state value if
the client supplied a value for state. s_hash may be omitted from the ID Token
returned fromthe Token Endpoint w hen s_hash is present in the ID Token
returned fromthe Authorization Endpoint
• In addition to the provisions given in section 5.2.2, an authorization server may
protect authorization responses to clients using the "JWT Secured Authorization
Response Mode" [JARM].
• The [JARM] allow s a client to request that an authorization server encode the
authorization response (of any response type) in a JWT. It is an alternative to
utilizing ID Tokens as detached signatures for providing financial-grade security
on authorization responses.
• The authorization server should advertise support for the [JARM] response
modes using the response_modes_supported metadata parameter.
• If [JARM] is used to secure the authorization responses, the clauses 2, 3, and 4
of section 5.2.2. do not apply. For example, clients may use [JARM] in
conjunction w ith the response type code.
58
“Hybrid Flow” にし、IDトークンを “Detached Signature” として返却することが
必須（SHALL）。ただしJARMに対応している場合にはその限りではない

Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
フラグメント
取得
フラグメント
送信
(フラグメント）state,
code, id_token#
state, code,
id_token
認可レスポンスの保護
Hybrid Flow
認可コードとIDトークンを認可EPから返却
59
GET /authorize
?response_type=code%20id_token
[…]
&state=af0ifjsldkj
Detached Signatureによる検証
code
AT, RT,
ID Token
HTTP/1.1 302 Found
Location: https://api.mytpp.com/cb#
code=SplxlOBeZQQYbYS6WxSbIA
&id_token=eyJ0 ... NiJ9.eyJ1c ...
I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
Detached Signature生成

認可レスポンスの保護
Detached Signature（分離署名）
検証用の値に署名して本文と別に送る
60
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
HTTP/1.1 302 Found
&id_token=eyJ0 ... NiJ9.eyJ1c ...
I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
IDトークン（SignedJWT）を検証した上で、c_hash,
s_hashを抽出し、それぞれをもとにcode,stateを検証
{ …
"s_hash": "76sa5dd",
"c_hash": "asd097d” …
}
state=af0ifjsldkj
state
(フラグメント）state, code,
id_token (s_hash, c_hash, 署名)
{ …
"c_hash": "asd097d” …
}
IDトークン（Signed JWT）生成
state, code の値が確定
s_hash, c_hash生成
#
IDトークン（Signed JWT）として
検証できた（改ざんされていない）値
クエリパラメーターとして
受け取った値

JARM
JWT Secured Authorization Response Mode for OAuth 2.0
61
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
response (code, state, 署名)
code
AT, RT,
ID Token
GET /authorize?
response_type=code&response_mode=jwt&[…]
HTTP/1.1 302 Found
Location: https://client.example.com/cb?
response=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJpc3MiOiJodHRwczovL2FjY291bnRzLmV4YW1wbGUuY29tIiwiYXVkI
joiczZCaGRSa3F0MyIsImV4cCI6MTMxMTI4MTk3MCwiY29kZSI6IlB5eU
ZhdXgybzdRMFlmWEJVMzJqaHcuNUZYU1FwdnI4YWt2OUNlUkRTZDBRQSI
sInN0YXRlIjoiUzhOSjd1cWs1Zlk0RWpOdlBfR19GdHlKdTZwVXN2SDlq
c1luaTlkTUFKdyJ9.
HkdJ_TYgwBBj10C-aWuNUiA062Amq2b0_oyuc5P0aMTQphAqC2o9WbGSk
pfuHVBowlb-zJ15tBvXDIABL_t83q6ajvjtq_pqsByiRK2dLVdUwKhW3P
_9wjvI0K20gdoTNbNlP9Z41mhart4BqraIoI8e-L_EfAHfhCG_DDDv7Yg
Signed JWT検証
{
"iss": "https://accounts.example.com",
"exp": 1311281970,
"code": "PyyFaux2o7Q0YfXBU32jhw.5FXSQpvr8akv9CeRDSd0QA",
"state": "S8NJ7uqk5fY4EjNvP_G_FtyJu6pUsvH9jsYni9dMAJw"
}
response（SignedJWT）生成

トークン
• Sender-constrained Tokens
– 5. shall only issue authorization code, access token, and refresh token that are holder of key bound
– 6. shall support [OAUTB] or [MTLS] as a holder of key mechanism
• ID Token
– 8. shall support signed ID Tokens
– 9. should support signed and encrypted ID Token
62
発行するすべての認可コード、アクセストークン、リフレッシュトークンは
「鍵の所有者」へのバインドが必須（SHALL）。IDトークンには署名が必須（SHALL）

MTLSによる“Holder of Key”
トークンリクエスト時のクライアント証明書に、発行するアクセストークンをバインドする
63
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
• TLS相互認証を行ってクライアントのX.509証明書を取得し、
その証明書のサブジェクトDNをもとにクライアントを認証
• リクエスト内のclient_idの値からクライアントを識別
• そのクライアント情報として事前登録されている「証明書の
サブジェクトDN」の値と照合し認証
X.509 PKC +
code + client_id
client_id
code
• 証明書に結びつけた（バインドした）アクセストークンを返却
AT, RT
APIリクエスト
• TLS相互認証を行いクライアントのX.509証明書を取得
• 証明書とアクセストークンの結びつき（バインド）を確認
• トークンに含まれる or イントロスペクションの結果と
して得られる、証明書の「サムプリント」を利用
X.509 PKC + AT
X.509 PKC +
RT + client_id

ユーザー認証
• 7. shall support user authentication at LoA 3 or greater
as defined in [X.1254]
64
ユーザー認証の保証レベル（LoA）は3以上が必須（SHALL）

クライアント認証
• 12. shall require [RFC7636] with S256 as the code challenge method
for public clients only, if it supports public clients
• 14. shall authenticate the confidential client at the token endpoint using
one of the following methods (this overrides FAPI part 1 clause 5.2.2.4)
– 1. Mutual TLS for OAuth Client Authentication as specified in section 2 of [MTLS]
– 2. private_key_jwt as specified in section 9 of [OIDC]
65
クライアント認証に「Mutual TLS」もしくは「JWTプロファイル」を
用いなければならない（SHALL）。後者は公開鍵暗号のみ（client_secret_jwt禁止）

認証コンテクストとIDトークン
• Authentication Context
– 3. shall request user authentication at LoA 3 or greater by requesting
the acr claim as an essentialclaim as defined in section 5.5.1.1 of
[OIDC]
– 5. shall verify that the acr claim in an ID Token indicates that user
authentication w as performed at LoA3 or greater
– 6. shall verify that the amr claim in an ID Token contains values
appropriate for the LoA indicated by the acr claim
• ID Token
– 4. shall require JWS signed ID Token be returned fromendpoints
– 7. shall verify that the authorization response w asnot tampered using
ID Token as the detached signature
– To verify that the authorization response w as not tampered using ID
Token as the detached signature, the client shall verify thats_hash
value is equal to the value calculated fromthe state value in the
authorization response in addition to all the requirements in 3.3.2.12 of
[OIDC]
66
IDトークンに含まれる認証コンテクストの検証が必須（SHALL）。認可レスポンスの改
ざんチェックにIDトークンを “Detached Signature” として用いることが必須（SHALL）

“Holder of Key” とリクエストオブジェクト
• Holder of key
– 1. shall support [OAUTB] or [MTLS] as a holder of key
mechanism
• Note: [MTLS] shall be used with instance-specific keys
and (self-signed) certificates to bind access tokens to
the particular instance ofa public client.It is NOT used
as clientauthentication mechanisms
• Request Object
– 2. shall include the request or request_uri parameter as
defined in Section 6 of [OIDC] in the authentication
request
– 8. shall send all parameters inside the authorization
request's signed request object
– 9. shall additionally send duplicates of the
parameters/values using the OAuth 2.0 request syntax
where required by the OAuth specification
67
認可サーバーにて利用可能な、HoK (OAUTB or MTLS) と、リクエストオブジェクトの
渡しかた（request_uri or request）への対応が必須（SHALL）

コンフィデンシャル・クライアントにおける “Holder of Key” と PII
• 1. shall support [OAUTB] or [MTLS] as a holder of key mechanism (this overrides clause
5.2.3.1)
– Note: In case of confidential clients, [MTLS] can also be used as client authentication mechanism
• 2. should require both JWS signed and JWE encrypted ID Tokens to be returned from
endpoints to protect any sensitive personally identifiable information (PII) contained in the
ID Token provided as a detached signature in the authorization response
68
認可サーバーにて利用可能なHoK (OAUTB or MTLS) への対応が必須（SHALL）。認可
レスポンスとして返却するIDトークンにPIIを含む場合にはJWS+JWEが必須（SHALL）

リソースへのアクセス
• The client supporting this document shall support the
provisions specified in clause 6.2.2 of Financial-grade
API - Part 1: Read-Only API Security Profile
69
Part 1と同様（アクセストークンはHTTPヘッダーにて送信することが必須（SHALL）。
その他FAPI独自のヘッダーを用いてもよい（MAY））

セキュリティ・プラクティス + MTLS or OAUTB
• 1. shall support the provisions specified in clause 6.2.1
Financial-grade API - Part 1: Read Only API Security Profile
• 2. shall adhere to the requirements in [MTLS] or [OAUTB]
70
アクセストークンをクエリパラメーターとして受け入れてはならない（SHALL NOT）。
MTLS or OAUTBへの対応が必須（SHALL）

“Decoupled Flow”
• 「アレクサ、お店に
5,000円払って」
→ 手元のケータイに
決済サービスAppから
通知
72Source: https://www.europeanpay mentscouncil.eu/document-library /minutes-and-agendas/authentication-sca-guidance-key -topic-clarif ication-api

• TVショッピングとかで、
– 視聴者が電話で購入希望を伝える
– オペレーターに「ではお客さまのスマート
フォンに注文内容をお送りします。ご確認
をお願いします」と言われる
– 視聴者は手元のスマートフォンにきた、決
済サービスAppからの通知をみて承認する
73
Source: https://www.linkedin.com/pulse/decoupled-authentication-moto-tatsuo-kudo/

• 仮に Ponta の ID と決済できるとこのIDが紐づいてたら
– コンビニ店員「Pontaカードカモン」
– 客「はい」
– 店員「XXX円です」
– 客「CIBA Pay(ﾀﾞｯｻ)」
– 店員「はい(ﾎﾟﾁ)」
– 客のスマホ「(XXX円をローソンに支払います。
よろしいですか？)」
– 客「おk」
– 店員「支払いおわた。レシートどぞ」
ぐらいは出来そうです
74
Source: https://ritou.hatenablog.com/entry /2018/12/29/224452

Typical AuthN/AuthZ Flow from a Device
Source: Connpass, Facebook
61 3 4
2
5
7
6. ログイン完了
API
クライアント
（リライング・
パーティ）
認可・APIサーバー
（アイデンティティ・
プロバイダー）
2. 認証・認可リクエスト
3. 「ログインしてください」
4. ID/パスワード
を送信
5. 認証結果・トークン
7. トークンを使ってAPIアクセス
ユーザー
デバイス
1. ログイン開始

Decoupling AuthN from Consumption
ユーザー
クライアント
パーティ）
デスクトップ

ユーザー
クライアント
パーティ）
デスクトップ
利用

ユーザー
クライアント
パーティ）
デスクトップ
利用
スマートフォン

ユーザー
クライアント
パーティ）
デスクトップ
利用
認証・認可
リクエスト

ユーザー
デスクトップスマートフォン
クライアント
パーティ）
利用認証
認証・認可
リクエスト

ユーザー
Consumption from Another Device
クライアント
パーティ）

ユーザー
クライアント
パーティ）
POS端末

ユーザー
認証
POS端末
クライアント
パーティ）
利用
認証・認可
リクエスト

ユーザー
Consumption by Another User
クライアント
パーティ）

ユーザー
クライアント
パーティ）
デスクトップ
オペレーター

ユーザー
クライアント
パーティ）
利用認証
デスクトップ
オペレーター
認証・認可
リクエスト

AuthN Initiated by Client via Backchannel
ユーザー
3. 認証結果・トークン
1. 対象ユーザーを指定して
認証・認可リクエスト
クライアント
（リライング・パーティ）
（アイデンティティ・プロバイダー）

CIBA (Client Initiated BackchannelAuthentication)
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html
• OpenID Foundation (OIDF) が策定中の「認証フロー」の仕様
– 2017年5月 “OIDC MODRNA* CIBA Flow 1.0” 実装者向け草案が承認
• もともとはモバイル向けだったが、現在は広範なユースケースに対応
するための改良が進められている
– MODRNA WG と FAPI WG が連携
– “CIBA Core” と各種プロファイル (MODRNA, FAPI, …) の構成
• 2019-02-04 に CIBA Core Implementer’s Draft が承認
(*) Mobile Operator Discovery, Registration & Authentication

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
プロバイダー）BA EP
(*) Access Token
(**) Refresh Token
バックチャネル認証
エンドポイント

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
1
1. 認証
リクエスト
User
Identif ier

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
2
2. 受付応答
AuthN Req ID

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
2’
2’. ユーザー
認証

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
3
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
ID Token / AT* / (RT**)

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
(*) Access Token
(**) Refresh Token
API
(4)
(4) トークン
を使ってAPI
アクセス
(4)
(4) 認証結果を
利用して処理を
実行

CIBA Flow
ユーザー
Consumption
Device (CD)
Authentication
Device (AD)
クライアント
パーティ）
0
0. ユーザーの
識別子を把握
login_hint_token
id_token_hint
login_hint
1
1. 認証
リクエスト
BA EP2
2. 受付応答
API
3
(4)
(4) トークン
を使ってAPI
アクセス
(*) Access Token
(**) Refresh Token
3. 認証結果と
トークンを返却
(Poll / Ping /
Push)
(4)
(4) 認証結果を
利用して処理を
実行
User
Identif ier
AuthN Req ID
ID Token / AT* / (RT**)
2’
2’. ユーザー
認証

FAPI Adoption
• UK Open Banking
• Australian Consumer Data Right (CDR)
• その他
– Slovak Banking API Standard
https://www.sbaonline.sk/Content/f iles/projects/slovak-banking-api-standard-1_1.pdf
– MKB Bank (ハンガリー)
https://portal.sandbox.mkb.hu/api-documentation/account-info-1.0
– Payments NZ API standards
https://pay mentsdirection.atlassian.net/wiki/spaces/PaymentsNZAPIStandards/ov erview
98

UK Open Banking
https://www.openbanking.org.uk/
• 英国における「銀行API」の
共通仕様
• 2018年1月開始
• 大手9行は義務化により、そ
れ以外の銀行は自発的に採用
• 2019年2月時点で、銀行34社、
サードパーティ事業者76社が
参加
100
Source: https://www.openbanking.org.uk/about-us/news/open-banking-february-highlights/

UK Open Banking
仕様群
• 「セキュリティ・プロファイル」と各種API仕様 etc.
101
Version 3 Technical Specifications
Introduction
Open Data APIs
• ATM info
• Branch info
• Product info
• Personal Current Accounts
• Business Current Accounts
• SME Lending
• SME Credit Cards
Read / Write APIs
• Account & Transaction Info (‘read’)
• Payment Initiation (‘write’)
• CBPII (‘funds check’)
• Event (‘notifications’)
New in Version 3, launched Sept 2018:
• Covers Redirect and Decoupled Flows
• All payment accounts (incl. credit cards,
wallets, pre-paid)
• Domestic and international payments
• Multi-currency
• Single Immediate, Scheduled, File
Payments
• Confirmation of Funds
Security Profile
• FAPI Profile (redirect)
• CIBA Profile (decoupled)
• Dynamic Client Management
(onboarding)
• Based on OAuth2 and OIDC
• MTLS
• JWS
© Open Banking Limited 2018 3
Source: https://www.openbanking.org.uk/providers/standards/, https://www.w3.org/2018/Talks/cm-openbank-20181022.pptx

UK Open Banking
セキュリティ・プロファイル
• FAPI Part 2 + CIBA
– 一部は Part 1 の水準
• “Intent”
– Request Object
– Client Credentials Grant Type (OAuth 2.0)
• Mutual TLS
– サーバー間のすべての通信
102

Open Banking UK
決済指示のフロー
103
Source:
https://openbanking.atlassian.net/w iki/spaces/DZ/pages/937
754701/Payment+Initiation+API+Specification+-+v3.1

Open Banking UK 決済指示のフロー
ユーザーが許可してから決済指示を開始
104Source: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/937754701/Payment+Initiation+API+Specification+-+v3.1,
https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines-V1-1.pdf
PSU (Payment Service User) が
PISP (Payment Initiation Service Provider) に
決済指示開始を許可

「インテント」を登録するためのトークンを要求
105
(Mutual TLS, Client Credentials Grant Type)
POST /as/token.oauth2 HTTP/1.1
Host: https://authn.alphabank.com
Accept: application/json
grant_type=client_credentials
&scope=payments
&client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRw
czovL2p3dC1pZHAuZXhhbXBsZS5jb20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmN
vbSIsIm5iZiI6MTQ5OTE4MzYwMSwiZXhwIjoxNDk5MTg3MjAxLCJpYXQiOjE0OTkxODM2MD
EsImp0aSI6ImlkMTIzNDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9yZWdpc3Rlc
iJ9.SAxPMaJK_wYl_W2idTQASjiEZ4UoI7-P2SbmnHKr6LvP8ZJZX6JlnpK_xClJswAni1T
p1UnHJslc08JrexctaeEIBrqwHG18iBcWKjhHK2Tv5m4nbTsSi1MFQOlMUTRFq3_LQiHqV2
M8Hf1v9q9YaQqxDa4MK0asDUtE_zYMHz8kKDb-jj-Vh4mVDeM4_FPiffd2C5ckjkrZBNOK0
01Xktm7xTqX6fk56KTrejeA4x6D_1ygJcGfjZCv6Knki7Jl-6MfwUKb9ZoZ9LiwHf5lLXPuy
_QrOyM0pONWKj9K4Mj7I4GPGvzyVqpaZUgjcOaZY_rlu_p9tnSlE781dDLuw
Source: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/937754701/Payment+Initiation+API+Specification+-+v3.1,
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/937984109/Domestic+Payments+v3.1,
https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2
client_assertion パラメーターの内容
{
"alg": "RS256",
"kid": "12345",
"typ": "JWT"
}
.
{
"sub": "s6BhdRkqt3",
"exp": 1499187201,
"iat": 1499183601,
"jti": "id123456",
"aud": "https://authn.alphabank.com/as/token.oauth2"
}
.
<<signature>>

「インテント」登録のためのトークンを返却
106
Content-Length: 1103
Content-Type: application/json
Date: Mon, 26 Jun 2017 15:18:28 GMT
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"expires_in": 3600,
"token_type": "bearer",
"scope":"payments"
}

「インテント」登録
107
PISPがASPSPに「決済指示に関する同意」を送信
(Mutual TLS, Detached JWS, POST)
POST /domestic-payment-consents HTTP/1.1
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA
x-idempotency-key: FRESCO.21302.GFX.20
x-jws-signature:
TGlmZSdzIGEgam91cm5leSBub3QgYSBkZXN0aW5hdGlvbiA=..T2ggZ29vZCBldmVuaW5nIG1yIHR5bGVyIGdvaW5nIGRvd24gPw==
x-fapi-financial-id: OB/2017/001
x-fapi-customer-last-logged-time: 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
{
"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"
}
}
}

Open Banking UK
“201 Created”
108
「決済指示に関する同意」リソースのIDを返却
HTTP/1.1 201 Created
x-jws-signature: V2hhdCB3ZSBnb3QgaGVyZQ0K..aXMgZmFpbHVyZSB0byBjb21tdW5pY2F0ZQ0K
{
"Data": {
"ConsentId": "58923",
"Status": "AwaitingAuthorisation",
"CreationDateTime": "2017-06-05T15:15:13+00:00",
"StatusUpdateDateTime": "2017-06-05T15:15:13+00:00",
"Initiation": {
"Amount": "165.88",
"Currency": "GBP"
},
"Name": "ACME Inc",
},
}
}
},
"Risk": {
"AddressLine": [
"Flat 7",
"Acacia Lodge"
],
"Wessex"
],
"Country": "UK"
}
},
"Links": {
"Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payment-consents/58923"
},
"Meta": {}
}

request パラメーターの内容
GET /authorize?
response_type=code id_token
&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",
"response_type": "code id_token",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://api.mytpp.com/cb",
"scope": "openid payments accounts",
"state": "af0ifjsldkj",
"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>>

銀行側でのユーザー認証と同意確認
ユーザー認証と決済指示への
同意確認

認可レスポンス（認可コードとIDトークンを返却）
HTTP/1.1 302 Found
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
id_token パラメーターの内容
{
"alg": "RS256",
"kid": "12345",
"typ": "JWT"
}
.
{
"iss": "https://api.alphabank.com",
"iat": 1234569795,
"sub": "urn:alphabank:payment:58923",
"acr": "urn:openbanking:psd2:ca",
"openbanking_intent_id": "urn:alphabank:payment:58923",
"exp": 1311281970,
"c_hash": "asd097d"
}
.
{
<<signature>>
}

トークン要求
(Mutual TLS, Authorization Code Grant Type)
POST /as/token.oauth2 HTTP/1.1
Host: https://authn.alphabank.com
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://api.mytpp.com/cb
&client_assertion_type=
urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRw
czovL2p3dC1pZHAuZXhhbXBsZS5jb20iLCJzdWIiOiJtYWlsdG86bWlrZUBleGFtcGxlLmN
vbSIsIm5iZiI6MTQ5OTE4MzYwMSwiZXhwIjoxNDk5MTg3MjAxLCJpYXQiOjE0OTkxODM2MD
EsImp0aSI6ImlkMTIzNDU2IiwidHlwIjoiaHR0cHM6Ly9leGFtcGxlLmNvbS9yZWdpc3Rlc
iJ9.SAxPMaJK_wYl_W2idTQASjiEZ4UoI7-P2SbmnHKr6LvP8ZJZX6JlnpK_xClJswAni1T
p1UnHJslc08JrexctaeEIBrqwHG18iBcWKjhHK2Tv5m4nbTsSi1MFQOlMUTRFq3_LQiHqV2
M8Hf1v9q9YaQqxDa4MK0asDUtE_zYMHz8kKDb-jj-Vh4mVDeM4_FPiffd2C5ckjkrZBNOK0
01Xktm7xTqX6fk56KTrejeA4x6D_1ygJcGfjZCv6Knki7Jl-6MfwUKb9ZoZ9LiwHf5lLXPuy
_QrOyM0pONWKj9K4Mj7I4GPGvzyVqpaZUgjcOaZY_rlu_p9tnSlE781dDLuw
client_assertion パラメーターの内容
{
"alg": "RS256",
"kid": "12345",
"typ": "JWT"
}
.
{
"sub": "s6BhdRkqt3",
"exp": 1499187201,
"iat": 1499183601,
"jti": "id123456",
"aud": "https://authn.alphabank.com/as/token.oauth2"
}
.
<<signature>>

トークン返却
HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"expires_in": 3600
}

Decoupled Flow (CIBA)
Decoupled (CIBA) の場合

Funds Confirmation リクエスト
Funds Confirmation リクエスト
(Mutual TLS)
GET /domestic-payment-consents/58923/funds-confirmation HTTP/1.1
Authorization: Bearer SlAV32hkKG
レスポンス
HTTP/1.1 200 OK
{
"Data": {
"FundsAvailableResult": {
"FundsAvailableDateTime": "2017-06-05T15:15:23+00:00",
"FundsAvailable": true
}
},
"Links": {
"Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payment-consents/58923/funds-
confirmation"
},
"Meta": {}
}

Open Banking UK決済指示のフロー
Payment Order
116
Payment Orderリクエスト (Mutual TLS)
POST /domestic-payments HTTP/1.1
Authorization: Bearer SlAV32hkKG
x-idempotency-key: FRESNO.1317.GFX.22
x-jws-signature:
TGlmZSdzIGEgam91cm5leSBub3QgYSBkZXN0aW5hdGlvbiA=..T2ggZ29vZCBldmVuaW5nIG1yIHR5bGVyIGdvaW5nIGRvd24gPw==
{
"Data": {
"Initiation": {
"Amount": "165.88",
"Currency": "GBP"
},
"Name": "ACME Inc",
},
}
}
},
"Risk": {
"AddressLine": [
"Flat 7",
"Acacia Lodge"
],
"Wessex"
],
"Country": "UK"
}
}
}

Open Banking UK決済指示のフロー
Payment Order
117
レスポンス
HTTP/1.1 201 Created
{
"Data": {
"DomesticPaymentId": "58923-001",
"Status": "AcceptedSettlementInProcess",
"CreationDateTime": "2017-06-05T15:15:22+00:00",
"StatusUpdateDateTime": "2017-06-05T15:15:13+00:00",
"Initiation": {
"Amount": "165.88",
"Currency": "GBP"
},
"Name": "ACME Inc",
},
}
}
},
"Links": {
"Self": "https://api.alphabank.com/open-banking/v3.1/pisp/domestic-payments/58923-001"
},
"Meta": {}
}

完了
118
決済指示完了

UK Open Banking
“Open Banking Directory” による管理
• 参加する全ての事業者（銀行とサー
ドパーティ事業者）が自組織の情報
をOBディレクトリに登録
• OBディレクトリは公開鍵証明書の
発行や各行APIのメタデータ（接続
に必要な設定情報）を管理
→ サードパーティ事業者が容易に複数
行のAPIに接続可能に
119

UK Open Banking
Dynamic Client Registration
• Open Banking Directoryなどが
“Software Statement
Assertion” を発行
• これを用いてTPPがASPSPに
自身のAPIクライアントを動的
に登録
120
Source: https://openbanking.atlassian.net/wiki/spaces/DZ/pages/131236509/The+Open+Banking+Directory +-+v 1.2

AUSTRALIAN CONSUMER DATA RIGHT
(CDR)
121

Consumer Data Right (CDR)
• 豪州における消費者の権利拡大の動き
• 製品やサービスの比較・切り替えをしやす
くすることにより、価格の適正化と製品・
サービスの革新につなげる
• 業種ごとに適用を進める。第一弾が銀行業
界（「オープン・バンキング」）。大手4行
に義務化。それ以外の銀行も追って対象と
なる
• 2019年7月1日からパイロット開始
• その後エネルギー、通信業界が続く
122Source: https://static.treasury.gov.au/uploads/sites/1/2018/05/t286983_consumer-data-right-booklet.pdf

CDR Information Security Profile
https://github.com/ConsumerDataStandardsAustralia/infosec
• ベースはFAPI-RW, FAPI-CIBA, OIDC（というかUK Open
Banking）。Hybrid Flow と CIBA Flow の 2 つに対応
• ロール: Data Holder , Data Recipient, Registry
• Client Authenticationはprivate_key_jwt のみ。クライアン
ト種別はコンフィデンシャル・クライアントのみ
• ID Token: 暗号化必須。acr の代わりに vot & vtm を利用可
能。sub の値は PPID であることが必須。同一人物でも業
務とプライベートでは識別子を変えるべき
• Levels of Assurance (LoAs): LoA と Credential Level の詳
細は TDIF に記述。Vectors of Trust にも対応
• Data Recipient と Data Holder との通信は全部双方向 TLS
• HoK のしくみは MTLS のみ（OAUTB はサポート禁止）
• Request Object に cdr_consent_id クレーム必須
• Client Registration Endpoint: Software Statement を含む
Signed JWT を POST
• Consent: 現時点では、Data Holder が用意した同意の API
エンドポイントを使って、Data Recipient が
cdr_consent_id を採番してもらって、その後の同意管理を
行う
123

Authlete: BaaS for API Authorization Service
https://www.authlete.com/
✓ BaaS (Backend as a Service)として利用可能であり
導入・運用が容易
✓ OAuth 2.0 / OIDC関連仕様を網羅した実装
✓ ユーザーからのフィードバックに基づいて
仕様の先を行く機能群を実装
✓ 関連仕様の専門家集団が設計・運用
OAuth/OIDC実装者の課題洞察から誕生した
「認可サーバ構築用APIサービス」
125

ワールドワイドに多数の利用実績。有力企業様も活用
126
採用実績例
コンシューマーIAMソリューション
「Uni-ID Libra」の認可エンジンとして採用
ユーザープロファイル（地域別）
Grand Prize Winner
ヘルスケアサービス「ルナルナ」等で採用
API 公開基盤「Resonatex」に採用
銀行APIの認可基盤として採用
各種サービスの認可サーバとして採用
IBM 賞
受賞歴
49%
21%
14%
12% 3% 1% Japan
North America
Europe
Asia
IoTプラットフォームにて採用
銀行APIの認可基盤として採用

API認可・公開基盤
APIクライ
アント
既存システム
Authleteによる認可サーバー構築アーキテクチャ
127
Webサイト
携帯端末
ネットワーク
デバイス
認可サーバー
認可ロジック
（認可判定）
ユーザー
認証
同意確認権限管理
APIサーバー
/data /function /transaction
Authlete
認可
バック
エンド
API 認可情報
DB
API認可リクエスト
（トークン取得）
APIアクセス
(トークン利用)
認可状態確認
（トークン検証など）
OAuth/OIDC処理リクエスト（認可コード/トークン発行など）
認可
フロント
エンド
既存の認証/同意/
権限等と認可サー
バーとを分離
Authleteに依存することなく
自由に認可ロジックを実装可能
APIサーバと
認可サーバの
構築・運用を分離
面倒なOAuth/OIDC処理
と認可情報（トークン）
管理を外部化
/…
認可サーバー
構築に必要な
ライブラリを
OSSにて提供

APIゲートウェイとの連携
APIリクエストに含まれるトークンの検証をAuthleteが実施
128
© 2018 Authlete, Inc.
API認可・公開基盤
既存システム
認可サーバー
認可ロジック
（認可判定）
ユーザー
認証
同意確認権限管理
認可
バック
エンド
API 認可情報
DB
API認可リクエスト
（トークン取得）
APIアクセス
(トークン利用)
認可状態確認
（トークン検証など）
OAuth/OIDC処理リクエスト
（リクエスト検証、レスポンス生成、認可コード/トークン発行など）
認可
フロント
エンド
APIゲートウェイ
（Apigee, AWS, Azure, …)
API Server
APIクライ
アント
Webサイト
携帯端末
ネットワー
ク
デバイス

FAPI / CIBA をサポート!
129
FAPIサポート (2018-07-24)
• UK Open Banking Security Profile
Conformance に掲載 *
CIBAサポート (2019-02-13)
• CIBA テストスイートのベータ版をクリア
した世界初のソリューション **
* https://openbanking.atlassian.net/wiki/spaces/DZ/pages/126321042/Open+Banking+Security +Prof ile+Conf ormance
** Source: f intechlabs.io 社（英国の Open Banking において FAPI および CIBA のテストスイートを開発）

リソース
• Webサイト / ソーシャルメディア
– https://www.authlete.com/, https://www.facebook.com/authlete,https://twitter.com/authlete_jp
• トライアル登録・ご利用ガイド
– https://so.authlete.com/accounts/signup,
https://www.authlete.com/documents/getting_started
• APIリファレンス・認可サーバー構築ライブラリ
– https://docs.authlete.com/,https://github.com/authlete,https://kb.authlete.com
• Authleteを用いたFAPI / CIBA 実装の手引き
– https://qiita.com/TakahikoKawasaki/items/83c47c9830097dba2744
– https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3
– https://qiita.com/hidebike712/items/8fc2938055d0b49cfc0a
130

まとめ
• Open Standard: FAPI and CIBA
• Industry Adoption: UK Open Banking and Australian
CDR
• Solution: Authlete!
132

FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication) #oauth #oidc #openbanking #api

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication) #oauth #oidc #openbanking #api

Similar to FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication) #oauth #oidc #openbanking #api (20)

More from Tatsuo Kudo

More from Tatsuo Kudo (20)

FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication) #oauth #oidc #openbanking #api