Postman OAuth 2.0 Flow

OAuth 2.0 lets an application act for a user without ever seeing the user's password. Think of a hotel key card. The front desk checks your identity once, then hands you a card that opens only your room and expires at checkout. OAuth 2.0 issues similar limited-access cards called access tokens.

The Four Roles

Role	Meaning	Hotel Comparison
Resource Owner	The user who owns the data	The guest
Client	The app that wants access	The guest's assistant
Authorization Server	Issues tokens after approval	The front desk
Resource Server	Holds the protected data	The hotel room

Common Grant Types

A grant type is the method an app uses to obtain a token. Postman supports the popular ones.

Authorization Code

The user signs in on the provider's page and approves access. The provider returns a short code, and the app trades the code for a token. This type suits web and mobile apps that act for a human user.

Authorization Code with PKCE

PKCE adds a one-time secret that blocks code theft. Mobile apps and single-page apps use it because they cannot hide a permanent client secret.

Client Credentials

The app authenticates as itself with an ID and a secret. No human takes part. Server-to-server integrations use this type.

Password and Implicit

Older documentation mentions these types. Modern guidance discourages both, so choose Authorization Code or Client Credentials for new work.

Authorization Code Diagram

  USER        POSTMAN (client)      AUTH SERVER       API SERVER
   │               │                      │                 │
   │  Get token    │                      │                 │
   ├──────────────►│  open login page     │                 │
   │               ├────────────────────► │                 │
   │◄──────────────┴─── sign in + approve ┤                 │
   │               │◄── authorization code┤                 │
   │               ├── code + secret ────►│                 │
   │               │◄── access token ─────┤                 │
   │               ├────── GET /data  (Bearer token) ──────►│
   │               │◄───────────── data ────────────────────┤

Configure OAuth 2.0 in Postman

1. Open the Authorization tab of a request or collection.
2. Select OAuth 2.0 as the type.
3. Choose the grant type, such as Authorization Code.
4. Enter the Auth URL, Access Token URL, Client ID, and Client Secret from the provider's developer console.
5. Set the Callback URL. Postman offers a built-in callback address for desktop testing.
6. Type the scopes, for example read:orders.
7. Click Get New Access Token and sign in when the provider's page opens.
8. Click Use Token to attach the token to the request.

Scopes Explained

A scope names one permission. A token with the scope read:orders can view orders but cannot delete them. Request only the scopes your test needs. Narrow scopes limit damage if a token leaks.

Token Lifetime and Refresh

Access tokens expire quickly. Many providers also return a refresh token that obtains a new access token without another sign-in. Postman stores both and offers a Refresh Token button. Enable Auto-refresh token to let Postman handle expiry silently.

Client Credentials Example

For a server-to-server API, send a POST request to the token URL with this form body:

grant_type    = client_credentials
client_id     = {{clientId}}
client_secret = {{clientSecret}}
scope         = read:orders

The response contains an access_token field. Save it with a post-response script and reuse it across the collection.

Troubleshooting

• redirect_uri mismatch: the callback URL in Postman must match the one registered with the provider.
• invalid_client: the client ID or secret contains a typo or extra space.
• invalid_scope: the provider does not recognize the requested scope name.
• 401 after success: the token expired, so refresh it.

Key Points

• OAuth 2.0 grants limited access without sharing passwords.
• Authorization Code suits apps that act for users, and Client Credentials suits machine-to-machine calls.
• Scopes restrict what a token may do.
• Postman retrieves, stores, and refreshes tokens from the Authorization tab.
• Variables keep client secrets out of shared fields.