OAuth Authorization vs Authentication

OAuth terminology has been bothering me a long time now. Is OAuth Authorization as some would suggest or is it Authentication?

Correct me if I'm wrong but I have always read Authorization as being the act of allowing someone access to a resource yet OAuth doesn't seem to have any implementation that actually allows access to users to a given resource. All OAuth implementations talk about is providing a user a token (signed and sometimes encrypted). This token is then passed with every call to a back-end service endpoint where it is checked for validity, again not an OAuth concern.

Is OAuth Authentication (every article says it isn't) which I take it requires a user to provide credentials which in turn proves a user should/shouldn't have access?

So it seems that OAuth is not Authorization NOR Authentication since these have to be performed by other processes. So what the heck is it? Is it a process for communicating a token? Is it fluff word that really has no specific meaning?

It's hard to ask a question about this subject without sounding enigmatic and superstitious (ghosts and goblins) so I expect that answering this question won't be a simple thing either. Enter at your own risk.

OAuth is a specification for authorization

OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:

> The authorization endpoint is used to interact with the resource owner > and obtain an authorization grant. The authorization server MUST first > verify the identity of the resource owner. The way in which the > authorization server authenticates the resource owner (e.g., username > and password login, session cookies) is beyond the scope of this > specification.

OAuth authentication?

Authentication deals information about "who one is". Authorization deals information about "who grants what permissions to whom". Authorization flow contains authentication as its first step. It is the reason people are often confused.

There are many libraries and services that use OAuth 2.0 for authentication. It is often called "social login" and It makes people more confused. If you see "OAuth authentication" (not "OAuth authorization"), it is a solution using OAuth for authentication.

OpenID Connect

OpenID 1.0 and OpenID 2.0 are old specifications for authentication. Those who made the specifications expected people to use OpenID for authentication. However, some people began to use OAuth 2.0 for authentication (not for authorization) and OAuth authentication has prevailed rapidly.

From a viewpoint of OpenID guys, authentication based on OAuth was not secure enough, but they had to admit that people preferred OAuth authentication. As a result, OpenID guys decided to define a new specification, OpenID Connect, on top of OAuth 2.0.

Yes, this has made people much more confused.

One-sentence definitions of OAuth 2.0 and OpenID Connect

OAuth 2.0 is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.

OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user's identity information which is managed by a service.

^{(Sorry, these definitions are excerpts from the overview page of my company)}

Definitions from a viewpoint of implementors

Authentication is a process to determine the subject (= unique identifier) of an end-user. There are many ways to determine the subject. ID & password, fingerprints, iris recognition, etc.

Authorization is a process to associate the subject with the requested permissions and the client application that requested the permissions. An access token represents the association.

See Also

1. Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings
2. Diagrams And Movies Of All The OAuth 2.0 Flows
3. Diagrams of All The OpenID Connect Flows
4. The Simplest Guide To OAuth 2.0

OAuth is an authorization protocol. It is not designed for authentication. Yes, there is a step in the OAuth process where the identity server authenticates a resource owner. The way it happens does not belong to the OAuth protocol. That is why OAuth does not concern itself about authentication.

OAuth performs authorization by giving an access token to a third party (service provider) and that party will be able to authorize access to the resource by presenting the token.

Let's say there is a requirement that a service provider wants to access resources (protected by an identity server) on behalf of the resource owner. So the resource owner will first authenticate and then will grant permission for the service provider to access specific resource. Then the identity server will issue an access token for service provider. Later the service provider can access the resource with that token.

Here, OAuth does not care about who is carrying the access token or trying to access the resources. It validates the access token, and lets the third party access the resources.