Last weekend I got an email asking whether OAuth 2.0 is ready to deploy for healthcare. Given SMART’s use on OAuth 2.0, I think so! Here’s the exchange…
The question I received
I realize that the big news is the NPRMs being released, but one thing that I have been interested in is the big push for using OAuth 2.0 with newer standards (primarily FHIR related), and the known vulnerabilities in OAuth2.0.
I realize that HL7’s security Workgroup has experts and the other organizations consult experts (and I’m certainly not questioning the work they have done in this area) , but considering we are talking about healthcare data – it seems that it might have raised at least a few eyebrows and would have been addressed more openly.
Below are just a few links that explain. I do not know how many – if any – of these vulnerabilities have been resolved since these were printed.
I just thought this was interesting…
http://www.darkreading.com/security-flaw-found-in-oauth-20-and-openid-third-party-authentication-at-risk/d/d-id/1235062
http://tetraph.com/covert_redirect/oauth2_openid_covert_redirect.html
http://www.oauthsecurity.com/
http://www.cnet.com/news/serious-security-flaw-in-oauth-and-openid-discovered/
My executive summary-level response:
There have been many reports of flawed OAuth 2.0 implementations, but there have not been security vulnerabilities identified in the OAuth 2.0 framework itself. The community is constantly improving on best practices that help developers avoid implementation pitfalls. There are already real-world OAuth 2.0 deployments in healthcare.
—
My more detailed take:
The overall system security of an
OAuth 2.0 implementation depends critically on a substantial number of implementation details (as with any reasonably-capable authorization framework). The core
OAuth 2.0 spec is accompanied by a “
Threat Model and Security Considerations” document (RFC 6819) outlining many risks; and other groups have performed related analyses. The bottom line is that a robust implementation of
OAuth 2.0 must account for these risks and ensure that appropriate mitigations are in place.
Sensational headlines in the blogosophere generally identify places where an individual implementer got some of these details wrong. In large measure, we’ve seen so many of these stories simply because OAuth 2.0 is so widely deployed — not because it’s so deeply flawed. (Now, we can argue that a well-designed security protocol should protect implementers from all kinds of mistakes — and that’s fair. But the collective community experience in identifying these threats, learning how things go wrong, memorializing the understanding in clearer recommendations and more-capable reference software implementations is exactly how that protection emerges.) At the end of the day, Microsoft, Google, Facebook, Twitter, Salesforce, and many, many more players (large and small) offer, promote, and continue to expand their OAuth 2.0 deployments.
With respect to health IT, there is ongoing work to define profiles of OAuth 2.0 that promote best practices and avoid common pitfalls. Three examples are:
MITRE’s OAuth 2.0 profiles created for VA:
SMART on FHIR’s profiles for EHR plug-in apps
OpenID Foundation’s Health Relationship Trust (HEART) Workgroup:
Commercial health IT vendors have already deployed OAuth 2.0 implementations, and I expect we’ll see many more in the near future.