OAuth 2.0 in an API client: get and use access tokens

To call an API protected by OAuth 2.0 from an API client, you configure the client with the provider's authorization and token URLs, your client ID (and secret, for confidential clients), the scopes you need and a callback URL. The client then runs the grant, receives an access token, and attaches it to your requests as Authorization: Bearer <token>. In Swastik Codes you do this in the Authorization tab: choose OAuth 2.0, fill in Configure new token, and press Get New Access Token.

This guide explains each grant type, what to register with your provider, how to share a token across a whole collection, and how to fix the errors you are most likely to meet.

Before you start

• Register a client with your provider (Auth0, Okta, Keycloak, Azure AD / Entra ID, Google, or your own server). You will get a client ID and, for confidential clients, a client secret.
• Register the callback URL. For the Swastik Codes web app it is:

https://swastik.codes/oauth/callback

The authorization code, PKCE and implicit grants redirect the popup there. Providers compare redirect URIs exactly, so copy it character for character.

• Have a free account. Token requests and API calls are sent through the swastik.codes server, which needs you signed in. The server also refuses private and loopback addresses, so the provider's token endpoint must be publicly reachable. An identity server on localhost will not work from the web app; use the desktop app for that.

Step 1: choose where the auth lives

Authorization can be set on a request, a folder or a collection. Requests default to Inherit, which uses the nearest folder or collection auth; the Authorization tab tells you which one is in effect ("This request uses OAuth 2.0 from …").

For an API where every endpoint needs the same token, configure OAuth 2.0 once on the collection (open the collection and select its Authorization tab) and leave the requests on Inherit. Override it on a folder or request only where an endpoint needs something different, such as No Auth for a public health check.

Step 2: configure the grant

Open the Authorization tab, choose OAuth 2.0 and fill in the Configure new token section. The fields depend on the Grant type.

Authorization Code (With PKCE) – for most user-facing APIs

This is the grant to use when a user signs in at the provider and approves access. PKCE protects the code exchange and is required by OAuth 2.1 and by many providers for public clients.

Press Get New Access Token. A popup opens at the provider; sign in and approve. The provider redirects the popup to the callback URL with a code, the app checks the state, and the code is exchanged for tokens. Allow popups for swastik.codes if your browser blocks it.

For Google the URLs are https://accounts.google.com/o/oauth2/v2/auth and https://oauth2.googleapis.com/token; for other providers, look for their OpenID Connect discovery document (/.well-known/openid-configuration), which lists authorization_endpoint and token_endpoint.

Authorization Code (without PKCE)

The same flow for confidential clients that do not use PKCE. Prefer the PKCE variant when the provider supports it.

Client Credentials – for service-to-service APIs

No user and no popup: the client authenticates as itself. Fill in Access Token URL, Client ID, Client Secret and Scope, then press Get New Access Token. This is the usual grant for machine APIs and for running a collection on a schedule in a monitor.

Password Credentials – legacy only

The client sends a username and password directly to the token endpoint. OAuth 2.1 removes this grant and many providers disable it, but older internal APIs still use it. Fill in Username and Password in addition to the token URL and client details.

Implicit – legacy only

The token is returned directly in the redirect, without a code exchange. It is also removed in OAuth 2.1. It is supported for older providers; for anything new, use the authorization code grant with PKCE.

Client authentication and extra parameters

Client Authentication decides how the client ID and secret reach the token endpoint: Send as Basic Auth header (the default) or Send client credentials in body. If the provider answers invalid_client although the secret is right, try the other option.

Under the advanced fields you can set Audience and Resource (Auth0 and resource-indicator providers need these), a separate Refresh Token URL, and two tables of extra parameters: Extra authorization request parameters (for example prompt=consent or access_type=offline for Google, to get a refresh token) and Extra token request parameters, where each row can be sent in the request body, a header or the URL.

Step 3: use the token

When the token arrives it is shown in a dialog; press Use Token. The Current token section then holds the access token and controls how it is sent:

• Header Prefix – Bearer by default.
• Add token to – Request Headers (Authorization: Bearer …) or Request URL for APIs that expect it as a query parameter.
• Use Token Type – when the provider also returned an OpenID Connect ID token, choose whether to send the access token or the ID token.

Send any request in the collection and it carries the token. To check, open the console: it shows the request headers that were actually sent.

Keep tokens out of shared documents

Fields accept variables, so the client secret can be {{clientSecret}} with the value stored in an environment. Variable current values stay on your device and are not synced, so a secret kept as a current value is not shared with your team. The vault keeps encrypted secrets that resolve only for hosts you allow. See environments and variables.

Step 4: refresh and manage tokens

Access tokens expire. If the provider returned a refresh token:

• Auto-refresh token (on by default) swaps an expired token for a fresh one through the refresh grant just before a request is sent.
• Refresh token in the Current token section refreshes on demand.

Manage opens the list of saved tokens. Each token has a name (from Token Name), its expiry and its refresh token, and you can use, refresh or delete it, or clear all expired ones. Expired tokens are marked in the token selector.

Getting a token in a script instead

Sometimes a token comes from a non-standard login endpoint. A pre-request script with swc.sendRequest can fetch it and store it:

// Collection pre-request script
const expiresAt = swc.environment.get('tokenExpiresAt');
if (!expiresAt || Date.now() > Number(expiresAt)) {
  swc.sendRequest({
    url: swc.environment.get('loginUrl'),
    method: 'POST',
    header: [{ key: 'Content-Type', value: 'application/json' }],
    body: { mode: 'raw', raw: JSON.stringify({
      username: swc.environment.get('user'),
      password: swc.environment.get('password')
    }) }
  }, function (err, res) {
    if (err) { console.log('login failed', err); return; }
    const body = res.json();
    swc.environment.set('token', body.access_token);
    swc.environment.set('tokenExpiresAt', Date.now() + (body.expires_in - 30) * 1000);
  });
}

Then set the collection's auth to Bearer Token with the value {{token}}. More script patterns are in writing API tests with swc.* scripts.

Other schemes in the same tab

OAuth 2.0 is one of several authorization types. The same tab handles API Key, Bearer Token, JWT (signed for you), Basic, Digest, OAuth 1.0, Hawk, AWS Signature v4, NTLM, Akamai EdgeGrid and ASAP. See the authorization feature page for the full list.

Troubleshooting

redirect_uri_mismatch or "invalid redirect". The callback URL registered with the provider must equal https://swastik.codes/oauth/callback exactly, including the scheme and with no trailing slash.

"Popup blocked". Allow popups for swastik.codes and press Get New Access Token again.

"OAuth state mismatch". An old popup answered after a newer attempt started. Close stray popups and retry.

invalid_client. Wrong secret, or the provider expects the credentials in the other place: switch Client Authentication between the Basic Auth header and the body.

invalid_grant on refresh. The refresh token was revoked or rotated. Get a new token with the original grant.

The token request never reaches the provider. If the token URL is on a private network or localhost, the swastik.codes server refuses it. Use a publicly reachable identity server.

Requests still return 401. Check the scopes and audience the API expects, and decode the token (the JWT payload is base64) to see what it actually contains.

Frequently asked questions

What callback URL should I register for Swastik Codes?

https://swastik.codes/oauth/callback for the web app.

Is PKCE supported?

Yes. Choose Authorization Code (With PKCE). The code verifier is generated automatically when the field is empty, and the challenge method can be SHA-256 (recommended) or plain.

Can one token be shared by every request in a collection?

Yes. Configure OAuth 2.0 on the collection or a folder and leave the requests on Inherit.

Can I test an MCP server that uses OAuth?

Yes. MCP requests include a discovery debugger that walks through protected resource metadata, authorization server metadata and dynamic client registration before getting a token. See testing an MCP server.

Are my client secrets synced?

Values you keep as a variable's current value stay on your device. Values you type directly into a saved request's auth fields are part of that request and are stored with the collection, so prefer variables or the vault for secrets.

Try it

Open the app, set OAuth 2.0 on a collection and get your first token; token requests need a free account. The authorization feature page lists every supported scheme, and environments and variables explains how to keep credentials per environment. If you are moving from another client, importing a Postman collection keeps its auth settings.