Components of OAuth 2.0 / 2.1
Welcome to the first in a series of blog post to help you get started with OAuth. Each post will get progressively more detailed however they can be read in any order you find suitable, and posts will link to each other where more information is available on a given topic.
While the OAuth 2.0 framework does follow a technical specification, many bits are still open to different ways of implementation and so this series will follow what I've seen to be the most common ways of implementing and using OAuth and specifically for end-user authentication in a Client/Server setup where a client accesses a set of API endpoints hosted on a separate server and there can be 1 or more clients and servers in the ecosystem.
In this initial post we talk about the main components of OAuth 2.0 / 2.1.
Components
OAuth consists of 6 primary components:
Resources
A resource is any protected object or data which actions can be taken on. Actions can be anything, but most commonly would be the ability to read or write. These are arbitrary however and will be discussed more in a later post related to Scopes which are commonly used to group resource groups and action permissions together.
An example of a resource might be a a video on a streaming service or the ability to post or edit a review on a restaurant review website or resources created by other users which someone has been granted access to.
Resource Owner
The resource owner is basically the end user. They are the end user which have ownership or access rights in some way over a particular set of resources.
For example, say you have a user named Bob. Bob is a user of your food review website and has some reviews he's posted, some messages he's sent and received and some private reviews he's been granted access to by other users, Bob is the resource owner for all the previously mentioned resources, with varying levels of access to each.
Resource Server
The resource server is the server (in our example an API server) which hosts the resources and handles the authorization logic. So in our client/server setup, the resource server is the server the client calls to retrieve data once the authentication process has been completed.
Authorization Server
The Authorization Server is the component which handles the authentication of a user, returning a token when successfully authenticated or an error code when failed.
The authorization server handles all the logic for both user authentication and client authorization, including what resources a client might be allowed to access, on which server and any other security or business requirements. When a user is authenticated and all other requirements are satisfied, the authorization server generates an access token which is then returned to the client and can be used to access resources on the requested resource server.
It is important to note that user authentication is not part of the OAuth specifications. A user can be authenticated in any manner the authorization server deems adequate, whether its a username and password, biometrics, or a pinky promise that they are who they say they are, authentication is entirely our of scope. It is named the authorization server because it authorizes a client to access resources on behalf of a resource owner. For example, when you login via a mobile application, the only bit which is part of the OAuth specifications is when you tell the authorization server, post authentication, that you allow this mobile application to take actions on resources on your behalf.
Client
The client is the user facing application which is used to access and display resources and data. The client can be a mobile application, a web application (Think SPA), a command line utility, or anything which the user accesses directly. So in our example of a client/server setup, the client is, of course, the client.
It should be noted though, that the client is what directly calls the resource server (e.g. the API Server) and there should be no other components in the middle. This client could however also be a resource server, such as in an MVC type application where both the data and frontend are hosted together.
Access tokens
Finally, to tie it all together, we have access tokens. Access tokens are strings which are used to grant access to resources hosted in the resource server to a given client. These access tokens are attached to all requests made by a client to a resource server.
JSON Web Tokens (JWTs) are the most commonly used format for this, and they are attached to API calls by the client when attempting to access resources on the resource server.
How it all ties together
Finally, we can now talk about how it all ties together. In the simplest of forms, a typical OAuth authorization flow consists of the following steps:
- User opens client (this can be a web, mobile or other application)
- Client directs the user to the authorization server, requesting a set of permissions it requires.
- Authrozation server authenticates the user and client, and grants authorization to the resource server via an access token
- Access token is returned to the client
- Client uses the access token to access resources on the resource server on behalf of the user.
In most cases, the resource server and authentication server will never need to directly communicate beyond sharing some initial information. A future blog post will discuss this in more detail.