The OAuth 2.0 (and the updated OAuth 2.1) specification defines a delegation protocol that is useful for conveying authorisation decisions across a network of web-enabled applications and APIs.
Since OAuth 2.0 is used in a wide variety of applications that include user authentication, many people incorrectly conclude that OAuth itself would be an authentication protocol. However, let us be clear: OAuth 2.0 is not an authentication protocol. It does assume authentication of the user and user authentication can happen alongside the OAuth 2.0 authorisation protocol, but OAuth 2.0 itself is not an authentication protocol (as opposed to for example SAML***). In fact, OAuth 2.0 does not even require the user to be present*.
User authentication tells an application (1) that a user has proven to be present and (2) that the user has been vouched for or registered. A full authentication protocol may also provide a number of attributes about this user, such as a unique identifier, an email address, and what to call them when the application says “Good Morning”. Authentication is all about the user and their presence with the application, and an internet-scale authentication protocol needs to be able to do this across network and security boundaries. Strictly speaking, user authentication services do not need to provide identity details. In fact, they are only vouching for the user.
Back to OAuth 2.0: it is not designed to tell the application anything about the user, nor does it say how the user proved their presence or even if they’re still there. OAuth 2.0 is essentially anonymous.
The OAuth 2.0 process does, however, usually include several kinds of authentication in its process as it requires the client side to be fully authenticated, which may or may not include user authentication. It is tempting to consider reception of an access token of any type proof that authentication has been carried out. However, mere possession of an access token doesn’t tell anything about the user on its own.
OAuth 2.0, however, enables an ‘authentication and identity protocol’ to be created on top of its authorisation protocol. OpenID Connect** is such a protocol. Most implementations of OpenID Connect issue an identity token along side an OAuth 2.0 access token. One major benefit of building authentication on top of authorisation this way is that it enables proper management of user consent.
Notes
* OAuth 2.0 is essentially a delegated authorisation protocol. The client does not need to a user (human being) but can equally be a service. In fact, OAuth 2.0 is designed to enable authorisation to be obtained by one microservice to access another microservice.
** OpenID Connect is an ‘‘authentication and identity protocol’ designed on top of OAuth 2.0 and issues identity tokens.
An identity token is often issued in addition to (and not in lieu of) an access token, allowing the access token to remain opaque to the client as it is defined in regular OAuth 2.0. Strictly speaking, the identity token is in fact an access token that gives the authorisation to… access the identity provider (more specifically: its UserInfo endpoint).
An identity token is a signed JSON Web Token (JWT) that is given to the client application along side the regular OAuth access token. The identity token contains a set of claims about the authentication session, including an identifier for the user (sub), the identifier for the identity provider who issued the token (iss), and the identifier of the client for which this token was created (aud). Additionally, the identity token contains information about the token’s valid (and usually short) lifetime as well as any information about the authentication context to be conveyed to the client, such as how long ago the user was presented with a primary authentication mechanism. Since the format of the identity token is known by the client, it is able to parse the content of the token directly and obtain this information without relying on an external service to do so.
The identity token itself is signed by the identity provider’s private key, adding an additional layer of protection to the claims inside of it in addition to the TLS transport protection that was used to get the token in the first place, preventing a class of impersonation attacks. By applying a few simple checks to this identity token, a client can protect itself from a large number of common attacks.
In case the identity provider is also the authorisation server, the identity token also provides a location to add detached signatures over the authorisation code (c_hash) and access token (at_hash). These hashes can be validated by the client while still keeping the authorisation code and access token content opaque to the client, preventing a whole class of injection attacks.
***As opposed to OAuth 2.0, SAML (Security Assertion Markup Language) describes a framework that allows one system to perform both authentication and authorisation on behalf of other systems. SAML can thus provides single sign-on functionality on its own. Strictly speaking, the name SAML refers to an XML variant language, but the term can also cover various protocol messages and profiles that make up part of the open SAML standard. Note that SAML is not well suited for consumer authorisation: it assumes federated identity management and it is not designed to take end user consent into account. OAuth 2.1, also specifies how a SAML token for authentication can be used to obtain an OAuth 2.1 access token for authorisation.
Further reading
More information on the authorisation aspect can be found here:
More information on authentication can be found here:
Controlled AI services 