OAuth 3.0: the sane and simple way | Hacker News Reader

OAuth 3.0: the sane and simple way

tav.espians.com

144 pointsllambda24 comments

Author here. I wrote this draft a few years ago after getting frustrated with OAuth 2.0. And, whilst I am grateful for llambda for posting it to HN, it was never meant to be published in this unfinished state. So please bear this in mind as you come across incomplete sections.

I never bothered to finish it back in 2010 since everyone seemed quite content with OAuth 2.0 at that time. However, now that it has been posted, I would love to know if anyone would like to see a completed version.

[Edit: Also, any criticisms of what's already there and thoughts on anything else you feel should be included would be really appreciated. Thanks!]

i'd love to ;3

Standards vacuum. Maybe reach out to the GitHub API dev’s. Having a powerful but open minded adopter would help a lot.

Maybe contact the developer behind flask-oauthprovider [1] (oauth 1). I see you have some flask-sqlalchemy type snippets in there.

[1]: https://github.com/ib-lundgren/flask-oauthprovider

As the author of several OAuth 1.0 libraries (https://github.com/icheishvili/pyoauth, https://github.com/icheishvili/phoauth), I would like to see a completed spec.

The only real problem with 1.0 is the difficulty of implementing it correctly and later debugging it when things go wrong (aka, the infamous generic "Invalid Signature" errors). In my mind, it would go a long way if generating a signature was based on a random nonce (say 16 bytes) + client id + client secret + access token.

I was a bit disappointed that the part on requesting and receiving a token, the really important part, was basically missing. Looking forward to seeing the proposed flow there. The stuff on hashcash is straightforward and hopefully foolproof for implementors and library authors.

The only hard suggestion I have is to fork the the client management part to to an extension standard draft. The Hypermedia zealots are going to have a fit when they see `action: "delete"`. Leave that discussion for later and get the rest out the door.

The /.well-known/ stuff always throws me for a loop. Why not use DNS for service discovery? Has worked well for SMTP for a very long time.

I think the reason most people give is that HTTP requests are usually easier to implement than DNS lookups. I do like the idea of DNS lookups tho, seems cleaner.

Great question. Unfortunately, it's not easy to do DNS queries from within today's browsers. However, all modern browsers already support [1] cross-origin XMLHttpRequests and the Access-Control-Allow-Origin header [2].

Thus a fixed URI like /.well-known/oauth.json would allow us to potentially do everything from service discovery to authorized requests from within client-side JavaScript apps without the need for server-side proxying or interpretation.

[1] http://caniuse.com/#feat=cors

[2] https://developer.mozilla.org/en/http_access_control

This is all way too complicated. All of the service-discovery you need can be encoded in the WWW-Authenticate header.

The only problem that OAuth really solves is coming up with some way for a third party to get an arbitrary set of revocable credentials that authenticate the (user, app) pair instead of just having every app use user credentials directly (because that's a phishing hazard). All we need is a standardized mechanism for getting those credentials, and then we can all continue to use Basic and Digest authentication over HTTPS.

OAuth 2.0 almost does that. It actually allows it, but it just has a little too much extra cruft. If you strip out refresh tokens, replace Bearer and MAC authentication with Basic and Digest authentication, mandate HTTPS, and add a couple of qop-options to the WWW-Authenticate header on the 401 response (see RFC 2617) that identify the authorization and token endpoints, you'd have a working standard, and it would be childsplay for anyone to implement it.

EDIT: So the 401 response would looks something like:

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Basic realm="foo", oauth2_auth="<URI>", oauth2_token="<URI>"

People should implement Mozilla profiles instead of a new version of OAuth.

Do you mean Mozilla Persona / BrowserID?

They serve different purposes; Persona is about authentication, OAuth _may_ be used for authentication but its original purpose is authorization - letting websites and applications access your content from other sites (e.g. letting an application post Tweets in your name) without giving them your password.

Edit: I meant Mozilla Persona.

Because developing a new standard always fixes problems.[1]

[1] http://xkcd.com/927/

Now would be a great time to put forward a simpler solution to 2.0 so yes please post a completed version!

Interesting. We develop oauthlib (an OAuth logic implementation for python, https://github.com/idan/oauthlib). Will has a chat with the other contributors about implementing this.

I wrote an implementation of Oauth 2.0 as a Rails Engine (github.com/schneems/opro). IMHO any future "auth specs" should require a working implementation in code (any language).

I like it. Where can I sign up for the OAuth 3.0 working group (we'll probably need to use a different name) to complete this and then evangelize it?

Meta: Is it just me or the typography of the blog post barely legible? Especially the code snippets. Windows 7 on chrome.

It's not just you. The code snippets use Inconsolata which, in my experience, looks splendid on Linux and absolutely crap on Windows. Presumably he never looked at his site from a Windows computer.

My apologies. As donatzsky correctly assumed, I haven't checked the site on Windows for a long time. An overwhelming majority of my readers have tended to be on OS X or Linux. But thanks for letting me know. I'll make sure to test on Windows too the next time I do a design update. Cheers!

A simple fix would be to add Consolas as the first font in the list. It looks almost the same as Inconsolata, comes standard with Vista/7 and newer versions of Office (including the "Viewers"), and looks good on both Windows and Linux.

Thanks — pushed that change.

Amen! Good analysis and solution.

Is it possible to someone make distinctions in OAuth and OpenID/BrowserID? It seems like a lot of people use OAuth for identity verification rather than accessing data.

Or a different question, would it be possible to craft OAuth 3 in a way that it works great alongside BrowserID?

Reply on news.ycombinator.com