Is there any drawback of using OAuth "pseudoauthentication" as opposed to OpenID?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

• OAuth is an authorization protocol, rather than an authentication protocol. Using OAuth on its own as an authentication method may be referred to as pseudo-authentication.
• OpenID is specifically designed as an authentication protocol.

The crucial difference is that in the OpenID authentication use case, the response from the identity provider is an assertion of identity; while in the OAuth authorization use case, the identity provider is also an API provider, and the response from the identity provider is an access token that may grant the application ongoing access to some of the identity provider's APIs, on the user's behalf. The access token acts as a kind of "valet key" that the application can include with its requests to the identity provider, which prove that it has permission from the user to access those APIs.

Because the identity provider typically (but not always) authenticates the user as part of the process of granting an OAuth access token, it's tempting to view a successful OAuth access token request as an authentication method itself. However, because OAuth was not designed with this use case in mind, making this assumption can lead to major security flaws

Source