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?

Posts in this thread

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

  • Hi,
    I’ve work a little bit with OAuth(both version 1 and 2) by writing a simple implementation and studying the protocol…

    OAuth2 is NOT developer-friendly. Personally, I think they hate developers:
    -it’s a FRAMEWORK, not a protocol. The difference is big in this case, as the IETF itself said OAuth2 specs are too loose to be defined as a protocol. This brings me to the next:
    -Too many options. Too many flow paths. If you want you can skip the initial client authentication, do it your personal/proprietary way — the specs says you can (rfc6749, section 2.3.2).
    -The total incompatibility between client implementations is what developers *hate*. Want to bring up a new service? Sure, just write yet another library for C/C++, for java, for python for… developer friendly?
    -making me include a web server just to handle the redirects is not what I call “developer-friendly”.

    but let’s talk about security:
    – Too many options means that no one will understand what flow they need — unless each developer studies the whole 80-page rfc and the 72 page security consideration — google still makes you use flows that authenticate your app for android. — I can get the client_id/secret out of every android app: apks/java are rather easy to decompile, unless you start doing heavy obfuscating (developer friendly?)

    -server implementations do not require important parameters such as “state”, “scope”, or “redirect_uri”. the specs says it’s optional! Which means that each website has different required and ignored parameters. You can make OAuth2 into a secure auth scheme, but you have to require *everything* that was optional or recommended.

    -every website will basically need a new library just to login. Google can handle it, can you avoid making mistakes?

    In short, OAuth2 can be secured. If it was broken google/facebook would not use it.
    The specs are too loose (and difficult to read), but you can make a secure implementation out of it. Provided you spend enough time on it. For both client and server. Can you? Can everyone else?
    Developer friendly, really?

Subscribe to Blog Notifications...  HERE