I’m not a deep OAuth 2.0 expert yet; at this point that label is reserved for the (substantial number of) people who wrote the specs. But I’ve worked with a few implementations and talked it over with smart people, and I have opinions. Summary: It’s a framework not a protocol, it has irritating problems, and it’s really very useful.

Real Internet Protocols · I mean things like HTTP and SMTP; plug a client and a server into each other and if it doesn’t Just Work, that’s surprising.

OAuth 2.0 isn’t one of those; the language of the spec is full of “Out of scope” and “At the discretion of the implementor”. It’s not that a generic OAuth2 client might not interoperate with a generic server; it’s that there’s really no such thing as a “generic OAuth2 client” or “generic Oauth2 server”.

So, is it really a “Standard” in any useful sense? And should we invest in implementing it? Yes to both. OAuth2 is, for lack of a better word, a framework that you can use to build actual real protocols.

For example, Google has an authorization protocol for accessing its APIs that’s totally OAuth2. It meets our security needs and it’s been easy for us (and anyone else) to ship libraries for app builders to use, because there are starting to be common bits and pieces of framework implementation to use. And also because OAuth2 just isn’t that hard.

Another example would be OpenID Connect, OIDC for short. It’s trying really hard to be a real actual Internet Protocol; plug a client into a server and feel entitled to anger if it doesn’t Just Work. I’m super-interested in OIDC and starting to become a fan. In fact, it deserves its own space in ongoing, so let’s note that it’s built on OAuth2, push it on the stack, and return to it in another piece.

What OAuth2 Actually Does · Let’s work through it from back to front. The end-game of an OAuth2 invocation is an “Access Token”, just a string of characters. It’s called a “bearer token”, which means that you send it along with an HTTP request, either using the HTTP Authorization header (which is the right way) or as an ?access_code=<token> name/value pair tacked onto the end of a URI (which makes me nervous, and I wish people wouldn’t).

Anyhow, the token represents the right for you to make that HTTP request to whatever the URI identifies. The tokens are fairly short-lived (an hour or less is typical) but can be refreshed. They can also be invalidated, in which case they stop working. For example, the string


was an access token that for an hour sometime last month represented the right for tbray@textuality.com to access the Google+ API.

OAuth2 also specifies how you go about getting a token; it’s a fairly involved HTTP dance involving several distinct servers, notably including:

  • One hosting the resource you’re trying to access,

  • one that can authenticate the person logged into the browser making the request, and

  • one that can issue and refresh the actual tokens.

Yes, it’s possible for some of them to be the same server, but whatever. The way it works is that the first redirects to the second redirects to the third and then you go back with your token to the first and do the actual work you started out trying to do.

The control can flow entirely back and forth through the browser, with simple-enough JavaScript, or through a back-channel between servers; the latter feels more natural and secure to me, but I guess I’m an old fogey who insufficiently worships all-browser-all-the-time logic.

The OAuth2 specs lay out how to build the target and redirect URIs and code the parameters and so on. They also specify that the app launching the dance has to be registered with the server-side logic in advance.

Anyhow, turn all those cranks and your token comes out of the machine and you’re off to the races. That’s about all there is to it; but it takes a whole lot of pages of specification-ware to describe all the pieces.

What’s Wrong With This Picture? · OAuth2 is controversial; the spec editor eventually got mad enough to stomp out of the room, and is now off in his own sandbox writing his own replacement for OAuth2. He (and others) have said these things about it:

  1. The spec suffers from enterprisey bloat; it’s too big and too complicated and can only be implemented by leviathans.

  2. The notion of naked bearer token is insane; anyone who can eavesdrop on your HTTP conversation has the keys to the kingdom. The tokens need to be signed and/or encrypted and thus immune from tinkering.

  3. The OAuth2 dance depends on Web-browser semantics with all those redirects, and thus isn’t really suitable for compiled mobile (as in iOS and Android) apps.

I think they’re all problems, but only one of them really costs me lost sleep. Let’s take them in order.

Is OAuth2 Too Big? · Yes, absolutely. It’s got way more stuff in it than, for example, an Internet company like Google needs; mostly things that are there to meet professed Enterprise requirements. The Working Group clearly needed more irritating loud-voiced minimalists stridently chanting YAGNI! YAGNI! YAGNI!

The critics are right that it would be a big engineering challenge — maybe impossibly big — to build a quality implemention of the whole thing.

That doesn’t bother me as a Googler because I don’t think we’re going to try. We’ve built the parts of the framework we need to implement the protocols that we want to support, and I can’t see us caring much about the rest.

This is a time-honored practice among implementors facing over-ambitious standards (which a majority of standards are).

I’m pretty convinced that there’s a 80/20 point there inside OAuth2 that provides real value and is pretty tractable to implement. It might make sense, with a couple years’ experience, to write that subset down and give it a name.

Are Bearer Tokens Sane? · No, unless you encrypt your transport, in which case they are. I start with a bit of a prejudice here, since I think that all Internet traffic should be private by default, i.e. be conducted using HTTPS.

It’s like this: If you’re sending data that needs authentication/authorization back and forth over channels that are subject to eavesdropping, stolen bearer tokens are going to be the least of your problems.

I acknowledge my prejudice; but my convictions are reinforced by the fact that Google’s security gorgons, who are an exceptionally paranoid bunch of people, are OK with bearer tokens too.

Also, while I never worked with an OAuth 1 implementation, I sure heard lots of complaints about how hard it was to get the encryption and signing to interoperate. I have worked with several OAuth2 services and it’s no biggie. People I respect say that in principle OAuth 1 shouldn’t be hard. Maybe it’s simply that OAuth 2 has had better libraries ship faster than its predecessor?

At this point, cue whining from people who say they can’t HTTPS because they need to do deep packet inspection for reasons of load balancing or regulatory compliance or whatever. I think they’re mostly just Doing It Wrong, but if the bottom line is those people can’t use OAuth2, well OK.

How About Mobile? · Yeah, it’s a problem. People who use Google apps right now on iOS know all about it; you’re always having a browser pop out at you and you have to type in your password way, way more than you should have to, which on a mobile device is basically never. (Yes, we know that we need to do something about this.)

We’ve worked around it on Android and made it easy for apps to get OAuth2 bearer tokens, but we had to build great gobs of Android and back-end code that bridge across lots of different pieces of Google infrastructure and were a major pain in the butt to debug; I know because I helped.

But what we got provides a pretty decent outcome; you can use Google’s APIs, and authenticate users to your own back-ends, with good performance, good security, and really rather nice user experience. I don’t see any reason why anyone else shouldn’t be able to do the same.

So maybe, even though OAuth2 isn’t a great fit for mobile apps, the cost/benefit analysis is such that we server-side folks should just suck it up and build the back-end code to make it work.

Having said that, I’ll take a good close look at anything that promises to make life easier for mobile-app writers.


Comment feed for ongoing:Comments feed

From: Dick Hardt (Jan 25 2013, at 09:39)

Great write up Tim! Agreed the final spec is more complicated than it shold be. Part of that was Eran insisting on the Bearer Token aspect be in a separate document.


From: Adrius42 (Jan 25 2013, at 13:30)

My sense is that any standard that necessarily allows "corporates" to insert their percieved needs will bloat, I watched that happen with X.400. Happily as a result of the bloated discussions some clever folks were able to distil out SMTP.

Perhaps we are simply on a journey (Highland Park, my favourite distilled product), with gallons of wort has to go through a wash back stage that often causes vibrations. It is arguable that there is no other way to achieve the finest distilled product.

Though a master distiller knows that it is the final "Ceremony" that they are aiming for... they have the knowledge and patience to go through the mash tun phase.

My favourite; Highland Park, takes 18 years from barley to lip. While it is possible to create lesser products more quickly from potatoe, they will always be just that ... lesser!

Here's to the journey! My only hope is that the Identity Master Distillers understand that their clients are NOT the corporates, but those that will consume what they produce. Here's to a final product that will have a fine nose and an excellent finish.


From: jrochkind (Jan 25 2013, at 15:50)

> That doesn’t bother me as a Googler because I don’t think we’re going to try. We’ve built the parts of the framework we need to implement the protocols that we want to support, and I can’t see us caring much about the rest.

Okay, what I'm not sure i see is what the actual _value_ of having a 'framework for building protocols' like this.

It's not a protocol, there's no such thing as a 'generic implementation', it's a framework for building specific protocols. OP isn't bothered by the complexity, even though it would be infeasible to implement 'the whole thing', because they just build their own concrete much simpler protocol out of the framework, and only have to implement that, and their clients only have to implement clients for that.

Fair enough.. but what did the OAuth 'framework' actually _get anyone_ then? What value did it add?

* Would Google have found it much harder to implement the protocol from scratch, without the OAuth framework to guide the?

* Does it matter to anyone that the concrete protocol they devised is 'compliant' with the OAuth framework?

** If when devising their concrete protocol, they had decided it made more sense to do something that actually violated the OAuth framework (if that's even possible, it's so flexible)... would it matter? If so, why?

Unless the answer to any of these questions is 'yes'... or there's some other 'yes' question I'm not thinking of... I don't see what the point of having this generic monstrously flexible OAuth 'framework for building a protocol' is. Sure, it might not get in your way, but what does it help, how does it simplify rather than confuse?


From: ebenezer (Jan 26 2013, at 11:34)

“access the Gooogle+ API” was probably supposed to have been “access the Google+ API.” :)


From: Antonio (Jan 27 2013, at 03:17)

Great stuff Tim.

I do agree to any of your points.

I would add couple of new points though.

One more issue with the OAuth 2 framework is the lack of choices made from the editors (as mentioned also from Eran Hammer). You need to really be a security expert in order to make things right.

Another thing that "bothers" me is that a lot of "entities" used OAuth as an Authentication protocol (see also the very detailed article of Vittorio Bertucci from Microsoft [0]) and this can be an issue specially in the client side flow .

Google not surprisingly does it right (using open id connect) and there is a warning on the client side flow doc about the "confused deputy problem" but believe me, not many providers do it.

[0] http://blogs.msdn.com/b/vbertocci/archive/2013/01/02/oauth-2-0-and-sign-in.aspx



From: Hannes Tschofenig (Jan 28 2013, at 04:02)

A short remark to a statement made by Adrius42:


My sense is that any standard that necessarily allows "corporates" to insert their percieved needs will bloat


Most people have to work for someone in order to earn money. Eran, for example, worked for Yahoo when he was working on the specification.


From: Hannes Tschofenig (Jan 28 2013, at 04:17)

You write: "Real Internet Protocols · I mean things like HTTP and SMTP. plug a client and a server into each other and if it doesn’t Just Work, that’s surprising. OAuth 2.0 isn’t one of those"

First, you have to describe what you call OAuth 2.0. There are various people who refer only the core spec, others use the term to refer to a specific deployment (such as Facebook's OAuth 2.0 implementation).

The comparison with HTTP and SMTP is also a bit challenging since in the case of OAuth you are talking about a multi-party security protocol.

Finally, you have to explain what you mean by "works". Is it that everyone is able to access everything?

Like with many security protocols you have to think about the treats you are concerned with, and what your security requirements are. It turns out that the security concerns that Eran had were quite different to other people and hence it was difficult to up with only one way to do it. Eran, for example, cared a lot about having the OAuth client implementation to actively participate in the cryptographic protocol exchange (via a keyed message digest) but he didn't care much about privacy or protecting the data that was exchanged as a result of a successful OAuth 2.0 authorization. His views were most likely driven by what Yahoo needed and those aspects weren't important to them (as it still seems). But not everyone has the same needs.


From: Prateek Mishra (Feb 06 2013, at 06:50)

Two comments -

1) I would be interested in learning more about Android utilities/libraries that make it easier to use OAuth 2.0 for applications on mobile devices. We also find this as an area of difficulty.

You mention investments that Google has made in this area. Are there any plans to make these generally available to the Android community?

2) Regarding the various flaws of OAuth 2.0, well, I believe these perceptions may be shaped by (lack of) experience with identity systems.

Use of bearer instruments (e.g., cookies) over TLS is the norm on the internet; application-level signature and encryption is MUCH more complex and error-prone. Finally, a comparison with the SAML 2.0 specifications (another multi-party protocol) would provide a fairer test to assess OAuth 2.0 complexity.


author · Dad
colophon · rights
picture of the day
January 23, 2013
· Technology (90 fragments)
· · Identity (44 more)
· · Web (396 more)

By .

The opinions expressed here
are my own, and no other party
necessarily agrees with them.

A full disclosure of my
professional interests is
on the author page.

I’m on Mastodon!