OAuth 2.0 Flows Explained

TL;DR

This guide explains common OAuth 2.0 flows – Authorisation Code, Implicit Grant, Resource Owner Password Credentials, and Client Credentials – what they are for, and when to use them.

1. Understanding OAuth 2.0 Basics

OAuth 2.0 lets users grant limited access to their resources (like photos or contacts) on one site (the Resource Server, e.g., Google Photos) to another site (the Client Application, e.g., a photo editing app) *without* sharing their passwords.

2. Authorisation Code Flow

This is the most secure and commonly used flow. It’s best for web applications and mobile apps where you can securely store a client secret.

1. The Client Application redirects the user to the Authorisation Server (e.g., Google’s login page).
2. The user logs in at the Authorisation Server and grants permission.
3. The Authorisation Server redirects back to the Client Application with an authorisation code.
4. The Client Application exchanges this code for an access token (and often a refresh token) by making a server-to-server request to the Authorisation Server, including its client ID and secret.
5. The Client Application uses the access token to access the user’s resources on the Resource Server.

Why it’s good: The refresh token allows continued access without repeatedly asking the user to log in. Client secret is never exposed to the browser.

# Example request to get an access token (simplified)

3. Implicit Grant Flow

This flow was popular for single-page applications (SPAs) running entirely in the browser, but it’s now generally discouraged due to security concerns. It directly returns an access token in the redirect URI.

1. The Client Application redirects the user to the Authorisation Server.
2. The user logs in and grants permission.
3. The Authorisation Server redirects back to the Client Application with the access token directly in the URL fragment (#token=…).

Why it’s less good: The access token is exposed in browser history and can be intercepted more easily. No refresh tokens are issued.

# Example redirect URI with an access token (simplified)

4. Resource Owner Password Credentials Flow

This flow involves the Client Application directly collecting the user’s username and password. Avoid this if possible! It’s only suitable for highly trusted applications you control completely, like a first-party mobile app.

1. The Client Application asks the user for their username and password.
2. The Client Application sends these credentials directly to the Authorisation Server.
3. The Authorisation Server validates the credentials and returns an access token (and often a refresh token).

Why it’s bad: You’re handling user passwords, increasing security risks significantly. The Client Application needs to be extremely secure.

5. Client Credentials Flow

This flow is used when the application itself (not a user) needs access to resources. For example, an automated backup service accessing data on behalf of its organisation.

1. The Client Application authenticates directly with the Authorisation Server using its client ID and secret.
2. The Authorisation Server validates the credentials and returns an access token.
3. The Client Application uses this access token to access resources on the Resource Server.

Why it’s good: No user interaction is required. Suitable for machine-to-machine communication.

# Example request to get an access token (simplified)

6. Summary Table

Flow	Use Case	Security	Refresh Token?
Authorisation Code	Web apps, mobile apps	High	Yes
Implicit Grant	SPAs (discouraged)	Low	No
Resource Owner Password Credentials	Trusted first-party apps only	Very Low	Yes
Client Credentials	Machine-to-machine access	Medium	Yes