FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

Copyright© Nomura Research Institute, Ltd. All rights reserved.
FAPI and beyond
仕様策定者の立場から
Nat Sakimura, Research Fellow, NRI
Chairman, OpenID Foundation
@_nat_en
🌏 https://nat.sakimura.org/
linkedin.com/in/natsakimura

JWT
JWS
OAuth PKCE
OpenID Connect

崎村夏彦（NatSakimura）
• 著作:
– OpenID Connect Core 1.0
– JSON Web Token [RFC7519]
– JSON Web Signature [7515]
– OAuth PKCE [RFC7636]
– OAuth JAR [IETF Last Call]
– Etc.
• Editor of:
– ISO/IEC 29184 Guidelines for online notice and consent
– ISO/IEC 29100 AMD: Privacy Framework – Amendment 1
– ISO/IEC 27551 Requirements for attribute based
unlinkable entity authentication
– Etc.
• OpenID Foundation 理事長
• Financial API WG議長
• ISO/IEC JTC 1/SC 27/WG5国
内小委員会主査
• WG5〜OECD/SPDEリエゾン
• 野村総合研究所上席研究員
3
• https://www.sakimura.org
• https://nat.sakimura.org
• @_nat_en (English)
• @_nat (日本語)
• https://www.linkedin.com/
in/natsakimura
• https://ja.wikipedia.org/wi
ki/崎村夏彦

APIセキュリティ
4

え、OAuth使えばそれで
問題解決なんじゃ?!

“部品を正しく組み合わせることが
重要だ。#oauth を使えば良いと言う
だけでは解決策になっていない。”
6
-- Mark O’Neill, Gartner
(SOURCE) Photo taken by Nat Sakimura @APIDays on 13th Dec. 2016
@APIDays Paris 2016
モバイルファーストの時代には,
API保護にOAuth 2.0 を使うのは当然だが、
なぜならば…

OAuth はフレームワークで、
実際に使う前にプロファイル作成が必要
This framework was designed with the clear expectation that
future work will define prescriptive profiles and extensions
necessary to achieve full web-scale interoperability.
“

一言でOAuthと言って
も、いったいどの仕様
のどのオプションを
使ったら

必要な中～高レベルのセキュリティを達成す
ることができるのか？
9
資源の価値
環境制御レベルHigh Low
High
Low
ソーシャル共有
閉域網アプリ
ケーション
金融 API
– Read & Write
e.g.,
Basic choices ok.
Bearer token Not OK
Basic choices
NOT OK
金融 API
– Read only

それに応えるのが

Financial-
Grade
Financial-Grade API (FAPI) Security Profile
11
Valueoftheresource
EnvironmentcontrollevelHigh Low
High
Low
Social sharing
Closed circuit
Factory
application
e.g.,
Basic choices ok.
No need to satisfy all the security
requirments by OAuth

金融APIのためのプロファイルを作る上で
は、複数の要因を考慮する必要がある。
12
これらの多くはしばしば無視
され、結果として非常に危な
いOAuth 2.0実装を産んで
いる。
金融機関向けのプロファイ
ルはこれら全てを解決する
必要がある。
• １クライアント１サーバの前提
• メッセージ認証（要求・応答）
• 送信者認証
• 受信者認証
• 利用者認証
• メッセージ秘匿性
• トークンフィッシング／リプレイ

パラフレーズ版 BCM*1 原則
13
4 つのクライテリア
(a) ユニークな送信者識別子 (Source Identifier)
(b) プロトコル + バージョン+ メッセージ識別子
(c) 全actor/rolesの一覧
(d) メッセージの改善検知
Basin, D., Cremers, C., Meier, S.: ProvablyRepairing the ISO/IEC 9798
Standardfor EntityAuthentication.Journalof Computer Security - Security and Trust Principles
archive Volume 21 Issue 6, 817-846 (2013)
*1

RFC6749 OAuth – code grant protocol メッセージs
• AuthorizationRequest
• AuthorizationResponse
• Token Request
• Token Response
• Assume:
– a network attacker (e.g. Browser malware)
– the crypto & TLS are not broken
– pure RFC6749 – Three parties static OAuth 2.0
14
UA
Client AS

RFC 6749の対応状況
Message Parameters (a) Unique Source
Identifier
(b) Protocol +
version identifier
(c) Full list of
actor/roles
(d) Message
Authentication
Authorization
Request
response type
client id
redirect uri
scope
state
Authorization
Response
code
state
other extension
parameters
Token Request grant type
code
redirect uri
client
credential/client id
.
Token Response access token
token_type
expires_in
refresh_token
others
15
メッセージ種別毎にパラメー
タの組み合わせは異なるの
で、 (b)= Good!
Legend
Required Parameter
OptionalParameter
Recommended Parameter
でも、喜ぶのはそこまでだ！

RFC 6749の対応状況
Identifier
(b) Protocol +
version identifier
(c) Full list of
actor/roles
(d) Message
Authentication
Authorization
Request
response type
client id
redirect uri
scope
state
Client ID is not
globally unique.
Tampering possible
OK, but it is not
integrity protected
No. No.
Authorization
Response
code
state
other extension
parameters
No source identifier OK, but it is not
integrity protected
No No
code
redirect uri
client
Client ID is not
globally unique.
OK (as long as there
is no OAuth 3.0)
No. OK
token_type
expires_in
refresh_token
others
No source identifier As above No. OK
16

RFC6749における、発信者(sender)・受信者(receiver)・
メッセージ(message)認証(authentication)の状況
17
送信者認証受信者認証メッセージ認証
認可要求 Indirect None None
認可応答 None None None
トークン要求 Weak Good Good
トークン応答 Good Good Good

18
泣けてくる

OAuth 2.0 関連のオプション機能とセキュリティレベル
セキュリ
ティ・レベ
ル
機能セット適用
JWS Authz Req
w/Hybrid Flow
認可要求の保護
Hybrid Flow*1
(confidential
client)
認可応答の保護
Code Flow
(confidential
client)
+ PKCE + MTLS
code injectionへの対応
長期Bearer Tokenの排除
Code Flow
(confidential
client)
クライアント認証
Implicit Flow クライアント認証無し
Plain OAuth Anonymous
*1) stateインジェクションの回避のために、‘s_hash’ を含む。
認証要求・応答の種類とセキュリティ・レベルトークンの種類とセキュリティ・レベル
セキュリ
ティ・レ
ベル
トークンの種類適用
記名式トークン
(Sender
Constrained
Token)
発行をうけた者しかトー
クン利用不能
持参人トークン
(Bearer Token)
盗難されたトークンも
利用可能
19
Part 1
Part 2

強化することは可能
Identifier
(b) Protocol +
version identifier
(c) Full list of
actor/roles
(d) Message
Authentication
Authorization
Request
response type
client id
redirect uri
scope
state
Unique redirect URI
+ Client ID
OK (Unique
Parameter List)
(a) + state as the UA
identifier / TBID as
UA identifier
Request signing by
JAR
Authorization
Response
code
state
other extension
parameters
Unique redirect URI OK (Unique
Parameter List)
(a) + client_id + state
as the UA identifier /
TBID as UA identifier
Response signing by
ID Token + s_hash
code
redirect uri
client
Unique redirect URI
+ Client ID
OK (Unique
Parameter List)
(a) + state as the UA
identifier / TBID as
UA identifier
TLS Protected
token_type
expires_in
refresh_token
others
Unique redirect URI OK (Unique
Parameter List)
(a) + client_id + state
as the UA identifier /
TBID as UA identifier
TLS Protected
20

FAPI RWセキュリティプロファイルでは、
送信者・受信者・メッセージ認証を強化
21
送信者認証受信者認証メッセージ認証
認可要求 Request Object Request Object Request object
認可応答 Hybrid Flow Hybrid Flow Hybrid Flow
トークン要求 Good Good Good
トークン応答 Good Good Good

PKCE [RFC7636]
+
JAR [RFCxxxx]
+
Hybrid Flow [OIDC]
+
Sender Constrained Tokens
(MTLS / Token Binding)
22
FAPI
Security
Profile
=

PKCE: RFC7636
• 認可リクエスト、認可レスポンス、トーク
ンリクエストを結びつけるための仕組み。
• １回限りの鍵を認可リクエスト送信時に生
成、そのハッシュを認可リクエストにつけ
て送る。
• 認可サーバは、このハッシュとcodeを結び
つけておく。
• トークン要求には、生成した鍵をつけて送
ることにより、一連のメッセージフローを
紐付けることができる。

JAR (JWS Authorization Request)
• 認可リクエストに署名をつけることによ
り、改ざんを検知。
• 公開鍵署名を使うことによって、証拠性
を向上、否認を難しくしている。

Hybrid Flow
• 認可応答に署名を掛ける方式
（Detatched Signature）
• IDトークンを認可応答に含めて返す。
– このIDトークンはDetached Signatureであ
り、個人を識別するものではないことに注意

Sender Constrained Token
• Bearer Token がだれでも使えるのに対して、
Sender Constrained Tokenは、対応する鍵
を持っていないと使えないタイプのトーク
ン
– MTLS https://datatracker.ietf.org/doc/draft-
ietf-oauth-mtls/
– Token Binding
https://tools.ietf.org/html/draft-ietf-oauth-
token-binding-07

It has been adopted by Open Banking UK
27

(Source) Chris Mitchel, “Banking is now more open”, Identify 2017
(出所) @UKOpenBanking https://twitter.com/UKOpenBanking/status/1017675263243702272

29
(source) https://www.zenginkyo.or.jp/fileadmin/res/news/news290713_1.pdf

US FS-ISAC
セキュリティ要件を合わせる方向
30

…そして多くのベンダーもサポート
31

ISO/TC 68へも提出
32

• ２つのImplementer’s Draft を策定。（近々Updateの予定）
Valueoftheresource
EnvironmentcontrollevelHigh Low
High
Low
Social sharing
Closed circuit
Factory
application
FinancialAPI
– Read & Write
e.g.,
Basic choices ok.
FinancialAPI
– Read only

これらはリダイレクト・アプローチを採用
• Part 1: Read Only Security Profile
• Part 2: Read and Write Security Profile
34
Redirect
Approach
Decoupled
Approach
Embedded
Approach

すべての要件に番号がついたチェックリスト形式なの
で、対応のチェックも簡単。
(source) https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md

暗号要件も絞り込んであるため、安全か
つ相互運用性高く運用可能
(source)
https://bitbucket.org/openid/f
api/src/master/Financial_API_
WD_002.md

Decoupled アプローチも検討中
• CIBA (client initiated backchannelauthentication)profile.
37
Redirect
Approach
Decoupled
Approach
Embedded
Approach
https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md

Embedded Approachもあるが…
• 第三者にベアラ・クレデンシャルを渡すのは悪い考え。
• アプリケーション・パスワード（別名：アクセストークン）を手動渡し
する方法が良いか？
38
Redirect
Approach
Decoupled
Approach
Embedded
Approach

その他にも…
39
• E.g. The
OpenBanking
OpenID
Dynamic Client
Registration
Specification

• Intent registration endpoint
40
Intent RegistrationEP
AuthorizationEP
Token EP
ServerPushing the intent,
e.g., to send $1,000 to
Bob’s account
Intent ID
AuthZ Req w/Intent ID
AuthZ Response
Redirect URI
Client

これらの実装が正しく仕様を実装しているかはど
うしたらわかるでしょうか？
41

42
（出所）https://twitter.com/IdentityMonk/status/1011960862272294912

join us at
https://openid.net/wg/fapi/

@_nat_en (English)
@_nat (Japanese)
🌏 https://nat.sakimura.org/
https://linkedin.com/in/natsakimura
https://nat.sakimura.org/youtube.php
Subscribe!

FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

Recommended

More Related Content

What's hot

What's hot(20)

Similar to FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018

Similar to FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018(20)

More from FinTechLabs.io

More from FinTechLabs.io(11)

FAPI and Beyond: From an specification author's point of view #fapisum - Japan/UK Open Banking and APIs Summit 2018 - July 24, 2018