有趣的 oAuth2 OpenID Con­nect

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


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.

Comments on this fragment are closed.


Com­ment feed for on­go­ing:Comments feed

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

Great write up Tim! Agreed the final spec is more com­pli­cated than it shold be. Part of that was Eran in­sist­ing on the Bearer Token as­pect be in a sep­a­rate doc­u­ment.


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

My sense is that any stan­dard that nec­es­sar­ily al­lows "cor­po­rates" to in­sert their per­cieved needs will bloat, I watched that hap­pen with X.400. Hap­pily as a re­sult of the bloated dis­cus­sions some clever folks were able to dis­til out SMTP.

Per­haps we are sim­ply on a jour­ney (High­land Park, my favourite dis­tilled prod­uct), with gal­lons of wort has to go through a wash back stage that often causes vi­bra­tions. It is ar­guable that there is no other way to achieve the finest dis­tilled prod­uct.

Though a mas­ter dis­tiller knows that it is the final "Cer­e­mony" that they are aim­ing for... they have the knowl­edge and pa­tience to go through the mash tun phase.

My favourite; High­land Park, takes 18 years from bar­ley to lip. While it is pos­si­ble to cre­ate lesser prod­ucts more quickly from pota­toe, they will al­ways be just that ... lesser!

Here's to the jour­ney! My only hope is that the Iden­tity Mas­ter Dis­tillers un­der­stand that their clients are NOT the cor­po­rates, but those that will con­sume what they pro­duce. Here's to a final prod­uct that will have a fine nose and an ex­cel­lent fin­ish.


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

> 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.

Okay, what I'm not sure i see is what the ac­tual _val­ue_ of hav­ing a 'frame­work for build­ing pro­to­cols' like this.

It's not a pro­to­col, there's no such thing as a 'generic im­ple­men­ta­tion', it's a frame­work for build­ing spe­cific pro­to­cols. OP isn't both­ered by the com­plex­ity, even though it would be in­fea­si­ble to im­ple­ment 'the whole thing', be­cause they just build their own con­crete much sim­pler pro­to­col out of the frame­work, and only have to im­ple­ment that, and their clients only have to im­ple­ment clients for that.

Fair enough.. but what did the OAuth 'frame­work' ac­tu­ally _get any­one_ then? What value did it add?

* Would Google have found it much harder to im­ple­ment the pro­to­col from scratch, with­out the OAuth frame­work to guide the?

* Does it mat­ter to any­one that the con­crete pro­to­col they de­vised is 'com­pli­ant' with the OAuth frame­work?

** If when de­vis­ing their con­crete pro­to­col, they had de­cided it made more sense to do some­thing that ac­tu­ally vi­o­lated the OAuth frame­work (if that's even pos­si­ble, it's so flex­i­ble)... would it mat­ter? If so, why?

Un­less the an­swer to any of these ques­tions is 'yes'... or there's some other 'yes' ques­tion I'm not think­ing of... I don't see what the point of hav­ing this generic mon­strously flex­i­ble OAuth 'frame­work for build­ing a pro­to­col' is. Sure, it might not get in your way, but what does it help, how does it sim­plify rather than con­fuse?


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

“ac­cess the Gooogle+ API” was prob­a­bly sup­posed to have been “ac­cess the Google+ API.” :)


From: An­to­nio (Jan 27 2013, at 03:17)

Great stuff Tim.

I do agree to any of your points.

I would add cou­ple of new points though.

One more issue with the OAuth 2 frame­work is the lack of choices made from the ed­i­tors (as men­tioned also from Eran Ham­mer). You need to re­ally be a se­cu­rity ex­pert in order to make things right.

An­other thing that "both­ers" me is that a lot of "en­ti­ties" used OAuth as an Au­then­ti­ca­tion pro­to­col (see also the very de­tailed ar­ti­cle of Vit­to­rio Bertucci from Mi­crosoft [0]) and this can be an issue spe­cially in the client side flow .

Google not sur­pris­ingly does it right (using open id con­nect) and there is a warn­ing on the client side flow doc about the "con­fused deputy prob­lem" but be­lieve 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 re­mark to a state­ment made by Adrius42:


My sense is that any stan­dard that nec­es­sar­ily al­lows "cor­po­rates" to in­sert their per­cieved needs will bloat


Most peo­ple have to work for some­one in order to earn money. Eran, for ex­am­ple, worked for Yahoo when he was work­ing on the spec­i­fi­ca­tion.


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

You write: "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"

First, you have to de­scribe what you call OAuth 2.0. There are var­i­ous peo­ple who refer only the core spec, oth­ers use the term to refer to a spe­cific de­ploy­ment (such as Face­book's OAuth 2.0 im­ple­men­ta­tion).

The com­par­i­son with HTTP and SMTP is also a bit chal­leng­ing since in the case of OAuth you are talk­ing about a multi-party se­cu­rity pro­to­col.

Fi­nally, you have to ex­plain what you mean by "works". Is it that every­one is able to ac­cess every­thing?

Like with many se­cu­rity pro­to­cols you have to think about the treats you are con­cerned with, and what your se­cu­rity re­quire­ments are. It turns out that the se­cu­rity con­cerns that Eran had were quite dif­fer­ent to other peo­ple and hence it was dif­fi­cult to up with only one way to do it. Eran, for ex­am­ple, cared a lot about hav­ing the OAuth client im­ple­men­ta­tion to ac­tively par­tic­i­pate in the cryp­to­graphic pro­to­col ex­change (via a keyed mes­sage di­gest) but he didn't care much about pri­vacy or pro­tect­ing the data that was ex­changed as a re­sult of a suc­cess­ful OAuth 2.0 au­tho­riza­tion. His views were most likely dri­ven by what Yahoo needed and those as­pects weren't im­por­tant to them (as it still seems). But not every­one has the same needs.


From: Pra­teek Mishra (Feb 06 2013, at 06:50)

Two com­ments -

1) I would be in­ter­ested in learn­ing more about An­droid util­i­ties/li­braries that make it eas­ier to use OAuth 2.0 for ap­pli­ca­tions on mo­bile de­vices. We also find this as an area of dif­fi­culty.

You men­tion in­vest­ments that Google has made in this area. Are there any plans to make these gen­er­ally avail­able to the An­droid com­mu­nity?

2) Re­gard­ing the var­i­ous flaws of OAuth 2.0, well, I be­lieve these per­cep­tions may be shaped by (lack of) ex­pe­ri­ence with iden­tity sys­tems.

Use of bearer in­stru­ments (e.g., cook­ies) over TLS is the norm on the in­ter­net; ap­pli­ca­tion-level sig­na­ture and en­cryp­tion is MUCH more com­plex and er­ror-prone. Fi­nally, a com­par­i­son with the SAML 2.0 spec­i­fi­ca­tions (an­other multi-party pro­to­col) would pro­vide a fairer test to as­sess OAuth 2.0 com­plex­ity.


What this is · Subscribe to ongoing
Truth · Biz · Tech
author · Dad · software ·colophon · rights
picture of the day
January 232013
· Technology (74 fragments) 
· · Identity (39 more) 
· · Web (376 more)

By Tim Bray.

I work for Google, but 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.

想对作者说点什么? 我来说一句


2016年02月04日 1KB 下载