Happy Birthday, OAuth 2.0! It has been ten years since OAuth 2.0 was specified. Since then, the protocol has been updated, improved, and extended by numerous complementary specifications. The vast number of specifications can make it challenging for a beginner to grasp the basics of the protocol. This article aims to introduce the OAuth protocol and explain the core concepts.

OAuth Basics

OAuth is designed to give a user control over what resources an application may or may not access on behalf of the user without having to share credentials. Imagine a service where the user has registered. To access any resources on that service, the user must authenticate.

Now, imagine a third-party application that wants to integrate with that service and present data to the user. The user could simply share their personal credentials with the third-party application. Yet, by doing so, the user would grant the third-party application unrestricted access to all their resources. There is also no way for the user (or the service) to control or revoke the third-party application’s access. OAuth addresses this problem by separating the application’s credentials from the user’s credentials.

The formal roles within OAuth are:

• The resource owner: The entity granting access to some resources, often the end-user.
• The resource server: The entity hosting the protected resources, such as an API. The resource server requires and validates access tokens as part of processing requests.
• The (OAuth) client: The application that requests access to protected resources on behalf of the resource owner. It uses the access token to prove authorization.
• The authorization server: The entity that authenticates the resource owner, obtains authorization, and issues access tokens to the client.

How Does OAuth Work?

Before accessing any resources under the control of the resource owner, the OAuth client needs to request authorization (permission) from the resource owner. The granted authorization (or delegated access) is described by an access token that the authorization server issues. The application uses the access token as its credentials to access resources on behalf of the user. A common and widespread representation for access tokens is the JSON Web Token (JWT) format. Ideally, such an access token contains all the data required for the resource server to determine if and to which extent the user granted access.

The OAuth client can either request access directly from the resource owner or indirectly via the authorization server, which is the preferred option. There are different ways for an OAuth client to request permission and gain an access token via the authorization server. In OAuth, the various methods are called grant types, but at Curity, we call them flows.

A flow describes the details of the communication between the OAuth client and authorization server, specifying the HTTP requests and responses for the OAuth client and authorization server. One such flow is the code flow. The OAuth client receives a one-time-use-only authorization code as part of this flow. To retrieve the token, the client needs to authenticate and present the authorization code to the authorization server. Consequently, the code flow authenticates both the resource owner and the OAuth client, which makes it a favorable flow.

Understanding OAuth Flows

There are different methods for client authentication. The most basic method is to have the client present a client ID and secret, just like a username and password. In some cases, more secure methods may be required, such as Mutual TLS where the client uses a certificate to authenticate to the authorization server to retrieve the token. Another advanced option is client-asserted JWTs, where the client presents a self-signed JWT during authentication.

An essential aspect of OAuth is that the authorization server authenticates the resource owner, not the application or the resource server. The central role of the authorization server is the reason why OAuth often lends itself to single sign-on. Depending on the authorization server, the user can choose between different authentication methods, or the authorization server can enforce specific policies. For example, the authorization server can implement multi-factor authentication or, in general, adapt the authentication process depending on the context such as the OAuth client, the user’s location, or the date or time of the request. Having all these options improves the system’s overall security and strengthens user assertion.

It’s relatively easy to integrate with the authorization server and benefit from its security features. Since OAuth has been around for quite some time, there are libraries with related tutorials and documentation, as well as many code examples that assist with the implementation. Using an OAuth client in your application lets you integrate in a standardized way with (basically) any authorization server.

It’s not just client-side security that improves with OAuth. OAuth also protects the resource server. Instead of validating user credentials, the resource server, commonly an API, validates access tokens. There are libraries, tutorials, and examples that help on the way, enabling developers to add OAuth functionality to APIs with simple code or configuration. The API checks that the access token is issued by a trusted issuer, such as a known authorization server. In practice, this means validating a JWT, checking its signature, and using the claims from the JWT to enforce authorization. The challenge is to design the access token to meet business logic requirements and integrate smoothly with the technical stack in a company. Since every business is different, it’s important to choose an authorization server that is flexible enough to handle different requirements and that allows you to adapt to changes.

Final Thoughts

OAuth has now grown into a very powerful tool for securing API access. OAuth enables access management by allowing for the dynamic creation of access tokens when needed, with just the permission (scopes and claims) required for the task, and supporting the revocation of the same. Consequently, OAuth is much more than a simple protocol. It is an extensive framework and a vital part of a modern Identity and Access Management (IAM) solution.