1. © 2014 The MITRE Corporation. All rights reserved. Mark Russell OAuth and OpenID Connect Risks and Vulnerabilities 12/3/2014 Approved for Public Release; Distribution Unlimited. Case Number 14-3178

2. | 2 || 2 | © 2014 The MITRE Corporation. All rights reserved. Purpose  Summarize OAuth and OpenID Connect risks and vulnerabilities  Provide pointers to further reading

3. | 3 || 3 | © 2014 The MITRE Corporation. All rights reserved. Task Background Sponsor: Dr. Paul Tibbits, VA Office of Information & Technology (OIT) Architecture, Strategy, & Design (ASD) Task Summary:  Phase 1 - Develop a profile for distributed information sharing using the RESTful architecture style –Use open standards –Must be secure and compliant with VA requirements –Must support lightweight web clients and mobile devices  Phase 2 - Demonstrate the viability of this approach using a pilot Work products approved for public release by the VA

4. | 4 || 4 | © 2014 The MITRE Corporation. All rights reserved. Task Team  Mary Pulvermacher – Outcome Lead –pulver@mitre.orgpulver@mitre.org  Mike Dowe – Outcome Lead –rdowe@mitre.orgrdowe@mitre.org  Justin Richer – Protocols & Security Standards SME; Developer –jricher@mitre.orgjricher@mitre.org  Mark Russell – Cybersecurity SME –mrussell@mitre.orgmrussell@mitre.org  Dave Hill – EHR and Medical Systems SME; Developer –dwhill@mitre.orgdwhill@mitre.org

5. | 5 || 5 | © 2014 The MITRE Corporation. All rights reserved. A stack of interrelated protocols in wide use on the web can help meet security requirements for RESTful interfaces Open Security Standards for RESTful Interfaces TLS (Secure Transport) JOSE (Signed & Encrypted Data) JWK JWT (Secure Tokens) OpenID Connect (Identity Federation) OAuth (Authorization) UMA (User-Managed Access) JWSJWEJWA Acronyms: TLS: Transport Layer Security JSON: JavaScript Object Notation JWK: JSON Web Key JWS: JSON Web Signature JWE: JSON Web Encryption JWA: JSON Web Algorithms JOSE: JSON Object Signatures & Encryption JWT: JSON Web Tokens

6. | 6 || 6 | © 2014 The MITRE Corporation. All rights reserved. The OAuth Players OAuth 2.0 Authorization Code Flow AE TE Authorization Server Resource Owner & User Agent Protected Resource Client Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

7. | 7 || 7 | © 2014 The MITRE Corporation. All rights reserved. Resource Owner OAuth 2.0 Authorization Code Flow AE TE Authorization Server Resource Owner & User Agent Protected Resource Client Resource Owner Description: Has credentials with the authorization server Controls access to a protected resource Decides to trust the client to interact with the resource Resource Owner Risks: Theft of credentials Delegation of unintended or excessive access Theft or manipulation of data Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

8. | 8 || 8 | © 2014 The MITRE Corporation. All rights reserved. Client OAuth 2.0 Authorization Code Flow AE TE Authorization Server Resource Owner & User Agent Protected Resource Client Client Description: Different client types with different security properties Native clients (e.g., mobile apps) Embedded clients (in-browser apps) Web clients Registers with the authorization server to obtain a client ID Most client types have their own credentials Orchestrates communications between the resource owner and the Authorization Server Often has nothing to lose for bad behavior but developer reputation (or being banned from the app store) Client Risks: Theft of credentials Theft or manipulation of data Authorization code or token manipulation Abuse of unsafe redirects Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

9. | 9 || 9 | © 2014 The MITRE Corporation. All rights reserved. Authorization Server OAuth 2.0 Authorization Code Flow AE TE Authorization Server Resource Owner & User Agent Protected Resource Client Authorization Server Description: Controls the policies that govern the process Registers clients Authenticates resource owners and (with exceptions) clients Defines scopes of access (in conjunction with protected resource) Typically hosted by the same organization as the protected resource Authorization Server Risks: Interception of credentials, tokens, or codes Brute-force guessing of credentials, tokens, or codes Redirect URI manipulation Unintended authorization grants via Cross-site Request Forgery Denial/degradation of service Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

10. | 10 | © 2014 The MITRE Corporation. All rights reserved. Protected Resource OAuth 2.0 Authorization Code Flow AE TE Authorization Server Resource Owner & User Agent Protected Resource Client Protected Resource Description: Security considerations depend on what the protected API does Validates tokens and evaluates whether to honor the request based on the granted scope Optional back-channel communications with the Authorization Server for token introspection & revocation Protected Resource Risks: Clients using intercepted tokens Clients using tokens issued for different resources Replay of authorized requests Requests for resources out of granted scope Brute-force guessing of tokens Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

11. | 11 | © 2014 The MITRE Corporation. All rights reserved. OAuth Vulnerabilities and Countermeasures Attack CategoryCountermeasures Extracting credentials or tokens in captured traffic TLS encryption Impersonating authorization server or resource server TLS server authentication Manufacturing or modifying tokensIssue tokens as signed JWTs Redirect manipulationRequire clients to declare redirect URIs during registration Guessing or interception of client credentials Used signed JWTs for client authentication Client session hijacking or fixationUse the State parameter to ensure continuity of client session throughout the OAuth flow

12. | 12 | © 2014 The MITRE Corporation. All rights reserved. Secure RESTful Interface Profile for OAuth  The profile locks down OAuth to address many security concerns: –Stronger client authentication – JWT signatures instead of passwords sent over the network –Tokens are also issued as signed JWTs – easily validated, not subject to brute-force –Redirect URI registration required to avoid redirection issues  Points to some advanced/future options for higher security, at the expense of usability –TLS client authentication –Proof of possession tokens Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

13. | 13 | © 2014 The MITRE Corporation. All rights reserved. Profiling Security Standards – Examples from the OAuth 2.0 Profile RFC6749 – The OAuth 2.0 Authorization Framework Secure RESTful Interface Profiles for OAuth 2.0 The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint. The authorization server SHOULD require the client to provide the complete redirection URI Clients using the authorization code or implicit grant types MUST register their full redirect URIs. The Authorization Server MUST validate the redirect URI given by the client at the authorization endpoint using strict string comparison.

14. | 14 | © 2014 The MITRE Corporation. All rights reserved. Profiling Security Standards – Examples from the OAuth 2.0 Profile RFC6749 – The OAuth 2.0 Authorization Framework Secure RESTful Interface Profiles for OAuth 2.0 An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. … Access tokens can have different formats, structures, and methods of utilization (e.g., cryptographic properties) based on the resource server security requirements. The server MUST issue tokens as JWTs with, at minimum, the following claims… The access tokens MUST be signed with JSON Web Signature (JWS). The authorization server MUST support the RS256 signature method for tokens and MAY use other asymmetric signing methods.

15. | 15 | © 2014 The MITRE Corporation. All rights reserved. The OpenID Connect Players OpenID Connect 1.0 Authorization Code Flow AE TE OpenID Provider End User & User Agent UserInfo Endpoint Relying Party Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

16. | 16 | © 2014 The MITRE Corporation. All rights reserved. OpenID Connect Security Considerations  Built on OAuth, using the same cast of characters –Many of the same considerations apply  Additions to OAuth: –ID Token – a signed and optionally encrypted JWT containing identity and attribute claims about the user –UserInfo Endpoint – a Protected Resource where the Relying Party can request additional claims about the user –OAuth scopes are used to request individual user attributes  Relying party places significant trust in the OpenID Provider –Especially if user claims are inputs to access control decisions  Token interception or manipulation can enable users to impersonate other users –JWT signatures, c_hash values, and other mitigations help prevent this Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

17. | 17 | © 2014 The MITRE Corporation. All rights reserved. Does this sound bad?  Consider the alternatives –The main alternative to OAuth today entails resource owners giving their passwords to clients –The client can then impersonate the owner at any resource server, gets all of the resource owner’s access (no scope limitations), and the only way to revoke the client’s access is to change the user’s password  Different mind-set – putting the user in control –Users decide what client software they want to have interacting with their resources –OpenID Connect is functionally similar to SAML, except that the user authorizes the Relying Party’s access to identity data Content originally published in Secure RESTful Interface Security Analysis and Guidance, July 2014

18. | 18 | © 2014 The MITRE Corporation. All rights reserved. For More Information  Secure RESTful Interface Profile site - access to profiles, other documents, and the source code for our pilot implementation –http://secure-restful-interface-profile.github.io/pages/http://secure-restful-interface-profile.github.io/pages/  OpenID Foundation Health Relationship Trust (HEART) Working Group – developing privacy and security specifications for individuals to control authorization to RESTful health APIs –http://openid.net/wg/heart/http://openid.net/wg/heart/  OAuth 2.0 Threat Model and Security Considerations (IETF) –http://tools.ietf.org/html/rfc6819http://tools.ietf.org/html/rfc6819  OpenID Connect Core – Chapter 16, Security Considerations (OpenID Foundation) –http://openid.net/specs/openid-connect-core-1_0.html#Securityhttp://openid.net/specs/openid-connect-core-1_0.html#Security  Secure RESTful Interface Profile Security Analysis and Guidance (MITRE) –http://secure-restful-interface- profile.github.io/pages/docs/Secure%20RESTful%20Interface%20Security%20Anal ysis%20and%20Guidance.docxhttp://secure-restful-interface- profile.github.io/pages/docs/Secure%20RESTful%20Interface%20Security%20Anal ysis%20and%20Guidance.docx

19. | 19 | © 2014 The MITRE Corporation. All rights reserved. Notice This technical data was produced for the U. S. Government under Contract Numbers VA791-P-0032, VA791-9-0042, VA798A-11-P- 0015, and VA118A-13-D-0037 and is subject to Federal Acquisition Regulation Clause 52.227-14, Rights in Data – General, Alt. II (JUN 1987), Alt. III (JUN 1987) and Alt. IV (JUN 1987). No other use other than that granted to the U. S. Government under that Clause is authorized without the express written permission of The MITRE Corporation. For further information, please contact The MITRE Corporation, Contracts Office, 7515 Colshire Drive, McLean, VA 22102-7539, (703) 983-6000. ©2014 The MITRE Corporation. All rights reserved.