Microsoft Entra ID token inspection using Postman

Revised article

This is a revised version of an article originally published on larsolino.dev on November 14, 2019.

Postman can help test an OpenID Connect application registered in Microsoft Entra ID (formerly Azure AD). You can obtain tokens, inspect the returned claims and isolate configuration problems before integrating a backend.

This revises the original 2019 walkthrough to use the v2.0 endpoints and authorization code flow with PKCE. The old screenshots of client secrets and token values are intentionally replaced by placeholder-based configuration.

Prepare a dedicated test application

In Microsoft Entra ID → App registrations, create or select a test application. Note its Application (client) ID and Directory (tenant) ID.

For the concrete example below, register a Web redirect URI under Authentication and create a temporary client secret under Certificates & secrets. Use the secret's value, not its identifier. This tests a confidential client: the token exchange runs in the Postman desktop app and authenticates with the secret.

Select Authorize using browser in Postman and register the exact callback URL it displays. Current documentation lists https://oauth.pstmn.io/v1/browser-callback; use the value shown by your installed version. Do not substitute an arbitrary localhost URL unless your test client actually handles that callback.

A public desktop-client registration is another option, but its platform and redirect configuration must match that client model; it does not use a client secret. Do not mix the two configurations.

For this authorization code flow, you do not need to enable implicit access-token or ID-token issuance. PKCE also applies when the code flow uses a confidential client. See Microsoft's authorization code flow documentation.

Discover the endpoints

The application's Endpoints dialog links to its OpenID Connect metadata. For a tenant-specific v2.0 authority, the metadata URL is:

https://login.microsoftonline.com/{{tenant}}/v2.0/.well-known/openid-configuration

Replace {{tenant}} with your tenant ID. Check the authorization_endpoint, token_endpoint, issuer and jwks_uri values. The version in the metadata URL should match the endpoints used in your test. See Microsoft's OIDC discovery documentation.

Configure OAuth in Postman

In a request or collection, choose Authorization → OAuth 2.0 and configure a new token:

Field	Value
Grant type	Authorization Code (With PKCE)
Code challenge method	SHA-256
Authorize using browser	Enabled
Callback URL	The exact registered callback URL
Auth URL	https://login.microsoftonline.com/{{tenant}}/oauth2/v2.0/authorize
Access Token URL	https://login.microsoftonline.com/{{tenant}}/oauth2/v2.0/token
Client ID	Your test application's client ID
Client Secret	Your temporary secret value, stored privately
Scope	openid profile email
Client authentication	Send client credentials in body

Use a fresh unpredictable state value for each authorization request and verify its return. A small random integer is not an appropriate production anti-forgery mechanism. For an application implementation, let an OIDC library manage state, PKCE and nonce validation.

Click Get New Access Token, sign in with a test user and complete any consent prompt allowed by your tenant. Inspect the token response. The openid scope requests an ID token; an access token has a different purpose and audience. Postman's OAuth guide covers its token helper.

Inspect the ID token

Find the id_token in the token response or token details. Decode its payload locally to inspect it. Do not paste live credentials or tokens into a public decoder or a shared troubleshooting report.

Decoding a JWT only makes its claims readable; it does not validate the signature or establish that the token is trustworthy. A real application must validate the signature using the issuer's signing keys, the expected issuer and audience, token lifetime and the nonce when used. An ID token's audience should identify your client. Microsoft's ID-token claims reference explains the relevant claims.

Successfully retrieving a token confirms part of the configuration; it does not by itself prove that the application's validation or authorization is correct.

Check group membership

To include groups, configure a groups claim in the app registration's Token configuration and choose which group types to emit. For the object-ID configuration used here, an ID-token payload excerpt can look like:

{
  "groups": [
    "ac5db011-28d6-4738-8f3b-b84b52c41a56",
    "3bf13aad-eead-44ee-b666-ba9669a5b120"
  ]
}

These values are directory group object IDs. Match them to the groups your application is authorized to use; do not treat an arbitrary group's presence as permission.

A missing groups array does not necessarily mean that the user has no memberships. JWT group claims have a 200-group limit; an overage indication means the application must retrieve membership through Microsoft Graph with the appropriate permissions. App roles can be a better fit when the application needs application-specific permissions. See Microsoft's group claims and app roles guidance.

Do not assume that the access token from a basic OIDC test can call every Microsoft Graph endpoint. Request the required delegated Graph scopes and consent for that resource, then use an access token intended for Graph. An ID token is not an API bearer token.

Troubleshooting and cleanup

Symptom	What to check
Redirect URI mismatch	Compare the registered URI with Postman's callback, including its path.
invalid_client	Check the registration type, secret value, expiration and client authentication method.
Consent or sign-in blocked	Read the tenant policy or Conditional Access error; use an approved test application.
Missing ID token	Check that openid was requested and inspect the token response.
Missing groups	Check token configuration, the test user's memberships and group overage indicators.
API rejects the token	Check its audience, requested resource scopes and whether you sent the access token.

Remove temporary secrets and redirect URIs when the test is complete. Keep token values and secrets out of exported collections, screenshots and source control.