Postman OAuth2 Flow: Authenticate and Test Protected APIs (2026)

Postman’s OAuth2 flow is less about the protocol itself and more about how Postman abstracts the protocol to make testing protected APIs feel like any other API call.

Let’s walk through setting up an OAuth2 request for a hypothetical API that requires an Authorization: Bearer <access_token> header. We’ll use the Authorization Code Grant type, which is common for web applications and server-side flows.

First, in your Postman request, go to the "Authorization" tab. Select "OAuth 2.0" from the "Type" dropdown.

Now, this is where Postman shines. It presents a form that maps directly to the OAuth2 spec, but you don’t need to be a spec expert to fill it out.

Key Fields and What They Mean:

• Grant Type: We’re choosing "Authorization Code" here. This means your application (Postman, in this case) will redirect the user to an authorization server, get an authorization code, and then exchange that code for an access token.
• Callback URL: This is crucial. It’s the URL on your application’s side that the authorization server will redirect back to after the user grants permission. For Postman, this is usually a generic https://www.getpostman.com/oauth2/callback. You don’t host this; Postman does.
• Auth URL: The URL of the authorization server where the user will be prompted to log in and authorize your application. For example, https://your-auth-server.com/oauth/authorize.
• Access Token URL: The URL of the authorization server that Postman will use to exchange the authorization code for an access token. For example, https://your-auth-server.com/oauth/token.
• Client ID: A unique identifier for your application, issued by the authorization server. You get this when you register your application with the OAuth provider. Let’s say it’s my-cool-app-id.
• Client Secret: A secret key for your application, also issued by the authorization server. This is used to authenticate your application when it exchanges the authorization code for an access token. For example, my-super-secret-key.
• Scope: This defines the level of access your application is requesting. For example, read_user profile_data.
• State (Optional): A value used to maintain state between the request and callback to prevent cross-site request forgery (CSRF) attacks. Postman can generate this for you.
• Client Authentication: How your client ID and secret are sent to the token endpoint. "Send as Basic Auth header" is common, or "Send client credentials in body."

Once you’ve filled these in, you’ll click "Get New Access Token." This triggers the flow. Postman will open a browser window (or a tab within Postman) showing your authorization server’s login page. You’ll log in, and then see a prompt asking if you authorize my-cool-app-id to access the requested scopes.

If you approve, the authorization server redirects back to the Postman callback URL with an authorization code. Postman intercepts this, uses the code and your client credentials to call the Access Token URL, and receives the access token.

You’ll then see a modal showing the available tokens. You can select the token you want to use and click "Use Token."

Postman automatically adds the Authorization: Bearer <access_token> header to your request.

The most surprising thing about Postman’s OAuth2 implementation is that it doesn’t require you to manually manage the redirect or parse the URL for the authorization code; it handles that entire dance behind the scenes, presenting you with a clean interface.

Let’s imagine you’re testing an API that lists user profiles, and you’ve configured your OAuth2 flow. You’ve successfully obtained an access token.

// Example Response from a GET /users request
{
  "users": [
    {
      "id": "user-123",
      "username": "alice",
      "email": "alice@example.com"
    },
    {
      "id": "user-456",
      "username": "bob",
      "email": "bob@example.com"
    }
  ]
}

Postman, having received that access token, has automatically appended it to your request headers:

GET /users HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
User-Agent: PostmanRuntime/7.28.0
Accept: */*
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

This means you can now interact with protected endpoints just as easily as public ones. The Client ID, Client Secret, Auth URL, and Access Token URL are static configuration for your application’s registration with the OAuth provider. The access_token itself is dynamic, obtained through the "Get New Access Token" flow.

The one thing most people don’t realize is how Postman handles token expiration and refresh. When your access token expires, Postman doesn’t automatically throw an error and stop. Instead, if you configured a Refresh Token and provided the Refresh Token URL in the OAuth 2.0 settings, Postman will attempt to silently refresh the access token in the background when it detects an expired token error (usually a 401 Unauthorized). This allows your subsequent requests to proceed without manual intervention, a feature that often goes unnoticed but is incredibly valuable for continuous testing.

The next step is understanding how to manage multiple access tokens or how to use refresh tokens programmatically within Postman scripts.