FAPI and beyond - よりよいセキュリティのために

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

崎村夏彦（Nat Sakimura）
• 著作:
– 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
Environment control levelHigh Low
High
Low
Social sharing
Closed circuit
Factory
application
e.g.,
Basic choices ok.
No need to satisfy all the security
requirments by OAuth

© 2017 by Nat Sakimura. CC-BY-SA.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
12
II. What is OpenID Foundation
Working Together
12
OpenID FAPI
(Chair)
(Co-Chair)(Co-Chair)
(UK OBIE Liaison)
Liaison Organizations
TC 68
JTC 1/SC 27/WG 5
Nat Sakimura
Tony NadalinAnoop Saxena
fido 2.0 WG Chair
W3C Web Authn WG
Chair

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

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

RFC6749 OAuth – code grant protocol メッセージs
• Authorization Request
• Authorization Response
• 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
15
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
16
メッセージ種別毎にパラメー
タの組み合わせは異なるの
で、 (b)= Good!
Legend
Required Parameter
Optional Parameter
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
17

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

19
泣けてくる

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)
盗難されたトークンも
利用可能
20
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
21

FAPI RWセキュリティプロファイルで
は、
送信者・受信者・メッセージ認証を
強化
22
送信者認証受信者認証メッセージ認証
認可要求 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)
23
FAPI
Security
Profile
=

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

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

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

Access Token from the token endpoint
• SHOULD include at_hash in ID Token.
• ID Token signature SHALL be checked
ここまでやると、極めて強い攻撃者を前提にしても、安全であることの形式証明が
できます。
（参考）Pedram Hosseyni (SEC, University of Stuttgart): ”Formal Security Analysis of
the OpenID Financial-grade API”
https://sec.uni-
stuttgart.de/events/osw2019/agenda#talkformal_security_analysis_of_the_openid
_financial-grade_api

https://sec.uni-
stuttgart.de/_media/events/osw2019/slides/hosseyni_-
_formal-analysis-fapi.pdf

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

Formally Verified

It has been adopted by Open Banking UK
31

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

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

https://www.zdnet.com/article/australian-big-four-to-align-
their-data-sharing-ducks-ahead-of-open-banking/

35
https://www.prnewswire.com/news-releases/financial-data-
exchange-openid-foundation-take-step-towards-global-
standard-for-financial-data-sharing-300818210.html

そのほかにも
• Berlin Group
• STET
• EBA etc. へアウトリーチ

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

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

これらはリダイレクト・アプローチを採用
• Part 1: Read Only Security Profile
• Part 2: Read and Write Security Profile
39
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 backchannel authentication) profile.
42
Redirect
Approach
Decoupled
Approach
Embedded
Approach
https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_CIBA.md

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

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

• Intent registration endpoint
45
Intent Registration EP
Authorization EP
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

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

47
(SOURCE) https://openid.net/2019/02/21/openid-certification-
program-expansion-and-fee-update/

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 - よりよいセキュリティのために

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FAPI and beyond - よりよいセキュリティのために

Similar to FAPI and beyond - よりよいセキュリティのために (20)

More from Nat Sakimura

More from Nat Sakimura (20)

FAPI and beyond - よりよいセキュリティのために

Editor's Notes