有趣的 oAuth2 OpenID Con­nect

翻译 2013年12月04日 23:08:09

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.


OAuth和OpenID区别 转自:http://www.cnblogs.com/linyc/p/4338092.html 用通俗的例子解释OAuth和OpenID的区别【原】 ...
  • yueguanyun
  • yueguanyun
  • 2017年08月04日 18:16
  • 268

OAuth1 OAuth2 OPenid 整合 带源码

OAuth1 OAuth2 OPenid 整合 带源码 源代码下载地址:http://www.zuidaima.com/share/1609651248630784.htm...
  • springmvc_springdata
  • springmvc_springdata
  • 2015年09月02日 10:23
  • 823

OpenID Connect:OAuth 2.0协议之上的简单身份层

OpenID Connect是什么?OpenID Connect(目前版本是1.0)是OAuth 2.0协议(可参考本人此篇:OAuth 2.0 / RCF6749 协议解读)之上的简单身份层,用 A...
  • jkx1132
  • jkx1132
  • 2017年09月10日 07:46
  • 311

Apereo CAS 5.0.X 启用OAuth/OpenID认证

  • chen517611641
  • chen517611641
  • 2017年03月07日 15:46
  • 4350


开源中国http://my.oschina.net/xshuai/blog/293458也是本作者 https://open.weixin.qq.com/ 这个是授权登陆自己网站的和我的这个是有...
  • u010651369
  • u010651369
  • 2016年01月06日 17:21
  • 5118

cas sso oauth openid saml的联系与区别

这几个设计用户认证、鉴权、单点登录的概念相互交织,很难区分,项目需要做了较为深入的分析和实现,将经验纪录分享,欢迎探讨拍砖。 首先,SSO英文全称Single Sign On,单点登录。...
  • cxzhq2002
  • cxzhq2002
  • 2017年12月20日 19:37
  • 118


ttp://mp.weixin.qq.com/wiki这个是官网的接口文档 微信授权获取用户openid-JAVA 第一步:用户同意授权,获取code 在确保微信公众账号拥有授权作用域(scop...
  • u010651369
  • u010651369
  • 2014年07月21日 17:48
  • 10744


接上文,项目搭建后,还需要一个配置文件,方便以后反复修改。 第一个是申请公众号,tx给你的公众号id,第二个是公众号密码,第三个是项目域名,这个以后经常用到,可改为你自己的域名。...
  • heboy19
  • heboy19
  • 2015年12月08日 10:51
  • 3864


OIDC(OpenID Connect), 下一代的身份认证授权协议; 当前发布版本1.0; OIDC是基于OAuth2+OpenID整合的新的认证授权协议; OAuth2是一个授权(authori...
  • monkeyking1987
  • monkeyking1987
  • 2016年05月18日 21:57
  • 3371

通过微信网页授权获取用户OpenId(redirect_uri 参数错误)

一、微信公众平台配置 登陆微信公众平台 开发->接口权限->网页服务->网页账号->网页授权获取用户基本信息->修改 在弹出框中输入申请的花生壳免费域名:j*s**x***.imwork.net 二、...
  • xiaoshuji
  • xiaoshuji
  • 2016年06月07日 10:55
  • 14247
您举报文章:有趣的 oAuth2 OpenID Con­nect