An Introduction to OAuth 2.0. Working Principles and Risks

OAuth 2.0 has become a widespread authorization method for many applications and websites. Learn its basic working principles and hidden risks for your business.

What is OAuth 2.0

With rapid digitalization, the average number of applications used by an individual has increased dramatically. Unfortunately, it created several issues for the users and app owners. For example, people had to memorize multiple passwords (which often led to using one password for many services).

In addition, the growing cybercrime made it hard for application developers to keep up with security requirements for the authorization process.

OAuth became a solution for both problems. Enabling users to log in to an application via a more secure authentication server eliminated the necessity of building complex security and password issues.

Mass applications like Google or Facebook became the OAuth 2.0 authorization server.

How Does OAuth 2.0 Work?

In general, the process looks like that:

The application (the Client) sends the authorization request to the User’s account (resource owner). The User gives the authorization grant.

Here’s an example of how it is done in Canva:

As you can see, the user can pick an authorization server of their liking (Facebook or Google). In this case, the resource owner decides to use their Google account.

The Client (Canva) opens a pop-up window (authorization endpoint) with an authorization request. In this example, there is only one Google account available. But if the user has logged in to more than one account, the choice will be wider. If the user hasn’t logged in to any accounts, they will have to do it first.

Once they click on their account in a pop-up window, they give the authorization grant to Canva. The rest of the process remains unseen to the resource owner.

The Client sends the obtained grant to the authorization server and its authentication identity. The authorization server checks both and, if they are valid, provides the access token to the Client.

The application then sends the access token to the resource server. The latter checks it and then sends the protected resources to the Client.

In the case of Canva, the scope of access to the user’s protected resources is limited to the name, the profile picture, and language preferences.

Let’s take a look at one more authorization framework.

How OAuth 2 works: authorization code grant type

The authorization code grant type is the most widespread OAuth grant type. Usually, it takes place in a web browser and doesn’t expose a client secret.

Here’s an example. A company uses Google Workspace collab tools. The SecOps Department purchases ten licenses of a SaaS data protection platform, SpinOne. They use their corporate accounts to log in to the software.

Step 1. Authorization Code Link

The resource owner goes to the platform page (so.spin.ai), where the Client requests authorization.

In this case, the platform offers to sign up with an authorization server of the user’s choice (Google, Microsoft, Salesforce) or use regular credentials:

Step 2. User Authorizes Application

The user chooses the Google authorization server to access the application. Since the user hasn’t logged in to any account, the platform redirects them to the Google sign-in page where the user can enter their credentials (email/phone and password):

By completing the login, the user authorizes the application and permits the following steps of the flow.

Step 3. Application Receives Authorization Code

The authorization server (Google) sends the authorization code to the Client at this stage. The platform redirects the user back to its website.

Step 4. Application Requests Access Token

The Client sends the authorization code to the resource server (it is still Google) and requests an access token.

Step 5. The application Receives Access Token

The resource server checks the data sent by the Client is correct. If yes, it grants access to protected resources. That’s when the user is redirected to the application and can start using it.

Note that this section describes the authorization code grant type. There are other types of authorization, such as device code or refresh token. Let’s take a closer look:

Device code grant type

This grant type is used for devices that do not have a user interface to complete the authorization or have an interface uncomfortable for data input.

Here are several examples. Most TV remote controllers enable you to enter your data. However, the process is cumbersome (you’ll have to click one button several times to enter one symbol).

Meanwhile, devices like robotic vacuum cleaners, some air conditioners, or ovens do not have an input interface. They are controlled via applications on your smartphones.

This section will review the authorization flow for devices with limited input interfaces. This process is similar to the code grant type, but there are several differences:

1. The parties to the process are the user, the device, and the authorization server (or endpoint).
2. The device code and user code are used along with an access token.
3. There is no resource server in this process.

Step 1. Once opened, the application on your device will send the post request and client ID to the authorization endpoint.

Step 2. The authorization server will send back several items:

• device code
• user code
• polling data (interval and expiration)
• verification URL.

Step 3. The device starts polling the authorization server. It can’t connect yet as it needs the user to do several more steps.

Step 4. The user opens the verification URL on their PC or mobile phone to log in. They also need to enter the device code which they received previously from the authorization server. Last but not least, the user allows the scope of permissions.

Step 5. The PC or mobile then sends the confirmation to the authorization server, which marks the device as authorized.

Step 6. The device polls the authorization server again, and this time, it gets the access token.

Refresh Tokens Flow

For the purposes of security, an access token can expire after some time. To avoid asking the user to log in again, the Client initiates the refresh tokens flow. In a nutshell, the client exchanges the refresh token for an access token.

Here is the step-by-step process.

Step 1. The Client sends the refresh token to the authorization server.

Step 2. The server returns the access token to the application.

Step 3. The Client sends the access token to the resource server and gets access to protected resources.

Refresh tokens can also be used in the device grant type.

Benefits of OAuth 2.0

We’ll review the benefits of OAuth 2.0 from the users’ perspective.

1. Authorization security

Service APIs your employees use to access third-party applications usually have better security than those third-party apps.

2. Password Security

Employees need multiple applications to perform their daily working tasks. The ability to log in with one account reduces the necessity of having multiple passwords.

Consecutively, that fixes the problems of password security in the following ways.

First, there is the problem of stealing users’ passwords if they aren’t stored securely. For example, writing down the credentials on paper and attaching it next to a computer is potentially hazardous. An office visitor can spot this paper and take advantage of it.

Second, the business can better impose healthy password and authentication practices on users in IT environments it controls.

For example, in Google Workspace, you can create a mandatory password reset each month. You can also set a multifactor authentication protocol to decrease the chances of unauthorized access.

3. Performance

With OAuth 2.0, employees do not have to memorize multiple credentials on many platforms. Removing one stressful step in their daily workflow has an accumulative positive effect on their job.

4. Improve your tech stack

OAuth 2.0 is used inter alia to connect performance-boosting applications to your main IT environment.

For example, platforms like SpinOne can add valuable data protection features to Microsoft Office 365, Google Workspace, or Salesforce.

Risks of OAuth 2.0

Unfortunately, OAuth 2.0 is a double-edged sword. While it grants multiple benefits for users and businesses, it also has multiple risks to your data.

1. Shadow IT

This is one of the biggest risks for any organization. We mentioned earlier the ease of OAuth authorization flow and the benefits it grants to users.

Unfortunately, employees use this process to sign in to applications or websites indiscriminately. Lacking the necessary knowledge of IT security, they grant access to their corporate environments (and the data stored within).

In the worst-case scenario, workers use their corporate accounts to access apps for personal use (often by mistake), like wellness or dating. In the majority of cases, this process goes under the radar of IT or Security departments. As a result, the company has little to no control over its own IT environment. Can you really control what you do not know?

One of the eye-opening moments in many demo meetings that our sales department conducts is when our platform SpinOne reveals the number of applications that actually have access to the corporate GW and MSO 365.

It’s a moment of bitter truth when admins realize how little control they have over the apps.

2. Permissions risks

Permissions is something few users think about when they use OAuth authorization flow. Meanwhile, some applications can request more than mere access to a name, profile picture, email address, and language preferences.

This very information is already enough to tailor a simple social engineering scam. However, security is even more compromised when users grant permission for the applications to access resources such as files, emails, calendar entries, etc. and edit them.

For example, one of the key reasons for data loss in Salesforce is the application with mass data upload. The mistakes in their operation can result in significant data corruption. That’s why using Salesforce backup is critical.

Another example is a zero-day attack when cybercriminals use previously unknown vulnerabilities. Here’s an example of the discovered vulnerabilities in MSO 365.

3. Ransomware attacks

In many cases, ransomware appears to potential victims under a disguise of a safe application with an OAuth 2.0 authorization framework. They usually have an extended scope of permission that enable them to corrupt the files.

Unfortunately, once the Client (ransomware app) acquires an access token, it initiates its malicious code encrypting the User’s account data.

4. Non-compliance

The OAuth access of some applications to your environment can breach laws and regulations your business is subject to. And unfortunately, without tools like SpinOne you have little to no control over this situation.

Want to study these risks in detail? Read our SaaS Application Security Risk Assessment Guide.

Take better control of OAuth risks with Microsoft Risk Management and Google Workspace Risk Management.

The essential terminology to understand OAuth 2.0

Any text on OAuth 2.0 ends up very technical, and unprepared readers might find themselves lost in multiple terms that authors use to describe this process.

This section will help you understand any OAuth 2.0 text better.

Authorization Code Flow is the process of authorization using OAuth. It is the exchange of data between several parties like users, applications, and servers.

The resource is the asset of a User to which a third-party requests access. The simplest example of it is user data. However, it can also be the permission to carry out certain activities on behalf of a user.

OAuth2.0 Roles

These are the parties of the authorization code flow:

• The user is the entity using the OAuth 2.o to access a third-party app. Their role is called resource owner.
• The third-party app in this process is known as the Client.
• The resource server is the software that stores the User’s resources.
• The authorization server is the app that provides authorization grant.

Sometimes resource server and authorization server represent the same entity, but not always.

Endpoints

Endpoints are HTTP resources that the third-party application uses for implementing the authorization. There are three endpoints:

• The authorization endpoint is for the authorization grant from a user.
• The token endpoint is to exchange the grant for the access token.
• The redirection endpoint is to obtain the credentials.

The authorization request is the first step in the authorization flow. Clients sents request to the Resource Owner or Authorization server.

The Authorization Grant is permission to proceed with the authorization.

The Authorization Code Grant is the confirmation of the authorization by the User that the authorization server returns to the client.

Authorization Grant Type

It is the method by which the Client receives the access token. There are many types; the most popular are:

• Authorization code grant
• Proof Key of Code Exchange
• Device Code grant
• Refresh token

The tokens

The access token is the permission for access sent by the authorization server. Usually, it is exchanged for the authorization code. When the Client receives it, the authorization process is completed.

The refresh token is used to carry out the authorization without a user’s participation when the access token has expired. The server exchanges a refresh token for an access token.

The codes

Similar to tokens, codes are pieces of information that the Client and application exchange between themselves to enable the app to access resources.

The authorization code is the data piece the authorization server grants the Client. It can be exchanged for the access token in the resource server.

A device code is a unique code of a device with a limited input interface granted by the authorization server.

The user code is a several-digit code that the user needs to input in the verification URL.

OAuth 2.0 Scopes define the set of actions that the Client can do on behalf of the user. You would see it as a list of permissions (like access photos and files).

Client ID is a unique code that the application possesses.

The client secret is a piece of the application data that is used in the authorization process that should never be revealed.