Is OAuth for Authentication or Authorization? | FusionAuth | FusionAuth Docs/Articles

Light<br>Dark<br>System

Log In

Get a demo<br>Open main menu

Is OAuth for Authentication or Authorization? | FusionAuth<br>By Dan Moore

OAuth, a standard for securely delegating authorization information, and OIDC, a profile written on top of it to securely transmit user profile data, both rely on proper user authentication. (A user is also known as the 'resource owner'.) An architectural component known as the authorization server issues tokens, which provide access to data or functionality, only after the user has been authenticated to its satisfaction.

However, there is little guidance about how to actually authenticate the user. Should you use a username and password? A magic link? Delegate to a third party? Require a TOTP code? Some combination of these?

Why exactly is authentication undefined in OAuth/OIDC? Why is this critical process not precisely defined in these specifications?

While OAuth grants differ slightly (see The Complete List for all the variations), the grant flow is basically:

The user (or, more precisely, some software acting on behalf of the user) tries to access a protected resource

The protected resource redirects the user to the authorization server

The authorization server authenticates the user

The user is sent a token

The token is presented to a protected resource

The protected resource validates the token

The user is granted access to a protected resource

This is a high level, truncated version, and there's a lot more, but let's keep it simple here. If you'd like even more details about the OAuth process, please check out the Modern Guide to OAuth.

Looking At the Standards#

The Authorization Code grant is the main OAuth grant involving users, so let's start there.

OAuth2 and OAuth2.1#

If you look closely at the specifications, it's clear that authentication is critical to this grant. From RFC 6749, the OAuth2 standard, the authorization server is:

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

What else does it say about authentication of the end user? Well, in section 1.3.1, you see:

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner and obtains authorization. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client.

It's clear that:

Authentication happens at the authorization server, and

The resource owner's credentials are never shared with other parts of the system, including the client which is requesting access to any protected resources.

However, the means of authentication is never defined in the specification.

How about the OAuth 2.1 specification, currently under development? It's similar to the OAuth2 standard, but the 2.1 specification expanded section 1.3.1:

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner, and may request the resource owner's consent or otherwise inform them of the client's request. Because the resource owner only authenticates with the authorization server, the resource owner's credentials are never shared with the client, and the client does not need to have knowledge of any additional authentication steps such as multi-factor authentication or delegated accounts.

You start to learn something about the authentication process: the "additional steps" such as MFA are part of it. But there's no full definition of how the authorization server can or should verify who the user is.

Well, OAuth is about authorization, not authentication. Perhaps OIDC spells out how you should authenticate the user? Let's look at that next, since there is, after all, an entire section titled "Authentication".

OIDC#

This section begins:

OpenID Connect performs authentication to log in the End-User or to determine that the End-User is already logged in. OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it. For this reason, the Client is called Relying Party (RP) in this case.

and further on covers the authentication process briefly.

If the request is valid, the Authorization Server attempts to Authenticate the End-User or determines whether the End-User is Authenticated, depending upon the request parameter values used. The methods used by the Authorization Server to Authenticate the End-User (e.g. username and password, session cookies, etc.) are beyond the scope of this specification. An Authentication user interface MAY be displayed by the Authorization Server, depending upon the request parameter values used and the authentication methods used.

So not only is authentication not defined, it is explicitly declared out of...