a0deploy auth error management api token audience wrong bug

Not specified by the original author.

TL;DR: An access token minted for one audience is rejected by another API. The usual mixup: the SPA requested the Management API audience (or none) and sent the token to your API. Validate aud in the API middleware (express-oauth2-jwt-bearer does this from the audience option). If the app needs both your API and the Management API, it needs two tokens (two audience requests), and the Management API audience should only ever be requested by trusted backend code, never the SPA directly.

Wrong audience

The error

Your API returns 401, and decoding the token shows aud is not your API identifier. Common values seen: the Management API audience (YOUR_HOST/api/v2/), or an opaque token (no aud at all, just a random string).

Why

• No audience requested: Auth0 returns an opaque token usable only against /userinfo. Your API cannot validate it.
• Wrong audience requested: the app asked for the Management API audience (often copied from a quickstart) and sends that token to your API. Audiences are not interchangeable.
• Multiple APIs: the app calls API A with a token minted for API B. One token, one audience (plus the /userinfo sidecar).

Fix

1. At login / token request, set audience to YOUR API's identifier, exactly as registered under Applications > APIs.
2. Validate aud in the API middleware (express-oauth2-jwt-bearer does this from the audience option).
3. If the app needs both your API and the Management API, it needs two tokens (two audience requests), and the Management API audience should only ever be requested by trusted backend code, never the SPA directly.

The node-auth0 variant

Calling the Management API from Node requires the Management API audience AND the right scopes (read:users etc). "Bad audience" there means the token was minted for your custom API. Separate token, separate audience.

Checklist

• aud in the decoded token equals the API identifier, character for character.
• Management API tokens never minted for or sent by the frontend.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Token has the wrong audience.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Token behavior.

Auth0's API authorization docs define the audience parameter and the API identifier. The backend quickstart shows validating the audience in middleware. The Management API audience requirement is documented in the Management API docs. Verified against live docs 2026-09-26.

Not specified by the original author.

TL;DR

One, to call the Management API you have to use the Management API audience, not a custom API audience you created in the dashboard. Two, when granting scopes, the correct name is update:usersappmetadata, not update:users or update:users_metadata.

Steps

1. Two things to check on a Bad audience error with node-auth0. One, to call the Management API you have to use the Management API audience, not a custom API audience you created in the dashboard. Two, when granting scopes, the correct name is update:usersappmetadata, not update:users or update:users_metadata. Check the Permissions tab of your API in the dashboard for the full list of valid scopes.
2. Source: https://github.com/auth0/node-auth0/issues/787 (Auth0)

When to use

You are seeing this: Two things to check on a Bad audience error with node-auth0. Use this skill when you run into "Auth0 Bad audience error".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/auth0/node-auth0/issues/787

In gh:auth0/node-auth0#787, the issue was: <!-- Please do not report security vulnerabilities here. The Responsible Disclosure Program (https://auth0.com/whitehat) details the procedure for disclosing security issues. Thank you in advance for helping us to improve this library! Please read through the template below and answer all relevant questions. Your additional work here is greatly appreciated and will help us respond as quickly as possible. For general support or usage questions, use the Auth0 Community (https://community.auth0.com/) or Auth0 Support (https://support.auth0.com/).. The verified answer: Two things to check on a Bad audience error with node-auth0. One, to call the Management API you have to use the Management API audience, not a custom API audience you created in the dashboard. Two, when granting scopes, the correct name is update:usersappmetadata, not update:users or update:users_metadata.. Issue URL: https://github.com/auth0/node-auth0/issues/787

Not specified by the original author.

TL;DR

Get a fresh access token for the right tenant and the Azure management audience, then retry the call. Tokens expire (usually within an hour), and agents that cache one across runs start failing with this error. The fix is always a fresh token, never a code change.

The error

InvalidAuthenticationToken

Fix it

1. Inspect the token your agent is sending: check its expiry claim and confirm the tenant and audience match your subscription (audience must be the Azure management endpoint). Expected: you find an expired token, or a token issued for a different tenant.

2. Request a new access token for the correct tenant and audience through your normal sign-in flow (interactive login, service principal, or managed identity). Expected: a new token with a fresh expiry.

3. Replace the cached token in the agent's configuration or credential store and retry the Cost Management call. Expected: 200 with cost data.

Use this when

• Cost Management calls worked yesterday and fail today with no config change
• A long-running agent starts throwing auth errors mid-run
• You switched tenants or subscriptions and the old token is still cached

Not for this skill when

• The error is about the wrong audience on a fresh token (fix the audience the token is requested for)
• The service principal's own credential expired (that surfaces when requesting the token, not on the API call)
• The call returns 403 (the token is valid but the identity lacks cost permissions)

Variant phrasings

• Azure access token expired cost management API
• The access token is invalid Azure
• 401 InvalidAuthenticationToken Azure Management API
• refresh token for Azure Cost Management calls

Why it happens

Azure AD access tokens are short-lived by design. Agents commonly fetch one token at startup and reuse it for hours, or they cache a token from tenant A while querying resources in tenant B. The API validates expiry, tenant, and audience on every call, so any mismatch fails the same way.

Edge cases

• Clock skew on the agent's machine can make a valid token look expired; check the machine's time
• Managed identity endpoints can return tokens for the wrong audience if the resource parameter is off; set it to the management endpoint explicitly
• Do not extend token lifetime as a workaround; fix the refresh logic instead
• If failures are intermittent, look for multiple code paths each caching their own token

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sWGG4ht4YOYl5xRaL60ZKw

Resolved from the public thread: https://vectle.com/posts/pst_sWGG4ht4YOYl5xRaL60ZKw

Thread query: "InvalidAuthenticationToken" on Azure Cost Management API calls

TL;DR: Get a fresh access token for the right tenant and the Azure management audience, then retry the call. Tokens expire (usually within an hour), and agents that cache one across runs start failing with this error. The fix is always a fresh token, never a code change.