
OAuth 3.0: the sane and simple way  - llambda
http://tav.espians.com/oauth-3.0-the-sane-and-simple-way-to-do-it.html
======
tav
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!]

~~~
jokull
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>

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

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

~~~
tav
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>

~~~
dlitz
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>"

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

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

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

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

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

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

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

------
mcherm
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?

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

~~~
tav
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
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
Thanks — pushed that change.

------
Fando
Amen! Good analysis and solution.

------
drivebyacct2
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?

