Why should I use OpenID for Authentication rather than OAuth?

24
votes

I've read repeatedly that OpenID is better for authentication than OAuth (which is for authorization), including several other posts on SO.

The case also seems to be made in this often-cited article.

However, I'm a bit unclear on why I should favor OpenID for authentication, vs. an honest OAuth provider (e.g. Twitter or Facebook OAuth 2.0). The other SO posts I've read explain the different use-cases, and I understand the difference between what the protocols are designed to do, but they don't explain why one could not use OAuth to authenticate.

Here are the reasons I can come up with and my (perhaps misguided) repsonses:

  1. OAuth is really for Authorization. Having users authenticate using OAuth gives a consumer more privilege than they need.
    • Response: This is generally true, but is far more limited in the case of fine-grained OAuth (such as Facebook provides) that allows me to only request very minimal permissions. In fact, many sites such as Facebook provide OAuth, but not OpenID, presumably because they are more interested in authorizing consumers than authenticating clients. If I want to provide clients with more authentication options, OAuth seems to give that to me.
  2. OAuth sessions tend to live longer
    • Response: Not relevant if I'm a consumer intent on authenticating clients; I'll do my own session management and could even get rid of the OAuth tokens immediately as soon as I'm done authenticating my users.

What authentication advantages does OpenID provide compared to using large-scale OAuth providers for authentication?

2
securityoauthopenid
You've already linked a good article explaining it, what's the question? Authorization and authentication are two entirely separate, independent things, why are you asking whether you should do one instead of the other? – Kerrek SB
The article explains the different use-cases. Plenty of sites use Facebook for authentication, despite the fact that they are technically authorized to view a person's basic information (which is a common extension to the OpenID protocol in any case). The question is: is using OAuth for authentication bad and if so, why? – Alex Churchill
I'd say "because OAuth is not a technology for authentication". It's like asking whether it's bad to use a microwave to make ice cubes... I think the article makes that reasonably clear. – Kerrek SB
That's a surprisingly tongue-in-cheek response, given how commonly it is used for exactly that. I've already explained in the question that I'm not asking what the protocol is designed for. I'm asking specifically why it is bad. – Alex Churchill

2 Answers

12
votes

The main question you need to ask yourself is if you know ahead of time which providers you want to support. If you want to allow users to use any provider they way (with OpenID support such as Google, Yahoo, AOL, etc.), you should use OpenID. But if you know most of your users will want to use Twitter, Facebook, or one of the other popular OAuth providers, use those.

The technical terminology is that OAuth provides delegated authentication while OpenID provides federated authentication. Now, it is true that OAuth is an authorization protocol and not an authentication protocol, but by providing you with /me (Facebook) or /account/verify_credentials (Twitter), these providers extended OAuth for use as an authentication protocol.

But you shouldn't use OpenID. It's a dead protocol.

10
votes

The fundamental challenge with using OAuth for authentication is that you would need to assume ones identity based on access to a given resource. In some cases, this may be a valid assumption, but OAuth does not guarantee it. If access to the resource you are using for authentication is delegated to another party, and you are presuming an identity based on access to that resource, then that is a vulnerability that can allow an imposter to authenticate on another subscriber's behalf. This has nothing to do with the OAuth provider's honesty or lack thereof, and everything to do with a tool being used in a manner for which it was not designed.

In the case of Facebook, OAuth can support authentication predicated on only the subscriber being able to authorize the application: if you receive authorization to access an individual's profile, it means the subscriber must have authenticated to Facebook. It appears this is a supported use case. However, if Facebook later allows, for instance, other applications or users to authorize resources on behalf of its subscribers, then that guarantee is lost.

Ultimately, to use OAuth for authentication, you need to make a lot of assumptions. You need to assume that the user you are authenticating and only that user have access to delegate a given resource; you have to assume that the request data you receive is sufficient to bind to a known identity; you have to assume that the authentication mechanism was sufficient for authentication to a third party (what if the file wasn't sensitive and anonymous access could be granted?); and you have to assume that these qualities are persistent over time. OpenID is built specifically for this; OAuth is not.

Can you safely make these assumptions? In the case of Facebook, possibly; they appear to be documented and supported use cases (I'm not familiar with the specific API). But generally, it's not a supported OAuth use case.