Authentication Patterns in Postman: API Keys, Bearer Tokens, and OAuth Basics

1) Identify authentication requirements from API docs

Before configuring anything in Postman, translate the API documentation into a concrete checklist. Authentication details are usually scattered across “Authentication”, “Security”, or per-endpoint sections.

What to extract from the docs

• Auth scheme: API key, Bearer token (JWT or opaque), OAuth 2.0, or multiple options.
• Where credentials go: header (e.g., X-API-Key), query parameter (e.g., ?api_key=), or Authorization header.
• Token format: exact header value pattern, typically Authorization: Bearer <token>.
• Token lifecycle: expiration time, refresh method, and whether refresh tokens exist.
• Scopes/roles: which permissions are needed for specific endpoints.
• Error behavior: expected status codes (401 unauthenticated, 403 unauthorized) and error body patterns.

Turn docs into Postman-ready parameters

Create a small mapping you can apply consistently:

• Credential variables: {{api_key}}, {{access_token}}, {{refresh_token}}, {{client_id}}, {{client_secret}}, {{token_url}}.
• Auth placement: “Header: X-API-Key” or “Query: api_key”.
• Protected endpoints: list a couple of requests you will use to verify allowed/denied behavior.

2) Implement API key authentication (header/query param) using variables

API key authentication is common for server-to-server or simple integrations. The key idea in Postman is to avoid hardcoding the key in each request: store it in a variable and reference it wherever needed.

API key in a header (recommended when supported)

Step-by-step:

• Open a protected request in your collection.
• Go to the request’s Headers tab.
• Add the header name specified by the docs (examples: X-API-Key, api-key, X-Auth-Token).
• Set the value to a variable, e.g., {{api_key}}.
• Send the request and confirm you get a successful response (often 200).

If the API uses the standard Authorization header with a key-like value (less common but possible), you might see a pattern like Authorization: ApiKey <key> or Authorization: Token <key>. In that case, set the header value to ApiKey {{api_key}} (or whatever prefix the docs require).

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

API key in a query parameter

Step-by-step:

• Open the request.
• Go to the Params tab.
• Add the parameter name from the docs (example: api_key).
• Set the value to {{api_key}}.
• Send the request and confirm success.

Be aware that query parameters can be logged in more places (server logs, proxies, browser history). If the API supports header-based keys, prefer headers.

Quick checks: denied vs allowed

Add simple tests to confirm authentication is actually enforced.

pm.test("Denied without API key (401/403)", function () {  // Use this in a copy of the request where the key is intentionally removed  pm.expect([401, 403]).to.include(pm.response.code);});

pm.test("Allowed with API key (not 401/403)", function () {  pm.expect([401, 403]).to.not.include(pm.response.code);});

3) Implement Bearer token flows (token storage and refresh assumptions)

Bearer tokens are typically short-lived access tokens. The client first calls a login/token endpoint, then attaches the token to subsequent requests using the Authorization header. In Postman, the repeatable pattern is: request token once, store it in a variable, and have all protected requests read from that variable.

Attach a Bearer token to requests

Step-by-step:

• Open a protected request.
• Go to the Authorization tab.
• Set Type to Bearer Token.
• In Token, use {{access_token}}.
• Send the request. If {{access_token}} is empty or invalid, you should see 401 (or sometimes 403).

Postman will generate the header Authorization: Bearer {{access_token}} for you. If you prefer manual control, you can also set the header directly, but using the Authorization tab is clearer and easier to centralize later.

Create a “Get Token” request and store the token

Most APIs provide a token endpoint that returns JSON containing an access token. Common response fields include access_token, token, and expires_in.

Step-by-step:

• Create a request named Auth - Get Access Token.
• Configure it according to the docs (often POST with JSON body or form-encoded body).
• Send it once to confirm the response includes a token.
• In the Tests tab of the token request, parse the response and store the token in a variable.

// Example: response JSON contains { "access_token": "...", "expires_in": 3600 }const json = pm.response.json();pm.test("Token response has access_token", function () {  pm.expect(json).to.have.property("access_token");  pm.expect(json.access_token).to.be.a("string").and.not.empty;});pm.collectionVariables.set("access_token", json.access_token);// Optional: store expiry timestamp if expires_in is providedif (json.expires_in) {  const expiresAt = Date.now() + (json.expires_in * 1000);  pm.collectionVariables.set("access_token_expires_at", String(expiresAt));}

Use collection variables for tokens when you want the token to be shared across the whole collection run. If you need different tokens per environment or per user context, store them in environment variables instead.

Refresh assumptions and practical handling

Token refresh varies widely. Some APIs provide a refresh token; others require re-authentication. In Postman, you typically implement one of these practical approaches:

• Manual refresh: run the “Get Token” request whenever you get a 401.
• Pre-request refresh check: if you stored {{access_token_expires_at}}, check it before sending protected requests and fetch a new token when expired.
• Refresh token flow: call a refresh endpoint using {{refresh_token}}, then overwrite {{access_token}}.

A lightweight pre-request check (without auto-calling another request) can at least fail fast with a clear message:

// Pre-request Script example for protected requestsconst token = pm.collectionVariables.get("access_token");const expiresAt = Number(pm.collectionVariables.get("access_token_expires_at"));if (!token) {  throw new Error("Missing access_token. Run Auth - Get Access Token.");}if (expiresAt && Date.now() >= expiresAt) {  throw new Error("access_token appears expired. Re-run Auth - Get Access Token (or refresh flow)." );}

If your API supports refresh tokens and provides a dedicated refresh endpoint, create a separate request (e.g., Auth - Refresh Token) that updates {{access_token}} similarly to the token request.

4) Overview of OAuth 2.0 in practical Postman terms (token retrieval, attaching tokens)

OAuth 2.0 is a framework for obtaining access tokens. In Postman, you usually care about two practical tasks: (1) obtaining a token from an authorization server, and (2) attaching that token to API requests.

Common OAuth 2.0 grant types you’ll encounter

• Authorization Code: user signs in via browser; you exchange a code for an access token. Common for user-facing apps.
• Client Credentials: machine-to-machine; no user login; you exchange client ID/secret for an access token.
• Resource Owner Password Credentials: legacy; username/password directly exchanged for token (often discouraged).

Regardless of grant type, the output is typically an access_token you use as a Bearer token.

Get a token using Postman’s built-in OAuth 2.0 helper

Step-by-step (high-level, fields depend on the grant type):

• Open a request (or a dedicated token request).
• Go to Authorization tab.
• Set Type to OAuth 2.0.
• Click Get New Access Token.
• Fill in values from the docs: Token Name, Grant Type, Access Token URL, Auth URL (if applicable), Client ID, Client Secret, Scope, and Audience/Resource if required.
• Request the token and then choose Use Token to attach it to the request.

For repeatable collection runs, you often still want to store the resulting token in a variable so other requests can use it consistently.

Store OAuth tokens in variables (so the collection can reuse them)

If you retrieve OAuth tokens via a token endpoint request (common for Client Credentials), store them exactly like any Bearer token:

// Tests tab of an OAuth token request (e.g., client credentials)const json = pm.response.json();pm.collectionVariables.set("access_token", json.access_token);if (json.refresh_token) {  pm.collectionVariables.set("refresh_token", json.refresh_token);}

Then, for protected requests, use Bearer Token authorization with {{access_token}}, or set collection-level auth to Bearer with that variable.

5) Centralizing auth configuration at collection level to reduce duplication

When many requests share the same authentication method, configure it once at the collection level and let requests inherit it. This reduces mistakes and makes updates (like rotating keys) much faster.

Set collection-level authorization

Step-by-step:

• Click your collection’s settings (edit the collection).
• Open the Authorization section.
• Choose the auth type used by most endpoints (API Key, Bearer Token, or OAuth 2.0).
• Reference variables instead of raw secrets (e.g., {{api_key}} or {{access_token}}).
• Save the collection.

Now, each request can use Inherit auth from parent. Only override auth at the request level when an endpoint is public or uses a different scheme.

Pattern: one auth setup, multiple verification requests

• Auth - Get Access Token (stores {{access_token}}).
• Protected - Get Profile (inherits Bearer token; should succeed when token is valid).
• Protected - Get Profile (No Auth) (explicitly set Authorization to “No Auth”; should fail with 401/403).

This structure makes it easy to validate that your auth is both required and correctly applied.

Exercises

Exercise 1: Configure a protected request and prove denied/allowed behavior

Goal: Confirm the API enforces authentication and your Postman setup is correct.

• Pick a protected endpoint from the docs (e.g., “Get current user”, “List orders”).
• Create two requests to the same endpoint: Protected - Allowed and Protected - Denied.
• For Protected - Allowed, inherit collection auth (API key or Bearer token).
• For Protected - Denied, set Authorization to No Auth (or remove the key header/param).
• Add tests:

// Tests for Protected - Deniedpm.test("Request is denied without auth", function () {  pm.expect([401, 403]).to.include(pm.response.code);});

// Tests for Protected - Allowedpm.test("Request is allowed with auth", function () {  pm.expect([401, 403]).to.not.include(pm.response.code);});

Exercise 2: Store a Bearer token from a login/token endpoint

Goal: Retrieve a token once and reuse it across requests.

• Create Auth - Get Access Token according to the docs.
• Send it and confirm the response includes access_token.
• Add this to the token request’s Tests:

const json = pm.response.json();pm.collectionVariables.set("access_token", json.access_token);pm.test("Stored access token", function () {  pm.expect(pm.collectionVariables.get("access_token")).to.be.a("string").and.not.empty;});

• Set collection Authorization to Bearer Token with token {{access_token}}.
• Send Protected - Allowed and verify it succeeds.

Exercise 3: Confirm access changes when token is missing or invalid

Goal: Validate your tests catch real auth failures.

• Temporarily clear the token variable by running this in the Postman console or in a request’s pre-request script:

pm.collectionVariables.unset("access_token");

• Send Protected - Allowed again (it should now fail with 401/403).
• Set an obviously invalid token value and retry:

pm.collectionVariables.set("access_token", "invalid-token");

• Confirm the response is denied and your tests detect it.
• Re-run Auth - Get Access Token to restore a valid token and confirm access is allowed again.