SlideShare a Scribd company logo
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)
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
3
In the era of mobile,
OAuth 2.0 is the protocol of the choice
for API protection.
3
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
4
Problems Solved?
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
6
OAuth 2.0 is a framework
6
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
7
So that it can span across various service environments
7
stake
Environment controlhigh Low
high
Low
As a framework, it
covers all quadrants
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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.
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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.
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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)
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
TLS terminates here.
A1Z cannot verify that the
Authz request is from C1O
C1R cannot verify that the
Authz response is from C1O
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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!
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
14
Identity and authentication problems
14
OAuth has no notion of user identity.
User authentication is “out of scope”.
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
1515Created by @nishantk
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
TLS terminates here.
Malware can see the payload
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
1818
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
19
So, how do we solve?
19
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
20
OpenID Foundation
Financial API WG (FAPI WG)
20
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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)
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
24
Working Together
24
OpenID FAPI
UK Implementation Entity
(Chair)
(Co-Chair)(Co-Chair)
(UK IE Liaison)
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
Swagger file will be
provided
Swagger file will be
provided
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
2727
Tasting tour of the FAPI Security Profiles
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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.
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
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
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
39
Do you know if you have implemented
correctly?
39
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
40
Certification test will be available online
40
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
41
Join the group!
https://openid.net/wg/fapi/
41

More Related Content

Financial Grade OAuth & OpenID Connect

  • 1. 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
  • 2. © 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 3 In the era of mobile, OAuth 2.0 is the protocol of the choice for API protection. 3
  • 4. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 4 Problems Solved?
  • 5. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 6 OAuth 2.0 is a framework 6
  • 7. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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 TLS terminates here. A1Z cannot verify that the Authz request is from C1O C1R cannot verify that the Authz response is from C1O
  • 13. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 14 Identity and authentication problems 14 OAuth has no notion of user identity. User authentication is “out of scope”.
  • 15. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 1515Created by @nishantk
  • 16. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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 TLS terminates here. Malware can see the payload
  • 17. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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
  • 18. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 1818
  • 19. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 19 So, how do we solve? 19
  • 20. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 20 OpenID Foundation Financial API WG (FAPI WG) 20
  • 21. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 24 Working Together 24 OpenID FAPI UK Implementation Entity (Chair) (Co-Chair)(Co-Chair) (UK IE Liaison)
  • 25. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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 Swagger file will be provided Swagger file will be provided
  • 27. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 2727 Tasting tour of the FAPI Security Profiles
  • 28. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 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. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 39 Do you know if you have implemented correctly? 39
  • 40. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 40 Certification test will be available online 40
  • 41. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 41 Join the group! https://openid.net/wg/fapi/ 41

Editor's Notes

  1. 1. In the era of mobile, OAuth 2.0 is the protocol of the choice. 2. However, RFC6749 is a framework and needs to be profiled appropriately for use cases. 3. FAPI WG @ OIDF is taking such task for Financial APIs and securing it using RFC7636, JWT Client Authentication/TLS Client Authentication, OpenID Connect, etc. 4. FAPI WG is collaborating with many stakeholders including financial institutions and fintech companies, etc.
  2. Hi, I am Nat Sakimura. It is an honor to be able to present in front of the distinguished audience, and I am very thankful to the APIDays committee for letting it happen. I am a Research Fellow at Nomura Research Institute, Chairman of the Board of the OpenID Foundation, and Chair of the Financial API WG among other things. If you are in API security field, you probably heard about me because I am an author of OpenID Connect, JSON Web Token, JSON Web Signature, OAuth PKCE, etc. OK. Now, here is the first Proposition to be discussed today:
  3. The answer is of course “NO”. Like Mark O’Neill of Gartner spoke yesterday, Building blocks needs to be combined correctly. Just saying #oauth does not do the job.
  4. It is abundantly clear even from the title of RFC6749. It is “The OAuth 2.0 Authorization Framework”. It is a framework, not a concrete protocol specification,
  5. So that it can span across various service environemnts. Here, I have depicted it in two dimentions. Horizontal axis is the degree of environment control and the vertical is the stake that the API is protecting. As a framework, it needed to cover all quadrants, and OAuth 2.0 Framework does so.
  6. Which is all good, but it also means that you need to profile it to suit the specific situations. For example, for the closed circuit factory application usecase, the security could be maintained by the close control of the environment so you may not need to do much on the application layer like OAuth. It probably is also ok to use a naïve implementation choice like bearer token in may social sharing scenarios as the stake is low though the environment is far from being controlled. But that does not apply for a higher stake scenario such as online banking. You got to be darn careful in such cases.
  7. And, to create such profile for Financial APIs, there are multiple factors that you actually have to take care of, many of which are often ignored and results in awfully insecure OAuth 2.0 implementations.
  8. One of the common mistake is not following the OAuth’s security assumptions. For example, OAuth’s primary security assumption is that there is only 1 Authz Server per client. But that assumption is violated in many cases. For example, a Personal Finance Client will necessarily have multiple Authz Svs. In that kind of cases, you have to make sure to have a proper virtual separation, that is, having different redirect endpoints for each authorization server to avoid Authz server mix-up attack etc. It has to be like the picture on your left. Unfortunately, in many implementations, they get lazy and re-use the same redirection endpoint like the figure on your right, which is a big mistake.
  9. And there are bunch of other issues to be resolved. Message Authn probl.