Understanding OAuth 2.0: A Comprehensive Guide to Secure Authorization and Application Integration

I. What is OAuth 2.0

1. What is OAuth 2.0

OAuth 2.0 is an industry-standard protocol for authorization.

OAuth 2.0 allows users to grant third-party applications access to their data on another service provider without sharing their credentials (such as username and password).

2. OAuth 2.0 Application Scenarios

The application scenarios of OAuth 2.0 are extensive, including but not limited to:

• Third-party applications accessing user information on other services, for example, an app accessing a user’s data on github.com via OAuth 2.0.
• Third-party applications performing actions on behalf of the user, for example, an email client application sending emails on behalf of the user via OAuth 2.0.
• Third-party applications implementing single sign-on for users using OAuth 2.0, such as logging into other applications with a Github account.

3. The Importance of OAuth 2.0

The importance of OAuth 2.0 is mainly reflected in its simple and easy-to-implement solution for solving the security issues of user data access and sharing.

• In the modern network environment, users’ data is often dispersed across different network services, and how to securely and effectively access and share this data is an important problem. OAuth 2.0 provides a standard solution, allowing users to control which applications can access what data, without providing usernames and passwords to third-party applications.

II. Basic Concepts of OAuth 2.0

In the operation process of OAuth 2.0, certain terms and concepts are involved, getting familiar with these terms and concepts can help better understand the OAuth 2.0 mechanism.

• Client: The third-party application requesting access to resources; the Client can be a web site, app, device, etc.
• Service Provider: The network service providing and storing the resources, such as Google, Github, etc.
• Resource Owner: The Resource Owner usually refers to the user, who owns the resources on the service provider.
• Authorization Server: The server used by the service provider for processing and issuing access tokens. When a user requests to access resources, they first need to request an access token from the authorization server.
• Resource Server: The server used by the service provider for storing and managing resources; once the user has the access token, they can request access to resources from the Resource Server.
• Access Token: A credential issued by the authorization server to the client, indicating that the client has the right to access the resource owner’s resources. The access token has a certain validity period, and upon expiration, a refresh token is needed to obtain a new access token.
• Refresh Token: A credential issued by the authorization server along with the access token, used to obtain a new access token after the current one expires. A refresh token typically has a longer validity period and can even be set to never expire.
• User Agent:
  Usually refers to the browser.

III. Basic Process of OAuth 2.0

The operation process of OAuth 2.0 is defined in RFC 6749

• (A) The Client requests resource authorization from the Resource Owner. The authorization request can be made directly to the Resource Owner, though it’s preferable to initiate indirectly via the Authorization Server.
• (B) The Client obtains authorization from the Resource Owner, which is typically a credential; the form of authorization and credentials may vary. RFC 6749 defines four main authorization types (further introduced below)
• (C) The Client presents the authorization credentials (from the Resource Owner) to the Authorization Server for authentication and requests an Access Token for accessing resources.
• (D) The Authorization Server authenticates the Client and verifies the granted authorization. If verification is successful, it issues an Access Token.
• (E) The Client initiates Access Token validation with the Resource Server to request access to protected resources.
• (F) The Resource Server verifies the Access Token; if authentication is successful, it returns the requested resource.

IV. Four Authorization Models

The client must obtain user authorization (the previous Step B) to get an Access Token.

OAuth 2.0 defines four authorization methods.

• Authorization Code Grant
• Implicit Grant
• Password Grant (Resource Owner Password Credentials)
• Client Credentials Grant

1. Authorization Code Grant

The authorization code grant is the most commonly used authorization process. It is also the most complete and secure authorization mode.

The diagram below expands the authorization process in the Authorization Code Grant of OAuth 2.0 (Step B in the text above)

• (A) The Client first redirects the page to the Authorization Server’s authorization page; this redirection must carry the RedirectURI indicating where to reopen the page post-authorization.
• (B) The Resource Owner authorizes on the authorization page.
• (C) After authorization, the Authorization Server redirects the page back to the Client’s page (RedirectURI specified in Step A). An authorization code is included in the URI. The authorization code will be transmitted to the Client’s backend through the User Agent.
• (D) The Client (backend) uses the authorization code to request an Access Token from the Authorization Server and must specify the access Scope sought.
• (E) Once the Authorization Server validates the authorization code, it returns the Access Token and Refresh Token.

2. Implicit Grant

The implicit grant is primarily for pure frontend applications like JavaScript SPA (Single Page Applications).

In the Implicit Grant, instead of issuing an authorization code to the client, an Access Token is directly issued as the result of granting resource owner authorization, omitting the issuance of intermediate credentials (such as an authorization code).

• (A) The User Agent (usually a browser) sends an authorization request to the Authorization Server. This is typically done by redirecting the user to the Authorization Server’s authorization endpoint, which includes the Client ID, requested permissions scope, RedirectURI, and state.
• (B) The authorization server authenticates the user, often by asking for the username and password. It then displays an authorization page for the user to decide whether to grant the requested permissions to the client.
• (C) If the user agrees to the permissions, the authorization server redirects the User Agent back to the Client’s RedirectURI, including the Access Token and state in the fragment portion of the URI. Note that since this is completed within the User Agent, the Access Token does not pass through the server-side application code.

3. Password Grant (Resource Owner Password Credentials)

The password grant is a simpler process where the user directly provides their username and password to the Client, who then uses this information to request an Access Token from the authorization server. The Client must not store the password.

This grant is mainly used for applications with a high level of trust, such as different products within the same company.

• (A) The user enters their username and password in the Client application.
• (B) The Client application uses the username, password, Client ID, and Client secret to send a request to the authorization server’s token endpoint to obtain an Access Token.
• (C) The authorization server validates the username, password, Client ID, and Client secret. If successful, it returns the Access Token to the Client application.

4. Client Credentials Grant

The Client Credentials Grant is mainly used for backend services without user involvement (such as in open API scenarios).

• (A) The Client application uses its Client ID and secret to send a request to the authorization server’s token endpoint to obtain an Access Token.
• (B) The authorization server validates the Client ID and secret. If successful, it returns the Access Token to the Client application.

V. Security Considerations for OAuth 2.0

1. Security of the Redirect URI: The Redirect URI is the address where the Client receives authorization codes and access tokens. To prevent attackers from intercepting this sensitive information, the Redirect URI should use the HTTPS protocol. Additionally, the authorization server should only accept pre-registered Redirect URIs to prevent attackers from redirecting users to malicious sites.
2. Protection of Access Tokens: Access Tokens are sensitive credentials, and if acquired by attackers, they can access users’ resources. Therefore, Access Tokens should be encrypted with the HTTPS protocol during all transmissions to prevent eavesdropping. While storing Access Tokens, appropriate encryption measures should also be used.
3. Use and Protection of Refresh Tokens: Refresh Tokens typically have long validity periods and can be set to never expire. Therefore, if a Refresh Token is acquired by an attacker, they can continuously access users’ resources. To prevent this, Refresh Tokens should only be used in backend services and should not be exposed to frontend applications. Additionally, Refresh Tokens should be encrypted during all transmissions and storage.
4. CSRF Attacks and Prevention: CSRF (Cross-Site Request Forgery) is a common web attack where attackers execute unauthorized actions by forging user requests. To prevent CSRF attacks, OAuth 2.0 authorization requests can include a state parameter, a randomly generated string used to validate the legality of requests when the authorization server redirects back to the Client. The Client generates the state parameter when sending the authorization request and validates it upon receiving the authorization response, rejecting the response if unmatched.

VI. OAuth 2.0 in Practice

1. Using OAuth 2.0 for Third-Party Login

Third-party login is a common application scenario for OAuth 2.0. Users can log into third-party applications using their accounts on service providers like Google or Facebook, eliminating the need to register a new account. This not only enhances user experience but also reduces the risk of users forgetting passwords.

2. Using OAuth 2.0 for API Authorization

OAuth 2.0 is also often used for API authorization. For instance, an application may request access to a user’s files on Google Drive or request posting a tweet on a user’s Twitter account. In these cases, users can use OAuth 2.0 to authorize applications to access their resources without providing the username and password to the application.

3. Common Issues and Solutions

While implementing OAuth 2.0, some issues may arise, such as Redirect URI matching problems, Access Token expiration issues, and Refresh Token usage issues. These issues can typically be resolved by properly configuring the authorization server and client and following OAuth 2.0 best practices. For example, using absolute matching instead of fuzzy matching to verify the Redirect URI, using Refresh Tokens to obtain new Access Tokens instead of requiring users to log in again, etc.

oauthserverclientpracticeprinciple