I’m not a deep OAuth 2.0 ex­pert yet; at this point that label is re­served for the (sub­stan­tial num­ber of) peo­ple who wrote the specs. But I’ve worked with a few im­ple­men­ta­tions and talked it over with smart peo­ple, and I have opin­ions. Sum­mary: It’s a frame­work not a pro­to­col, it has ir­ri­tat­ing prob­lems, and it’s re­ally very use­ful.

Real In­ter­net Pro­to­cols · 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 sur­pris­ing. ¶

OAuth 2.0 isn’t one of those; the lan­guage of the spec is full of “Out of scope” and “At the dis­cre­tion of the im­ple­men­tor”. It’s not that a generic OAu­th2 client might not in­ter­op­er­ate with a generic server; it’s that there’s re­ally no such thing as a “generic OAu­th2 client” or “generic Oau­th2 server”.

So, is it re­ally a “Stan­dard” in any use­ful sense? And should we in­vest in im­ple­ment­ing it? Yes to both. OAu­th2 is, for lack of a bet­ter word, a frame­workthat you can use to build ac­tual real pro­to­cols.

For ex­am­ple, Google has an au­tho­riza­tion pro­to­col for ac­cess­ing its APIsthat’s to­tally OAu­th2. It meets our se­cu­rity needs and it’s been easy for us (and any­one else) to ship li­braries for app builders to use, be­cause there are start­ing to be com­mon bits and pieces of frame­work im­ple­men­ta­tion to use. And also be­cause OAu­th2 just isn’t that hard.

An­other ex­am­ple would be OpenID Con­nect, OIDC for short. It’s try­ing re­ally hard to be a real ac­tual In­ter­net Pro­to­col; plug a client into a server and feel en­ti­tled to anger if it doesn’t Just Work. I’m su­per-in­ter­ested in OIDC and start­ing to be­come a fan. In fact, it de­serves its own space in on­go­ing, so let’s note that it’s built on OAu­th2, push it on the stack, and re­turn to it in an­other piece.

What OAu­th2 Ac­tu­ally Does · Let’s work through it from back to front. The end-game of an OAu­th2 in­vo­ca­tion is an “Ac­cess Token”, just a string of char­ac­ters. It’s called a “bearer token”, which means that you send it along with an HTTP re­quest, ei­ther 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 ner­vous, and I wish peo­ple wouldn’t). ¶

Any­how, the token rep­re­sents the right for you to make that HTTP re­quest to what­ever the URI iden­ti­fies. The to­kens are fairly short-lived (an hour or less is typ­i­cal) but can be re­freshed. They can also be in­val­i­dated, in which case they stop work­ing. For ex­am­ple, the string

ya29.AHES6ZQRUz_7TzCdPehdeGeh6g4yFIBZGOwi-nRJTlg3XoQ

was an ac­cess token that for an hour some­time last month rep­re­sented the right for tbray@​textuality.​com to ac­cess the Google+ API.

OAu­th2 also spec­i­fies how you go about get­ting a token; it’s a fairly in­volved HTTP dance in­volv­ing sev­eral dis­tinct servers, no­tably in­clud­ing:

• One host­ing the re­source you’re try­ing to ac­cess,

• one that can au­then­ti­cate the per­son logged into the browser mak­ing the re­quest, and

• one that can issue and re­fresh the ac­tual to­kens.

Yes, it’s pos­si­ble for some of them to be the same server, but what­ever. The way it works is that the first redi­rects to the sec­ond redi­rects to the third and then you go back with your token to the first and do the ac­tual work you started out try­ing to do.

The con­trol can flow en­tirely back and forth through the browser, with sim­ple-enough JavaScript, or through a back-chan­nel be­tween servers; the lat­ter feels more nat­ural and se­cure to me, but I guess I’m an old fogey who in­suf­fi­ciently wor­ships all-browser-all-the-time logic.

The OAu­th2 specs lay out how to build the tar­get and redi­rect URIs and code the pa­ra­me­ters and so on. They also spec­ify that the app launch­ing the dance has to be reg­is­tered with the server-side logic in ad­vance.

Any­how, turn all those cranks and your token comes out of the ma­chine and you’re off to the races. That’s about all there is to it; but it takes a whole lot of pages of spec­i­fi­ca­tion-ware to de­scribe all the pieces.

What’s Wrong With This Pic­ture? · OAu­th2 is con­tro­ver­sial; the spec ed­i­tor even­tu­ally got mad enough to stomp out of the room, and is now off in his own sand­box writ­ing his own re­place­ment for OAu­th2. He (and oth­ers) have said these things about it: ¶

1. The spec suf­fers from en­ter­prisey bloat; it’s too big and too com­pli­cated and can only be im­ple­mented by leviathans.

2. The no­tion of naked bearer token is in­sane; any­one who can eaves­drop on your HTTP con­ver­sa­tion has the keys to the king­dom. The to­kens need to be signed and/or en­crypted and thus im­mune from tin­ker­ing.

3. The OAu­th2 dance de­pends on Web-browser se­man­tics with all those redi­rects, and thus isn’t re­ally suit­able for com­piled mo­bile (as in iOS and An­droid) apps.

I think they’re all prob­lems, but only one of them re­ally costs me lost sleep. Let’s take them in order.

Is OAu­th2 Too Big? · Yes, ab­solutely. It’s got way more stuff in it than, for ex­am­ple, an In­ter­net com­pany like Google needs; mostly things that are there to meet pro­fessed En­ter­prise re­quire­ments. The Work­ing Group clearly needed more ir­ri­tat­ing loud-voiced min­i­mal­ists stri­dently chant­ing YAGNI! YAGNI! YAGNI! ¶

The crit­ics are right that it would be a big en­gi­neer­ing chal­lenge — maybe im­pos­si­bly big — to build a qual­ity im­ple­men­tion of the whole thing.

That doesn’t bother me as a Googler be­cause I don’t think we’re going to try. We’ve built the parts of the frame­work we need to im­ple­ment the pro­to­cols that we want to sup­port, and I can’t see us car­ing much about the rest.

This is a time-hon­ored prac­tice among im­ple­men­tors fac­ing over-am­bi­tious stan­dards (which a ma­jor­ity of stan­dards are).

I’m pretty con­vinced that there’s a 80/20 point there in­side OAu­th2 that pro­vides real value and is pretty tractable to im­ple­ment. It might make sense, with a cou­ple years’ ex­pe­ri­ence, to write that sub­set down and give it a name.

Are Bearer To­kens Sane? · No, un­less you en­crypt your trans­port, in which case they are. I start with a bit of a prej­u­dice here, since I think thatall In­ter­net traf­fic should be pri­vate by de­fault, i.e. be con­ducted using HTTPS. ¶

It’s like this: If you’re send­ing data that needs au­then­ti­ca­tion/au­tho­riza­tion back and forth over chan­nels that are sub­ject to eaves­drop­ping, stolen bearer to­kens are going to be the least of your prob­lems.

I ac­knowl­edge my prej­u­dice; but my con­vic­tions are re­in­forced by the fact that Google’s se­cu­rity gor­gons, who are an ex­cep­tion­ally para­noid bunch of peo­ple, are OK with bearer to­kens too.

Also, while I never worked with an OAuth 1 im­ple­men­ta­tion, I sure heard lots of com­plaints about how hard it was to get the en­cryp­tion and sign­ing to in­ter­op­er­ate. I have worked with sev­eral OAu­th2 ser­vices and it’s no big­gie. Peo­ple I re­spect say that in prin­ci­ple OAuth 1 shouldn’t be hard. Maybe it’s sim­ply that OAuth 2 has had bet­ter li­braries ship faster than its pre­de­ces­sor?

At this point, cue whin­ing from peo­ple who say they can’t HTTPS be­cause they need to do deep packet in­spec­tion for rea­sons of load bal­anc­ing or reg­u­la­tory com­pli­ance or what­ever. I think they’re mostly just Doing It Wrong, but if the bot­tom line is those peo­ple can’t use OAu­th2, well OK.

How About Mo­bile? · Yeah, it’s a prob­lem. Peo­ple who use Google apps right now on iOS know all about it; you’re al­ways hav­ing a browser pop out at you and you have to type in your pass­word way, way more than you should have to, which on a mo­bile de­vice is ba­si­cally never. (Yes, we know that we need to do some­thing about this.) ¶

We’ve worked around it on An­droid and made it easy for apps to get OAu­th2 bearer to­kens, but we had to build great gobs of An­droid and back-end code that bridge across lots of dif­fer­ent pieces of Google in­fra­struc­ture and were a major pain in the butt to debug; I know be­cause I helped.

But what we got pro­vides a pretty de­cent out­come; you can use Google’s APIs, and au­then­ti­cate users to your own back-ends, with good per­for­mance, good se­cu­rity, and re­ally rather nice user ex­pe­ri­ence. I don’t see any rea­son why any­one else shouldn’t be able to do the same.

So maybe, even though OAu­th2 isn’t a great fit for mo­bile apps, the cost/ben­e­fit analy­sis is such that we server-side folks should just suck it up and build the back-end code to make it work.

Hav­ing said that, I’ll take a good close look at any­thing that promises to make life eas­ier for mo­bile-app writ­ers.

Con­tri­bu­tions