24

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?

Improve this question
4
  • 1
    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? Commented Aug 15, 2011 at 0:43
  • 1
    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? Commented Aug 15, 2011 at 0:45
  • 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. Commented Aug 15, 2011 at 0:47
  • 11
    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. Commented Aug 15, 2011 at 0:50

2 Answers 2

Reset to default
12

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

I'm not sure OpenID is a dead protocol; it is moving toward OAuth anyway with OpenID connect, but this definitely affirms what I suspected when asking this question (essentially that OAuth can/is used as securely as OpenID for authentication). To summarize (correct me if I'm wrong): for general purposes, OpenID is good for authentication while OAuth might not be, but if the OAuth provider has good authentication APIs, OAuth authentication is equally good/secure.
OpenID is useful if your users are likely to have an OpenID provider identity and that you are happy to allow any provider for authentication, including self-issued OpenID identifiers (e.g. using a Wordpress plugin for the server). The problem is that most of those self-issued providers are insecure. By pre-selecting the providers you trust and using OAuth, you get both secure login and an access token to extend your application with useful resources from the other providers. I would argue you get better security using OAuth.
The last line really shocked me. Are you serious about that..? I am novice in all that and continuously obsessing my self to choose one over other. Please give me straight advice.
@Eran Hammer - you cannot reliably implement "connected accounts" using oauth. When user authorizes with oauth provider all your app gets is an access token. You cannot use such access token as unique identifier that binding to your app's profile as access token might change. So when token has changed and user tries to login to your app and user the same profile in your app using the same twitter oauth account (but a different token) -> your app will not know who the user is. Oauth is for authorization,not authentication. You saying it's a dead protocol - I think you're wrong.
10

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.

Improve this answer

2 Comments

Cool, thank you for the comprehensive explanation. Facebook Connect indeed does provide an API which can consistently authenticate (FB.api('/me', ...);), but the distinction does make sense to me.
This is completely wrong. Both protocols are valid for authentication and in practice OAuth usually provides a more secure implementation.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.