REST Uneasy: Do we Need to Worry about OAuth 2.0?

Reading the IETF OAuth 2.0 authorization API specifications and generally investigating similar social login protocols over the past couple of months has been fascinating. While the journey is far from over, I’ve come far enough to gain perspective on the landscape and see something of the road ahead. Time to blog! This will be the first of a little mini-series I call “REST Uneasy.”

The journey began at RSA Conference in San Francisco over dinner with some developers telling me they had “heard about security problems with OAuth 2.0.” Checking into it, I found some concerns right in the Wikipedia page for the protocol:

“OAuth 2.0 has had numerous security flaws exposed in implementations. The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable.”

First thing I did was email a colleague from a research firm and ask him what he thought. In reply:

“Careful of the Wikipedia stuff – the old OAuth editor is really bitter and has been making a lot of negative noise. Read the security considerations section in the RFCs 6749 and 6750 – both are good.”

I’d seen those bitter posts my colleague referred to back in San Francisco already. I’d read the two normative OAuth 2.0 RFCs and even a third one “RFC 6819 on OAuth 2.0 Threat Model and Security Considerations.” No question but the RFCs are impressive works and that Dick Hardt and company know their stuff. But the question remains: do we have to worry about OAuth 2.0 security?

I say yes. I think the bitter posts did the industry a disservice by making security concerns easier to dismiss than they should be. The fact of the matter is that OAuth 2.0 – a developer-friendly protocol –  has made many compromises. Why else would RFC 6819 need to be whole separate document weighing in at 72 pages long just on security? (I’ll cover those security compromises soon in another post I’m thinking of called “There’s no smoke without fire.”) But for now, trust me, we’ll pay the price either with increased security testing and counter-measures, or with increased security vulnerabilities and breaches.

I think the interoperability OAuth 2.0 brings is worth some pain, but would prefer to minimize it through testing and counter-measures with implementations.

Please comment: Are these concerns over-blown, or do you agree that a lot of work needs to be done on security testing and hardening of OAuth implementations? If so, what kind?

• Securing the API Economy
• Covert OAuth Redirects and Perverse Incentives
• OAuth-Protected Access at Facebook and Twitter Breached from Leaky Buffer Service
• Managing OAuth Risks in Mobile Applications
• OAuth 2.0Assurance Issues
• Mitigating OAuth Security Issues with Good Profiling
• OAuth 2.0 and RESTful Protocol Security Testing Challenges
• Piling on OAuth
• REST Uneasy: Do we Need to Worry about OAuth 2.0?