What OAuth 2.0 Solves
OAuth 2.0 is an authorization framework that lets an application obtain limited access to a resource on behalf of a user without ever handling that user's password. Instead of sending credentials to every API, the client exchanges them once with an authorization server for an access token, and that token — not the original password — is what gets sent with subsequent API calls, which is exactly what Postman's OAuth 2.0 Authorization tab automates.
Cricket analogy: A broadcaster doesn't get the BCCI president's personal keys to the stadium to film a match; instead they're issued a limited media accreditation for that specific tournament, just as OAuth issues a scoped token instead of handing over the user's actual password.
Grant Types in Postman's OAuth 2.0 Tab
Postman's OAuth 2.0 auth type supports multiple grant types, most commonly Authorization Code (with PKCE), Client Credentials, and Password grant. Authorization Code is used when a human resource owner must log in and approve access through a browser popup that Postman opens; Client Credentials is used for machine-to-machine calls where the app itself is the identity, with no user involved, exchanging a Client ID and Client Secret directly for a token at the Access Token URL.
Cricket analogy: Selecting Authorization Code grant is like a fan logging into the official ICC app themselves to approve a ticket purchase, while Client Credentials is like the stadium's own turnstile system authenticating directly with the ticketing server with no fan involved.
{
"grant_type": "client_credentials",
"client_id": "{{client_id}}",
"client_secret": "{{client_secret}}",
"scope": "orders.read orders.write"
}Requesting and Managing Access Tokens
In the Configure New Token section of Postman's OAuth 2.0 tab, you fill in the Auth URL, Access Token URL, Client ID, Client Secret, and Scope, then click 'Get New Access Token'; Postman opens the authorization flow, retrieves the token, and stores it under the Available Tokens list, from which you can select it to be added to the current request's Authorization header. Tokens obtained this way can also be auto-refreshed if the server returns a refresh token and Postman's 'Automatically refresh this token' setting is enabled.
Cricket analogy: Clicking 'Get New Access Token' is like a broadcaster submitting an accreditation form to the ICC once and receiving a match pass valid for the tournament, which they then present at every gate instead of resubmitting paperwork each day.
PKCE and Common Pitfalls
For public clients such as mobile or single-page apps, Authorization Code with PKCE (Proof Key for Code Exchange) adds a code_verifier and code_challenge pair so an intercepted authorization code alone can't be exchanged for a token by an attacker; Postman generates these automatically when 'Use PKCE' is enabled. A very common mistake is forgetting to set the Callback URL to match exactly what's registered with the authorization server, which causes a 'redirect_uri_mismatch' error before Postman ever gets a code to exchange.
Cricket analogy: PKCE's code_verifier is like a coded watermark only the original broadcaster's rights-holder can validate, so even if someone intercepts the accreditation slip mid-transfer, they can't redeem it without the matching secret proof.
Postman's 'Authorize using browser' checkbox opens the authorization flow in your system's default browser instead of Postman's embedded webview, which is useful when the identity provider requires an already-logged-in session, SSO, or a passkey/biometric prompt.
Client Secrets used in the Client Credentials or Authorization Code grants should never be embedded in a mobile app or single-page app build; for public clients use Authorization Code with PKCE instead, which doesn't require a client secret at all.
- OAuth 2.0 exchanges credentials once for a scoped, revocable access token instead of sending a password with every API call.
- Postman's OAuth 2.0 Authorization tab supports Authorization Code, Client Credentials, Password, and Implicit grant types.
- Authorization Code grant involves a human resource owner approving access through a login popup; Client Credentials is machine-to-machine.
- Clicking 'Get New Access Token' retrieves a token and stores it in the Available Tokens list for reuse across requests.
- PKCE adds a code_verifier/code_challenge pair to protect public clients that can't safely hold a client secret.
- A mismatched Callback/Redirect URL is one of the most common causes of OAuth failures in Postman.
- Enable 'Automatically refresh this token' so long test sessions don't fail from an expired access token.
Practice what you learned
1. What is the primary security benefit OAuth 2.0 provides over sending a username and password directly?
2. Which OAuth 2.0 grant type is appropriate for pure machine-to-machine communication with no human user involved?
3. What problem does PKCE (Proof Key for Code Exchange) solve in the Authorization Code grant?
4. In Postman, what typically causes a 'redirect_uri_mismatch' error during OAuth 2.0 testing?
5. Where does Postman store an access token after you click 'Get New Access Token'?
Was this page helpful?
You May Also Like
Basic and Bearer Token Auth
Learn how HTTP Basic Authentication and Bearer Token Authentication work, and how to configure each correctly in Postman's Authorization tab.
API Keys and Custom Headers
Learn how to authenticate requests using API keys and how to work with custom HTTP headers in Postman, including placement options and common conventions.
Managing Secrets Safely
Learn how to store, share, and rotate API keys, tokens, and passwords in Postman using variable scopes, secret-typed variables, and Vault integration without leaking them into version control.