Introduction to OAuth 2

The OAuth 2 is an authorization protocol designed to restrict access to personal accounts created on HTTP resources. Typical implementations include DigitalOcean, GitHub, and Facebook. OAuth 2 works by delegating the authentication process to the server where the account is located. This approach allows third-party applications to request access to user data, such as for registration using pre-filled credentials.

OAuth 2 can be used in cloud services, desktop computers, and mobile applications for smartphones and tablets. In this guide, we will explore how OAuth works and discuss the main practical applications of this tool.

OAuth Roles

Copy link

OAuth 2 defines four main roles: the resource owner, the client, the resource server, and the authorization server. Let’s go through each role in detail.

Resource Owner

Copy link

The resource owner is the user who is authenticated using their credentials to access their personal account. The accessible area may have restricted permissions—either read-only or with write and modification capabilities.

Server (Resource Server and Authorization Server)

Copy link

• The resource server stores user account data in a protected form.
• The authorization server verifies the authenticity of entered login credentials and generates authorization tokens for applications. These tokens allow applications to access user data.

Both servers are logically combined into a unified system, which is perceived by external services through the API interface. Thus, we will refer to the resource and authorization servers collectively as the Service or API.

Client (Application)

Copy link

The client refers to the application requesting access to the user’s account. Before activation, two conditions must be met: authentication within the application and a positive response from the API.

Protocol Overview

Copy link

Having reviewed the OAuth 2 roles, let's look at the authorization protocol and the information exchange process. Below is a sequence of typical operations:

1. The application prompts the user to enter authentication credentials.
2. If the login and password are correct, an authorization grant is issued.
3. The application sends a request to the API, including the authorization grant.
4. If the application is authenticated, the server generates an access token for the specific instance, completing the authorization process.
5. The application requests resources using the API.
6. The resource server validates the token and provides data only upon confirmation.

The sequence may vary depending on the developer and the software’s purpose, but the general scheme remains consistent.

Registering an Application

Copy link

Before using OAuth, an application must be registered with the service. This is typically done under the Developer or API section on the website. The following details are required:

• Application name
• Website where the application is hosted
• Callback URL (Redirect URL)

The Callback URL is a link to the page that the service will open in case of access denial or after successful authorization.

Client Identification

Copy link

Upon registering the application, user credentials are created—these include the Client ID and Client Secret:

• Client ID is a public string used by the API to verify the application's legitimacy and generate URLs for authorized users.
• Client Secret is used for authentication within the API and is only visible to the API and the application.

Authorization Grants

Copy link

OAuth 2 provides four types of authorization grants depending on the situation:

1. Authorization Code – Used for server-side applications.
2. Implicit Grant – Suitable for mobile applications, including web versions.
3. Resource Owner Password Credentials – Used for trusted applications, such as those integrated with an online service.
4. Client Credentials – Used for API-based operations.

Now, let's examine each type in more detail.

Authorization Code Grant

Copy link

This is the most common authorization method, as it is secure and suitable for applications where the source code and client secret are stored on a protected server.

Step 1: Create an Authorization Link

The application presents the user with the following link:

https://cloud.example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Components:

• authorize endpoint: Used for OAuth authentication via API.
• client_id: Identifies the requesting application.
• redirect_uri: Redirects the user after authorization.
• response_type=code: Requests an authorization code.
• scope=read: Specifies read-only access.

Step 2: User Authentication

When the user clicks the link, they are prompted to log in. Upon successful authentication, the application is either authorized or denied access.

Step 3: Authorization Code is Sent to the Application

If authorization is granted, the system redirects the browser to:

https://example.com/callback?code=AUTHORIZATION_CODE

Step 4: Request an Access Token

The application sends the authorization code to the server along with authentication details:

https://cloud.example.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

Step 5: Server Returns an Access Token

If authentication is successful, the API returns an access token:

{
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{
    "name":"User",
    "email":"info@example.com"
  }
}

The application is now connected to the server.

Implicit Grant

Copy link

This method is used in mobile applications and web browsers. Unlike the Authorization Code Grant, it does not ensure the confidentiality of the client secret.

Step 1: Generate an Authorization Link

The authorization service provides a link:

https://cloud.example.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Step 2: Authenticate the User

Upon successful authentication, the server returns an access token directly to the browser:

https://example.com/callback#token=ACCESS_TOKEN

Step 3: Extract and Use the Token

The application extracts the token from the URL and uses it for API requests.

Resource Owner Password Credentials Grant

Copy link

This method involves the user entering credentials directly into the service. It is used when other methods are not viable, such as system-integrated applications.

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

Upon successful authentication, the server returns an access token.

Client Credentials Grant

Copy link

This method allows access to the service’s own resources:

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

If authentication is successful, an access token is returned.

Refreshing an Access Token

Copy link

To refresh an access token before it expires:

https://cloud.example.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

Conclusion

Copy link

We have explored the different ways to use OAuth in applications, depending on their requirements. Now, users understand how access to remote services is managed and what factors to consider when choosing an authorization method.