Access Delegation with OAuth2
There may be times that you need to give an application, access to another one of your application’s resources. For example, you might need to edit your photos through a photo editing app and you need to give the app, access to your photos stored in a cloud (ex: iCloud Photos, Google Photos), to edit them. This process is called Access Delegation.
Now, let’s take a formal look at Access Delegation. Authorizing a third-party client to access some resources on behalf of you (maybe with limited access) is known as Access Delegation and OAuth is an industry-standard protocol that can be used to implement Access Delegation. But before jumping into OAuth2, let’s talk about how Access Delegation was done before OAuth.
About a decade ago, when a user wanted to give access to his/ her resources (ex: photos) on a server (resource server — ex: iCloud Photos) to another third-party application (ex: photo editing app), it was done by giving the username and the password of the user directly to the above application. Therefore, the application will have unlimited access to the user’s resources and the account becomes more vulnerable to threats even though the third-party application is a trusted one. For example, if the application stores the password of the user insecurely (ex: without hashing) and if the application server gets attacked (hacked), all the account details of the user will be leaked to the attacker very easily.
There will be a point where the user wants to remove (or revoke) access to the application, and this can be only achieved by changing the user’s password and this might result in revoking access to other third-party applications that need access to the user’s resources.
Thus, early access delegation had many disadvantages, and to overcome them, the OAuth standard protocol was introduced. Currently, OAuth 2.0 is the widely used version of OAuth.
OAuth stands for Open Authorization and it is a lightweight protocol used for secure access delegation as mentioned before. This is a token-based access delegation method where the third-party application does not need the user’s username and password to access the user’s resources. The user will give consent to create a token with limited access and the application will use it to access the user’s resources on behalf of the user.
Next, let’s look at how this token-based interaction is implemented through the OAuth2 standard. Before that, we need to understand the four major roles in OAuth2.
- Resource Owner — This is the user who owns the resources (ex: photos) in the resource server (ex: iCloud Photos) and he/ she has the capability to delegate access to these resources to a third-party application (ex: photo editing app).
- Resource Server — This is the server (ex: the server where iCloud Photos are stored) that stores the resources (ex: photos) of the user in a protective way and it can accept incoming tokens and make necessary responses to the resource requests.
- Client— This is the third-party application (ex: photo editing application) that needs to access the user’s resources on behalf of the user (resource owner).
- Authorization Server — This is the server that issues the token when the resource owner gives his/ her consent.
There are 5 main ways that the token-based authorization can be implemented and they are called “Grant Types”. (There can be other customer grant types such as SAML Grant and JWT Grant)
- Authorization Code Grant
This is the most used Grant Type when implementing OAuth2 token-based authorization.
The above diagram illustrates the basic steps involved in the Authorization Code grant type. First, the resource owner (user) logs into the client application, and then, it redirects the user to the relevant authorization server with an authorization request and needed scopes. Here, the scopes specify what kind of access (ex: read-only or read and modify or delete) the client needs, regarding the user’s resources. Therefore, using these scopes, the access of the client can be limited and thus, giving only the necessary permissions to perform the action that the client is supposed to do.
After the redirection, the user is authenticated into the authorization server and the user is asked for consent for the passed scopes. After the consent is given, the user is redirected to the client application with an Authorization Code. This authorization code is something that the client can exchange for an access token and it is passed to the client through a front channel. Front channel (ex: your browser) is a connection between two end points in a less secure way compared to a Back channel (ex: from your backend server to another backend server) which is a highly secure connection.
So, after that, the client sends the Authorization Code to the authorization server and obtains an Access Token that can be used to access (with limited scopes) the resources of the user.
2. Implicit Grant
This is a simplified version of the Authorization Code Grant where there is no involvement of an Authorization Code and the client is given the Access Token directly when an authorization request is made. Therefore, this method is less secure compared to the above grant type since the access token is passed in the front channel and thus, more vulnerable to attackers.
3. Resource Owner Password Credentials Grant
Here, the resource owner will give his/ her own credentials to the client, and the client will exchange them with the authorization server for an access token. This grant type is only used with highly trusted clients and not usually a recommended one because this doesn't eliminate the problem we had with access delegation before.
4. Client Credentials Grant
Client Credentials Grant is basically used by a client to access its own resources on its own behalf. Here, the client sends its client id and client credentials in exchange for an access token for its own resources.
5. Device Code Grant
This grant type is used with client devices that don’t have browser facilities or their input is constrained (ex: Smart TV). For example, let’s say you want to access your iCloud Photos inside a Smart TV. So, first, the Smart TV (client device) sends an Authorization Request to the authorization server and as a response, it will receive three items namely Device Code, User Code, and Verification URI.
The smart TV will display the User Code and Verification URI to the end-user (resource owner) and at the same time, it will start to poll the authorization server with an access token request (including the Device Code) until it receives a response from the authorization server.
When the user notices the User Code and Verification URI, he/ she will access the verification URI with another device (that has a browser and input is not constrained) and he/ she will be prompted for the User Code. Here, the user will enter the displayed User Code and it will be verified by the authorization server. If the verification is a success, the client device (Smart TV) will receive an access token, which can be used to communicate with the resource server (iCloud Photos storage server).
Refresh Tokens
Until now, we discussed only one specific type of token called Access Tokens that can be used by a client to access the user’s resources on a resource server. But there is another type called Refresh Tokens. They can be used to get access tokens when the previous access token expires. This is optional and the authorization server can decide whether to issue refresh tokens or not.
Let’s consider a scenario where the authorization server issues refresh tokens with Implicit Grant.
So, in the above diagram, the only difference is that the client will receive a refresh token along with the access token when the user gives his/ her consent. Let’s say that the received access token expires some time later. Now, the client cannot access the resources and if there are no refresh tokens, the user has to give consent again explicitly to obtain a new access token. But in this scenario, as the client has a refresh token, it can send an access token request to the authorization server with the refresh token. Here, without the user’s explicit consent, a new access token is sent to the client as mentioned below.
Therefore, the client will receive a new access token with an optional refresh token according to policies at the authorization server.
In conclusion, the method of access delegation with OAuth2 has made it secure and easy for a user to transfer access to his/ her resources to another third-party application with limited access. Here, the user will have more control over this access than previous methods (ex: directly giving credentials), and, as only the minimum needed access is given to the application, the user doesn’t need to worry about unnecessary and invalid accesses from the application (For example, if only view and edit accesses are given, the application cannot delete any resources).
