Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Nomura Research Institute
Nat Sakimura (@_nat_en)
Chairman of the Board, OpenID Foundation
Research Fellow, Nomura Researc...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
2
Nat Sakimu...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
3
In the era...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
4
Problems S...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
5
“Building ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
6
OAuth 2.0 ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
7
So that it...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
8
But you ne...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
9
To create ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
10
OAuth’s p...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
11
Message A...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
12
Message S...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
13
Message D...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
14
Identity ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
1515Created ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
16
Message c...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
17
Token Phi...
© 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 d...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
20
OpenID Fo...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
21
Purpose
T...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
22
Enable
a...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
23
Why OpenI...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
24
Working T...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
25
In a IPR ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
26
Current S...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
2727
Tasting...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
28
Financial...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
29
5.2.2 Aut...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
30
… continu...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
31
… continu...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
32
Then, the...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
33
E.g., if ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
34
Request O...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
35
Response ...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
36
Authoriza...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
37
Protectio...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
38
Once comp...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
39
Do you kn...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
40
Certifica...
© 2016 by Nomura Research Institute. All rights reserved.
Copyright © 2016 Nat Sakimura. All Rights Reserved.
41
Join the ...
Upcoming SlideShare
Loading in …5
×

Financial Grade OAuth & OpenID Connect

2,395 views

Published on

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.
5. Read only security profile going to OIDF votes.
6. Overview of the requirements for Read Only and Write Access security profiles are discussed.

Published in: Technology
  • DOWNLOAD FULL BOOKS, INTO AVAILABLE FORMAT ......................................................................................................................... ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. PDF EBOOK here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. EPUB Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... 1.DOWNLOAD FULL. doc Ebook here { https://tinyurl.com/y3nhqquc } ......................................................................................................................... ......................................................................................................................... ......................................................................................................................... .............. Browse by Genre Available eBooks ......................................................................................................................... Art, Biography, Business, Chick Lit, Children's, Christian, Classics, Comics, Contemporary, Cookbooks, Crime, Ebooks, Fantasy, Fiction, Graphic Novels, Historical Fiction, History, Horror, Humor And Comedy, Manga, Memoir, Music, Mystery, Non Fiction, Paranormal, Philosophy, Poetry, Psychology, Religion, Romance, Science, Science Fiction, Self Help, Suspense, Spirituality, Sports, Thriller, Travel, Young Adult,
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Financial Grade OAuth & OpenID Connect

  1. 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. 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. 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. 4. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 4 Problems Solved?
  5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 1515Created by @nishantk
  16. 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. 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. 18. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 1818
  19. 19. © 2016 by Nomura Research Institute. All rights reserved. Copyright © 2016 Nat Sakimura. All Rights Reserved. 19 So, how do we solve? 19
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×