Financial Grade OAuth & OpenID Connect

Nomura Research Institute
Nat Sakimura (@_nat_en)
Chairman of the Board, OpenID Foundation
Research Fellow, Nomura Research Institute
#apidays
Financial Grade OAuth & OpenID Connect
• OpenID® is a registered trademark of OpenID Foundation.
• *Unless otherwise noted, all the photos and vector images are licensed by GraphicStocks.
14th December 2016

© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
2
Nat Sakimura
Author of:
OpenID Connect Core 1.0
JSON Web Token [RFC7519]
JSON Web Signature [7515]
OAuth PKCE [RFC7636]
OAuth JAR [forthcoming]
Etc.
Editor of:
ISO/IEC 29184 Guidelines for online notice and
consent
ISO/IEC 29100 AMD: Privacy Framework
ISO/IEC 27551 Requirements for attribute based
unlinkable entity authentication
Etc.
• Research Fellow,
Nomura Research Institute
• Chairman of the Board,
OpenID Foundation
• Chair, Financial API WG
• Head of Japanese delegation to
ISO/IEC JTC 1/SC 27/WG5
• Liaison Officer from ISO/IEC JTC
1/SC 27/WG5 to OECD/SPDE
• .. and an amateur flutist
(https://youtu.be/3gTCQhTcXL0)
• https://nat.Sakimura.org/
• @_nat_en (English)
• @_nat (Japanese)
• Linked.in/natsakimura
• https://www.linkedin.com
/in/natsakimura
• https://ja.wikipedia.org/w
iki/崎村夏彦
(courtesy of Hired
@ APIDays 2016)

3
In the era of mobile,
OAuth 2.0 is the protocol of the choice
for API protection.
3

4
Problems Solved?

5
“Building blocks needs to be
combined correctly. Just saying
#oauth does not do the job.”
5
-- Mark O’Neill, Gartner
(SOURCE) Photo taken by Nat Sakimura @APIDays on 13th Dec. 2016
@APIDays Paris 2016

6
OAuth 2.0 is a framework
6

7
So that it can span across various service environments
7
stake
Environment controlhigh Low
high
Low
As a framework, it
covers all quadrants

8
But you need to profile it to suit the specific situation
8
stake
Environment controlhigh Low
high
Low
Social sharing
Closed circuit
Factory
application
Financial API –
Read & Write
Financial API –
Read only
For example:
Naïve
implementation
choice OK
Bearer token Not
OK
Not OK (IMHO)
Not all security requirements
need to be covered by OAuth
You got to be darn
careful in the
uncontrolled
environment such as
open internet.

9
To create such profile for Financial APIs, there
are multiple factors that you actually have to
take care of,
9
many of which are often ignored and results in
awfully insecure OAuth 2.0 implementations.

10
OAuth’s primary security assumption is that there
is only 1 Authz Server per client:
 In case of a Personal Finance Management Software/Client,
it will necessarily have multiple Authz Servers.
 Make sure to have virtual separation, i.e., having different redirect endpoints
for each server to avoid Authz server mix-up attack etc.
v.s.
C1
O
C1R
U
A
A1Z
C2R
C2
O
A2Z
1 Authz Server / client Model
C2R
C1
O
C1R U
A
A1Z
C2
O
A2Z
n Authz Server / client Model

11
Message Authentication Problems
Communication through UA are not authenticated and thus can be tainted, but
often used without taint check.
Neither ‘code’ nor ‘state’ can be taken at its face value, but we do...
C1O
C1R
UA A1Z
TLS terminates here.
Not authenticated
(response_type, client_id,
redirect_uri, scope, state)
Not authenticated
(code, state)

12
Message Source Authentication Problems
Since the authorization request and response goes through the browser, the
receiving ends cannot be sure of who is the real sender.
C1O
C1R
UA A1Z
A1Z cannot verify that the
Authz request is from C1O
C1R cannot verify that the
Authz response is from C1O

13
Message Destination Authentication Problems
We are in a mobile app world, right?
“Code phishing” on public clients a.k.a. mobile apps
Custom scheme etc. can be hijacked by malware on the device.
It has been exploited against popular apps.
RFC7636 OAuth PKCE exists for the mitigation of this problem.
13
Good
App
Bad App
UA A1Z
Redirect uri = goodapp://
I am
goodapp!

14
Identity and authentication problems
14
OAuth has no notion of user identity.
User authentication is “out of scope”.

1515Created by @nishantk

16
Message confidentiality problems
Authorization request is not encrypted in the application layer thus can be seen by
the Man-in-the-browser etc.
And we know that malware abounds.
The most popular Online Banking attack in Japan since 2014 is man-in-the-browser.
C1O
C1R
UA A1Z
Malware can see the payload

17
Token Phishing / Token Replay
Clients sends token requests and resource requests to forged/compromised
servers. Then, these servers can act as a hostile client to replay the request.
E.g.,
▪ Sending a fake email to developer that the endpoints has been changed. (We know that about 1 in 20
trained engineer gets phished.)
▪ Combination of TLS certs mis-issuances and DNS spoofing, etc.  there seems to be real examples for
the attacks against banks.
17
Client
XYZ
Attack
er
ABC
Bank
Hi I am
ABC
Bank API
Hi I am
Client
XYZ

1818

19
So, how do we solve?
19

20
OpenID Foundation
Financial API WG (FAPI WG)
20

21
Purpose
The goal of FAPI is to provide JSON data schemas, REST APIs,
and security & privacy recommendations and protocols to:
21
JSON REST
OAuth
OpenID Connect
(SOURCE) ODI OBWG: The Open Banking Standard (2016)

22
Enable
applications to utilize the data stored in the financial account,
applications to interact with the financial account, and
users to control the security and privacy settings.
Both commercial and investment banking account as well as
insurance, and credit card accounts are to be considered.
(Source) OpenID Foundation Financial API WG draft charter

23
Why OpenID Foundation?
• Authors of OAuth, JWT, JWS, OpenID
Connect are all here.
Right
People
• Royalty Free, Mutual Non-Assert, so
that everyone can use it freely.Right IPR
• Free to join WGs. (Sponsors welcome)
• WTO TBT Compliant Process.
Right
Structure
23

24
Working Together
24
OpenID FAPI
UK Implementation Entity
(Chair)
(Co-Chair)(Co-Chair)
(UK IE Liaison)

25
In a IPR safe and Completely Open Environment
IPR regime
Mutually assured patent non-assert
Trademark (OpenID®) control against false claim of
the spec support
Certification support to reinforce the interoperability
Completely Open Environment
Free of charge to join the WG as long as you file the
IPR agreement
Bitbucket (git) to track the changes
▪ File an issue and send a pull request!
Made possible by these sponsors!
25
Sustaining corporate members (board members
Corporate members
Non-profit members

26
Current Spec Structure
Financial Services – Financial API --
Part 1: Read Only API Security Profile
Part 2: Read and Write API Security Profile
Part 3: Open Data API
Part 4: Protected Data API and Schema - Read only
Part 5: Protected Data API and Schema - Read and Write
26
Public Review Period
Swagger file will be
provided
provided
provided

2727
Tasting tour of the FAPI Security Profiles

28
Financial Services – Financial API - Part 1: Read Only API Security Profile
1. Scope
2. Normative references
3. Terms and definitions
4. Symbols and Abbreviated terms
5. Read Only API Security Profile
5.1 Introduction
5.2 Read Only API Security Provisions
▪ 5.2.1 Introduction
▪ 5.2.2 Authorization Server
▪ 5.2.3 Public Client
▪ 5.2.4 Confidential Client
6. Accessing Protected Resources
6.1 Introduction
6.2 Read only access provisions
▪ 6.2.1 Protected resources provisions
6.2.2 Client provisions
7. Security Considerations
7.1 TLS Considerations
7.2 Message source authentication failure
7.3 Message integrity protection failure
7.4 Message containment failure
▪ 7.4.1 Authorization request and response
▪ 7.4.2 Token request and response
▪ 7.4.3 Resource request and response
8. Privacy Considerations
8.1 Privacy by design
8.2 Adhering to privacy principles
9. Acknowledgement
10. Bibliography
28
ISO way of
saying MUST +
SHOULD

29
5.2.2 Authorization Server
The Authorization Server
shall support both public and confidential clients;
shall provide a client secret that adhears to the requirements in section 16.19 of OIDC if symmetric
key is used;
shall authenticate the confidential client at the Token Endpoint using one of the following methods:
TLS mutual authentication TLSM;
JWS Client Assertion using the client_secret or a private key as specified in section 9 of OIDC;
shall require a key of size 2048 bits or larger if RSA algorithms are used for the client authentication;
shall require a key of size 160 bits or larger if elliptic curve algorithms are used for the client
authentication;
shall support RFC7636 with S256 as the code challenge method;
shall require Redirect URIs to be pre-registered;
shall require the redirect_uri parameter in the authorization request;
shall require the value of redirect_uri to exactly match one of the pre-registered Redirect URIs;
shall require user authentication at LoA 2 as defined in X.1254 or more;
29

30
… continued
shall require explicit consent by the user to authorize the requested scope if it has not been previously authorized;
shall verify that the Authorization Code has not been previously used if possible;
shall return the token response as defined in 4.1.4 of RFC6749;
shall return the list of allowed scopes with the issued access token;
shall provide opaque, non-monotonically increasing or non-guessable access tokens with a minimum of 128 bits as
defined in section 5.1.4.2.2 of RFC6819.
should clearly identify long-term grants to the user during authorization as in 16.18 of OIDC; and
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.
NOTE: The Financial API server may limit the scopes for the purpose of not implementing certain APIs.
NOTE: Section 4.1.3 of RFC6749 does not say anything about the code reuse, but this document is putting
limitation on it as per 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.
30

31
… continued
Further, if it wishes to provide the authenticated user's identifier to the client in the token response,
the authorization server
shall support the authentication request as in Section 3.1.2.1 of OIDC;
shall perform the authentication request verification as in Section 3.1.2.2 of OIDC;
shall authenticate the user as in Section 3.1.2.2 and 3.1.2.3 of OIDC;
shall provide the authentication response as in Section 3.1.2.4 and 3.1.2.5 of OIDC depending on
the outcome of the authentication;
shall perform the token request verification as in Section 3.1.3.2 of OIDC; and
shall issue an ID Token in the token response when openid was included in the requested scope as
in Section 3.1.3.3 of OIDC with its sub value equal to the value of the CustomerId of the Customer
object corresponding to the authenticated user and optional acr value in ID Token.
31

32
Then, there are provisions (=requirements
+recommendations) for clients and resource
as well…
32
And that is only for Read Only use cases.
Further provisions will be defined in Write Access cases.

33
E.g., if you look at “7. Security considerations”
7.2 Message source authentication failure
 Authorization request and response are not authenticated. For a higher risk scenarios, it should be taken care of. See
Part 2, which uses request object to achieve the message source authentication.
7.3 Message integrity protection failure
 Authorization request is not message integrity protected thus request tampering and parameter injection are possible.
Where the protection is desired, it should use Part 2.
 The response is integrity protected when ID Token is returned from the authorization endpoint.
7.4 Message containment failure
 7.4.1 Authorization request and response
▪ In this document, the authorization request is not encrypted. Thus, it is possible to leak the information contained if the browser was
infected with virus, etc.
▪ Authorization response can be encrypted as ID Token can be encrypted.
▪ It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are
compromised. Strict access control to the logs in such cases should be enforced.
 7.4.2 Token request and response
▪ It is possible to leak the information through the logs if the parameters were recorded in the logs and the access to the logs are
compromised. Strict access control to the logs in such cases should be enforced.
 7.4.3 Resource request and response
▪ Care should be taken so that the sensitive data will not be leaked through the referrer.
▪ If the access token is a bearer token, it is possible to exercise the stolen token. Since the access token can be used against multiple
URIs, the risk of it leaking is much larger than the refresh token, which is used only against the token endpoint. Thus, the lifetime of
the access token should be much shorter than that of the refresh token. Refer to section 16.18 of OIDC for more discussion on the
lifetimes of access tokens and refresh tokens.
33

34
Request Object
cf. OIDC 6. Passing Request Parameters as JWTs
= “The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)”
https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-09
Will be published as RFC soon.
In essence, you construct a JWS signed (and optionally JWE encrypted) JWT
from the authorization request parameters and send it either
By value (request parameter); or
By reference (request URI).
Protects against:
Source authentication failure;
Authorization Request Message integrity failure;
Additionally, by including the all the intended endpoints in it,
Protects against various mix-up attacks etc., which we do not know yet.
34

35
Response integrity protection
Include ‘s_hash’ as well to protect against state injection.
Security
Level
Feature Set Remarks
Request Object
w/Hybrid FLow
Authz Request protected
Hybrid Flow
(confidential client)
Authz Response protected
Code Flow
(confidential client)
Client authentication
Implicit Flow No client authentication
Plain OAuth Anonymous

36
Authorization request / response containment
Request:
Use JAR:
▪ Send JWE encrypted JWT through request parameter; or
▪ push the request object to the authorization server over TLS and use request_uri.
Response:
Use encrypted ID Token
36

37
Protection against stolen tokens
Use OAuth Token Binding (if possible)
OAuth 2.0 Token Binding
https://tools.ietf.org/html/draft-ietf-oauth-token-binding
If that is not possible, use PoP tokens.
37

38
Once complete, consider submitting it to ISO/TC 68
38
Maintainer of ISO 20022 Financial Services - universal
financial industry message scheme.
ISO 20022 Financial Services - universal financial industry message
scheme.
Part 1: Overall Methodology and Format Specifications for Inputs and
Outputs to/from the ISO 20022 Repository
Part 2: Roles and responsibilities of the registration bodies
Part 3: (TS) XML design rules
Part 5: (TS) Reverse engineering
Part 6: Message Transport Characteristics

39
Do you know if you have implemented
correctly?
39

40
Certification test will be available online
40

41
Join the group!
https://openid.net/wg/fapi/
41

Financial Grade OAuth & OpenID Connect

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Financial Grade OAuth & OpenID Connect

Similar to Financial Grade OAuth & OpenID Connect (20)

More from Nat Sakimura

More from Nat Sakimura (20)

Recently uploaded

Recently uploaded (20)

Financial Grade OAuth & OpenID Connect

Editor's Notes