

The Good and the Bad of OAuth 2.0 Authorization Implementations - goronbjorn
http://john-sheehan.com/post/41653656681/the-good-and-the-bad-of-oauth-2-0-authorization

======
socalnate1
I love that the first comment on this is from Mike Krieger, one of the
founders of Instagram trying to fix the "bad."

The idea that a guy who just made $100 million is reading hackernews on a
Sunday night, and immediately tries to address a product issue he stumbles
upon makes me happy.

~~~
dwolchon
I had the same thought. Awesome.

------
conradev
Also interesting is that Google will soon not require a client_secret
parameter for installed applications[1], as it is impossible to keep secret.
This is technically legal according to the spec, which states that "the client
MAY omit the parameter if the client secret is an empty string"[2].

[1]
[https://groups.google.com/d/msg/oauth2-dev/HnFJJOvMfmA/JzZ8J...](https://groups.google.com/d/msg/oauth2-dev/HnFJJOvMfmA/JzZ8JA717BYJ)

[2] <http://tools.ietf.org/html/rfc6749>

------
ecesena
[related] This year at CCS conference: San-Tsai Sun and Konstantin Beznosov,
The Devil is in the (Implementation) Details: An Empirical Analysis of OAuth
SSO Systems <http://css.csail.mit.edu/6.858/2012/readings/oauth-sso.pdf>

~~~
peter_l_downs
Thanks for posting this! Great overview of potential implementation flaws.
From the article:

    
    
        In some RPs, access
        tokens are appended as query parameters to the RP's sign-in
        endpoint (i.e., the URI that issues the authenticated session
        cookie), which reveals the tokens in the browser's history
        and server logs.
    

The official spec only supports including the access token in a URL-encoded
body of a POST request, or as part of an Authorization header [0]. This is one
of the biggest differences between the official spec and most current (not up
to spec) implementations.

Also disappointing^H^H^H^H^H^H^H^H^H^H^H^H^H interesting:

    
    
        Surprisingly, our evaluation shows that only 21% of RPs em-
        ploy SSL to protect SSO sessions, even though about half of
        tested RPs have protected their traditional login forms with
        SSL.
    

The relevant part of the specifcation [1]:

    
    
         Always use TLS (https):  Clients MUST always use TLS [RFC5246]
         (https) or equivalent transport security when making requests with
         bearer tokens.  Failing to do so exposes the token to numerous
         attacks that could give attackers unintended access.
    

[0]: <http://tools.ietf.org/html/rfc6750#section-2> [1]:
<http://tools.ietf.org/html/rfc6750#section-5.3>

------
eksith
It's interesting that people who harp on about avoiding a single point of
failure would gleefully go along with a single login option. Mind you, these
are the same folks who insist you shouldn't use one password everywhere. But
one login (which may still have one password) is totally OK.

Very interesting.

------
peter_l_downs
Something to be aware of is that as of the last time I checked (a month or two
ago) most of these providers do not implement the finalized 2.0 specification
[0]. I was lucky enough to have to write an implementation recently, and using
Google's and Facebook's docs as a reference often led to confusion.

[0] <http://tools.ietf.org/html/rfc6749>

------
sergiotapia
I always felt that implementing OAuth authorization was much too complicated.
I used to think it was because I'm an idiot, but seeing so many people have
trouble with the same thing makes me doubt myself.

I've used Mozilla Persona and THAT was straightforward. I can't help but feel
that Person is what OAuth should have been. Secure, simple login for my
grandmother, and easy to implement and integrate for Joe Coder.

~~~
peter_l_downs
If you decide not to support the HMAC stuff, writing a server implementation
for OAuth 2.0 isn't really that bad. Something I've been confused about since
day one is the need for refresh token. If an attacker is able to sniff the
auth token, wouldn't they be able to sniff the refresh token, too?

~~~
mikeknoop
What's worse is when OAuth providers force the refresh tokens to be refreshed!
Many OAuth providers are now requiring user-action (ie. re-walk through the
oauth popup) every x months to get new refresh tokens.

~~~
X-Istence
As a user I am actually okay with this. That way if I haven't visited a
website in a long time, then most likely they should no longer have access to
my account.

Maybe I've long moved on and forgotten about that one site that I authorised
and now they are using my data in a way that I wouldn't approve of.

~~~
johns
The tricky part is for services like IFTTT (where I used to work) and Zapier
(where the GP works) where you do want an authorization to be indefinite and
not require user interaction because it's a background job.

------
flyinRyan
I must be missing something here. If someone hacks an oauth provider (e.g.
Facebook, Google, etc.) and gets my password _there_ does that not mean they
can then log into any service that supports oauth as me at that point?
Probably even if I have purposely avoided ever using oauth for anything?

How is this different from the vulnerability of using the same password
everywhere?

~~~
csears
Using the same password everywhere means a hacker only has to break the
weakest of any service you use to get at all your accounts. Using oauth or any
single-sign-on system allows you to put all your eggs in one (potentially)
more trusted basket.

Your scenario certainly is a legitimate concern, but it depends on how the
other services implement account linking. If you create a non-oauth account
and then sign in with Facebook, some services will allow you to link the
accounts based on your email address matching, others won't.

Of course in the case of Google, if someone hacked your account, they would
probably also have access to your Gmail and could reset passwords from any
other service. So the risk isn't significantly different.

As a general rule, I only use oauth SSO on sites that I trust less or care
about less than my oath provider.

