Workgroup Discussion on RESTful Application Programming Interface (API) Security

Transport & Security Standards Workgroup

January 12, 2014

January 12, 2015 Agenda

2

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 3

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

4

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

JWS JWE JWA

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 |

© 2014 The MITRE Corporation. All rights reserved.

OAuth Vulnerabilities and Countermeasures

Attack Category Countermeasures

Extracting credentials or tokens in captured traffic

TLS encryption

Impersonating authorization server or resource server

TLS server authentication

Manufacturing or modifying tokens Issue tokens as signed JWTs

Redirect manipulation Require clients to declare redirect URIs during registration

Guessing or interception of client credentials

Used signed JWTs for client authentication

Client session hijacking or fixation Use the State parameter to ensure continuity of client session throughout the OAuth flow

| 7 |

© 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

| 8 |

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

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 linko 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 10

*A web token signature is a verified and secure means of representing claims to be transferred between two parties