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 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.
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.
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.
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.
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:
The sequence may vary depending on the developer and the software’s purpose, but the general scheme remains consistent.
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:
The Callback URL is a link to the page that the service will open in case of access denial or after successful authorization.
Upon registering the application, user credentials are created—these include the Client ID and Client Secret:
OAuth 2 provides four types of authorization grants depending on the situation:
Now, let's examine each type in more detail.
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.
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.When the user clicks the link, they are prompted to log in. Upon successful authentication, the application is either authorized or denied access.
If authorization is granted, the system redirects the browser to:
https://example.com/callback?code=AUTHORIZATION_CODE
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
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.
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.
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
Upon successful authentication, the server returns an access token directly to the browser:
https://example.com/callback#token=ACCESS_TOKEN
The application extracts the token from the URL and uses it for API requests.
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.
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.
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
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.