OAuth 2.0 Authorization Code and Implicit Grant Flows

OAuth 2.0 is the industry‑standard protocol for delegated authorization, commonly used for third‑party logins and granting applications access to user data stored on other services.

The specification defines four grant types: Authorization code , Implicit , Resource Owner Password Credentials , and Client Credentials . This article concentrates on the first two.

Basic Concepts

Roles

OAuth defines four roles:

resource owner : the entity that owns the protected resources.

resource server : the server that hosts and protects the resources.

client : the application acting on behalf of the resource owner.

authorization server : authenticates the resource owner and issues an access token .

In a typical scenario such as using WeChat login on a third‑party forum, the forum is the client, the user’s WeChat account is the resource owner, WeChat’s servers act as both the resource and authorization servers.

Tokens

An Access Token grants the client permission to access protected resources for a short period, while a Refresh Token can be used to obtain new access tokens without requiring the user to re‑authenticate.

Client Registration

Before initiating an OAuth flow, the client must register with the authorization server, providing its type, redirect URI, and other metadata. The registration returns a client_id and client_secret , which are used in subsequent requests.

Authorization Code Grant

The Authorization Code flow is the most common and secure method.

1. The client redirects the user’s browser to the authorization endpoint:

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24

Parameters include client_id , redirect_uri , response_type=code , scope , and a CSRF‑preventing state .

2. The user authenticates and consents.

3. The authorization server redirects back to the client’s redirect_uri with an authorization code :

GET /callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24

4. The client exchanges the code for an access token:

POST /token
client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8

5. The authorization server responds with a JSON payload containing the access_token (and optionally a refresh_token ):

{
  "access_token": "z0y9x8w7v6u5",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "openid profile"
}

6. The client calls the resource server using the access token:

GET /userinfo HTTP/1.1
Host: oauth-resource-server.com
Authorization: Bearer z0y9x8w7v6u5

The resource server returns the protected user data.

Implicit Grant

The Implicit flow (also called the simplified or hidden mode) is shorter but less secure because the access token is returned directly in the URL fragment.

1. The client initiates the request:

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24

2. The user authenticates and consents.

3. The authorization server redirects to the client with the access token in the fragment:

GET /callback#access_token=z0y9x8w7v6u5&token_type=Bearer&expires_in=5000&scope=openid%20profile&state=ae13d489bd00e3c24

Using the fragment ( # ) prevents the token from being sent to the server in the HTTP request, which is a security consideration.

4. The client extracts the token from the fragment and calls the resource server as in the Authorization Code flow.

5. The resource server returns the requested data.

Conclusion

The article covered the two most common OAuth 2.0 grant types. The Authorization Code grant offers higher security and is widely used, while the Implicit grant provides a simpler, faster flow at the cost of reduced security.