Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have seen posts that insist that OAuth is an orthogonally different thing from OpenID, because OpenID is about authenticating users, while OAuth is about giving access to certain services to a third party.

However, I know a lot of people uses OAuth as authentication anyway, as illustrated here, Wikipedia calls it "pseudo-authentication", but it looks like a valid way to go. Is there any drawback compared to using OpenID? if OAuth is OK for authentication, does it mean that OAuth can do everything OpenID does, but OpenID can't do somethign that OAuth does (like accessing services). Why would people use OpenID as opposed to OAuth then?

Note: I am a beginner, so please excuse me and point out if I miss something fundamental here.

share|improve this question
Common pitfalls for authentication using OAuth, straight from the horse's mouth, may be worth reading. – antak Feb 22 at 5:17

Whenever I compare the two I think of them as the difference between an active and passive identification/authentication model with openID being passive, OAuth active.

Passive tells the requesting application what to do, such as a web browser redirecting from identity provider to application, and the browser is a basic dumb client because it only does whats it's been told to do. Active requires that the requesting application know what to do when it's handed data, and it does whatever it wants with the data, e.g. the token.

Active models allow the application to make a direct request to an API with the users token because it's got the token stored locally. Passive models require the user to authenticate with a redirect to the provider, and return back to the application with a temporary token. (not technically temporary, but it fits the explanation)

Depending on what you are trying to do with your application, either model could work.

share|improve this answer

OAuth was designed for cases where Application X needs access to resources (e.g., "my photos" or "my email address" or "my calendar") controlled by Application Y and belonging to User A — User A may want to grant access to those resources on Application Y, but he doesn't want to give Application X his actual username/password credentials. So an access token is used as an alternative credential for a resource on Application Y. Access tokens can be revoked independently of username/password credentials and are, ideally, tightly scoped to only allow access to specific resources.

Using OAuth 2 for authentication overloads that model in ways that can be risky. Look at the example above, and imagine it being used for authentication. If Application X uses that access token for authentication, then it's taking a token that grants access to resources on Application Y, and using it to grant access to its own resources. Maybe that's splitting hairs, because the important thing is that we know that the act of granting an access token via OAuth 2 implies that the user has successfully authenticated. The problem is that the access token doesn't say anything about which application the end user authenticated for. So what happens if Application Z also has an access token for User A's resources on Application Y? If Application Z can get Application X to use this access token, then it has access to User A's resources on Application X. That's bad. User A may have trusted Application Z to access his resources on Application Y, but User A certainly never granted consent for Application Z to access his resources on Application X.

OpenID and OpenID Connect are specifically designed for authentication. OpenID Connect is built on top of OAuth 2 so that it can take advantage of existing interactions and flows, but it adds an entity called an ID token, which is an object containing a set of claims about an authentication event. Those claims include an identifier for the user who performed the authentication, an identifier for the server that handled the authentication, and an identifier of the audience of the authentication. This gives an application the information it needs to validate that a user is authenticated on its behalf.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.