The Components of OAuth 2.0

One of the first things that can confuse people just getting started with OAuth 2.0 is all the many different components that make it up. OAuth, which is gaining popularity especially with mobile apps and Single Page Applications where there is a client and API server, two distinct systems that run independently of each other, is a departure from the traditional session or cookie-based authentication methods and includes concepts created to operate in zero-trust environments. This blog post will give you a quick overview of the primary components you'll need to be aware of when getting started with OAuth 2.0.

Resources, Resource Owners and Resource Servers

There's no point in having security if you have nothing to protect. Resources are the data or actions which you are protecting. This could be anything, from a person's private information, a calendar, photos or the switch to turn on and off your network-connected espresso machine. What a resource is really just depends on what you are building, but in essence, they are whatever you need to limit access to.

The resource owner, is the physical individual, the actual human being, who owns the resource or who has been given access. The resource owner is not a digital concept, while it may be represented by a row in a database table that stores their details, it is still the actual human being behind it.

The resource server is the server on which these resources can be accessed. In most situations, this is the API endpoint you call to get information or make changes. This is different to the authorization server however, and while the code for both might exist in the same codebase, be run on the same server, use the same framework and for all intents and purposes seem to be the same thing in any one individual system, in OAuth 2.0 they are two distinct components each with a separate purpose.

Clients

An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). RFC 6749

The resource owner doesn't access the resource server directly, they use a client. A client is any application that accesses resources on a resource server on behalf of a resource owner. Put simply, this is the user interface someone uses to view and interact with their resources and can any device capable of communicating with the resource server, from obvious things such as mobile and web applications you login to to directly access and manage your resources, to smart tvs and thermostats. This access can be done both while you are online and actively using the client, as well as completely independently based on the client type and the permissions given to the client by the resource owner.

In Oauth 2.0 there are two types of clients, public clients and confidential clients. Public clients are clients which are incapable of keeping a secret secure, which covers things such as desktop, SPA web and mobile apps, or any sort of app which is run in a way where all information is processed on the client device and so any information stored in it could be extracted. Confidential clients are those such as server-side applications and services where additional processing can be done on a device on which the user does not have access and so a secret can be kept secure. This allows for different authentication flows for each, the details of which is outside the scope of this post. For now, it is simply good enough to know the two types exist.

Authorization Server

The authorization server is the central component of OAuth 2.0. It handles all authentication logic, issues the access tokens and hosts the relevant information. The authorization server is where the user goes to enter their username and password, where developers go to register clients they'll be using, and where resource servers can go to validate access tokens.

Access Token

An access token is a string provided to the client to give it access to the resource server on behalf of the resource owner for a specified set of actions or resources. This string can be anything, though more often than not it is a JWT token. The format of the access token is irrelevant and doesn't need to be understood by the client, it simply represents time-limited access to specific resources on a specific resource server granted by the resource owner and validated by the authorization server. Access tokens are most commonly bearer tokens, which means that anyone with this access token will be able to access the specified resources until the access token expires or is revoked if such a mechanism exists. This authentication method is stateless and the token must be added to every HTTP request you make to the resource server for all protected resources.

Scopes

Finally, we come to scopes. Scopes allow you to limit what the client can do with the access token on your behalf. Rather than an access token being a carte blanche for the client to do anything it wants on your behalf, they are instead limited to a set of actions or records. For an example, if you wanted to give a client the ability to read your emails, but not write them, the resource server might have a scope called "email.read" which you approve for the client, and "email.send" which you do not approve for the client. The name of the scope can be anything, but a common pattern is to name it in the format object.action, which is why in the examples we seen email.read, email is the object, and read is the action. Access tokens should include 1 or more scopes.