CODEWITHSUNDEEP
securityoauthopenid
Alex Churchill
Alex Churchill

Reputation: 4957

Why should I use OpenID for Authentication rather than OAuth?

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?

Upvotes: 24

Views: 7052

Answers (2)

Eran Hammer
Eran Hammer

Reputation: 7206

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.

Upvotes: 12

drf
drf

Reputation: 8699

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.

Upvotes: 10

Related Questions