6 ms·

OAuth 3.0: the sane and simple way

144 points by llambda 14y ago

jokull 14y ago
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.
dreamdu5t 14y ago
People should implement Mozilla profiles instead of a new version of OAuth.
- icebraining 14y ago
  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.
- dreamdu5t 14y ago
  Edit: I meant Mozilla Persona.
drivebyacct2 14y ago
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?
heyitsnick 14y ago
Meta: Is it just me or the typography of the blog post barely legible? Especially the code snippets. Windows 7 on chrome.
- donatzsky 14y ago
  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.
- tav 14y ago
  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!
  - donatzsky 14y ago
    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.
    - tav 14y ago
      Thanks — pushed that change.
tav 14y ago
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!]
- yawnt 14y ago
  i'd love to ;3
- jokull 14y ago
  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 https://github.com/ib-lundgren/flask-oauthprovider
- icheishvili 14y ago
  As the author of several OAuth 1.0 libraries (https://github.com/icheishvili/pyoauth https://github.com/icheishvili/pyoauth, https://github.com/icheishvili/phoauth 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.
foz 14y ago
Now would be a great time to put forward a simpler solution to 2.0 so yes please post a completed version!
jms18 14y ago
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.
- aaronpk 14y ago
  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.
- tav 14y ago
  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 http://caniuse.com/#feat=cors [2] https://developer.mozilla.org/en/http_access_control https://developer.mozilla.org/en/http_access_control
  - dlitz 14y ago
    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>"
thinkbohemian 14y ago
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).
Leszek 14y ago
Because developing a new standard always fixes problems.[1] [1] http://xkcd.com/927/ http://xkcd.com/927/
idan 14y ago
Interesting. We develop oauthlib (an OAuth logic implementation for python, https://github.com/idan/oauthlib https://github.com/idan/oauthlib). Will has a chat with the other contributors about implementing this.
Fando 14y ago
Amen! Good analysis and solution.
mcherm 14y ago
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?

144 points by llambda 14y ago

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.

dreamdu5t 14y ago

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

icebraining 14y ago
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.
dreamdu5t 14y ago
Edit: I meant Mozilla Persona.

drivebyacct2 14y ago

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?

heyitsnick 14y ago

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

donatzsky 14y ago
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.
tav 14y ago
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!
- donatzsky 14y ago
  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.
  - tav 14y ago
    Thanks — pushed that change.

tav 14y ago

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!]

yawnt 14y ago
i'd love to ;3
jokull 14y ago
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 https://github.com/ib-lundgren/flask-oauthprovider
icheishvili 14y ago
As the author of several OAuth 1.0 libraries (https://github.com/icheishvili/pyoauth https://github.com/icheishvili/pyoauth, https://github.com/icheishvili/phoauth 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.

foz 14y ago

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

jms18 14y ago

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.

aaronpk 14y ago
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.
tav 14y ago
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 http://caniuse.com/#feat=cors [2] https://developer.mozilla.org/en/http_access_control https://developer.mozilla.org/en/http_access_control
- dlitz 14y ago
  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>"

thinkbohemian 14y ago

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

Leszek 14y ago

Because developing a new standard always fixes problems.[1] [1] http://xkcd.com/927/ http://xkcd.com/927/

idan 14y ago

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

Fando 14y ago

Amen! Good analysis and solution.

mcherm 14y ago

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?