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.
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].
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.
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.
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.
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.
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?
My understanding, and it may be wrong, is that if an attack walks off with your data, then wouldn't be able to refresh the access token you have on hand without the client ID and secret and so the extent to which they could compromise the authorized accounts is limited in time.
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.
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.
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.
OAuth 1.0a is far too complex. OAuth 2.0 for the simple and common cases is not that bad since there's no signature to generate.
Most of the issues from OAuth 2 stem from a fluid spec that wasn't finalized until recently. Now that that's done hopefully the situation will stabilize and once you learn how to use one (I also recommend making the requests directly yourself and not using a library) you'll easily be able to use all the others without having to search out all the quirks I wrote about in this post.
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?
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.
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.