Workgroup Discussion on RESTful Application Programming Interface (API) Security Transport & Security Standards Workgroup January 12, 2014

January 12, 2015 Agenda 1 12:00 p.m. Call to Order/Roll Call — Michelle Consolazio, Office of the National Coordinator Meeting Objective: RESTful Application Programming Interface (API) Security Recommendations 12:05 p.m. Welcome and Agenda Review — Lisa Gallagher, Co-Chair 12:10 p.m. “OAuth and OpenID Connect Risks and Vulnerabilities” Presentation Recap — Mark Russell, The MITRE Corporation 12:35 p.m. Workgroup Recommendation Discussion — Lisa Gallagher, Co-Chair 1:15 p.m. Discussion of Next Steps 1:25 p.m. Public Comment 1:30 p.m. Adjourn Office of the National Coordinator for Health Information Technology

“OAUTH AND OPENID CONNECT RISKS AND VULNERABILITIES” PRESENTATION RECAP (FROM 12/3/14 TSSWG MEETING) Mark Russell, The MITRE Corporation Office of the National Coordinator for Health Information Technology 2

Highlights from Presentation Open security standards for RESTful application programming interfaces (APIs) OAuth and OpenID Connect components (Referenced to the right of this slide) OAuth vulnerabilities and countermeasures Secure RESTful Interface Profiles for OAuth 2.0 OpenID Connect security considerations Office of the National Coordinator for Health Information Technology 3

| 4 || 4 | © 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

| 5 || 5 | © 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

| 6 || 6 | © 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

| 7 || 7 | © 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

WORKGROUP RECOMMENDATION DISCUSSION Lisa Gallagher, Co-Chair Office of the National Coordinator for Health Information Technology 8

Recommendations to Consider The following are some recommended topics to consider in enabling Health IT (HIT) to be certified for having implemented a secure application programming interface (API) for information sharing between partners using RESTful APIs: o Enhance stronger client software authentication by using standardized signed web tokens* instead of passwords sent over the network. o HIT RESTful APIs adopt OAuth 2.0 and OpenID Connect standards with TLS encryption. o Use of TLS encryption with server side authentication assures the clients are communicating with the correct server. The information is also protected across the established link o Minimize redirect manipulation risk exposure by using declared redirect Unique Resource Identifiers “URIs” during registration. o Establish and enhance HIT RESTful API security vulnerability testing to minimize evolving cybersecurity risks. o Ensure appropriate awareness and mitigation of Cross-Site API vulnerabilities. TSS WG should also consider tracking the development and piloting of the OpenID Foundation Health Relationship Trust (HEART) Working Group as potential standards for privacy and security specifications for RESTful HIT APIs Office of the National Coordinator for Health Information Technology 9 *A web token signature is a verified and secure means of representing claims to be transferred between two parties