OAuth 2.0 Token does not expire as expected

Question

OAuth 2.0 Token does not expire as expected

Eckhart, Johannes 0

Dear Microsoft Support Team,

I need your help with an issue regarding OAuth 2.0 token expiration in our Azure-based setup.

Our system architecture (simplified):

Service B needs to fetch an access token to communicate with external services inside our Microsoft environment.

Tenant ID → belongs to Service A, against which the token is requested.

Client ID & Client Secret → come from a separate App Registration, from Service B

Goal: Register external services and enable communication using token-based authentication.

What I did (following the documentation):

Requested credentials from Servie A and B:

AUTH_MICROSOFT_CLIENT_ID
- AUTH_MICROSOFT_CLIENT_SECRET
- AUTH_MICROSOFT_TENANT_ID
- baseUrl (our API endpoint)

Acquired token via OAuth 2.0 client credentials flow:

curl --location 'https://login.microsoftonline.com/{TENANT_ID}/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id={CLIENT_ID}' \
--data-urlencode 'client_secret={CLIENT_SECRET}' \
--data-urlencode 'resource=https://management.azure.com/'

Response example:

{
    "token_type": "Bearer",
    "expires_in": "3599",
    "ext_expires_in": "3599",
    "expires_on": "1776936897",
    "not_before": "1776932997",
    "resource": "https://management.azure.com/",
    "access_token": "eyJ0eXAiOiJKV1QiLCJ..."
}

The problem:
The response clearly states expires_in: 3599 (1 hour).
However, the token I received does not expire as expected.
I tested a token generated one week ago – it is still valid today.

This should not happen with the default OAuth 2.0 client credentials flow.

Questions:

Are there any Azure settings (App Registration, Enterprise Application, Token lifetime policies, or Conditional Access) that could cause a token to ignore expires_in?

Could the resource (https://management.azure.com/) or a specific API policy override token expiration?

Is it possible that token validation is not checking expiration on the API side (our baseUrl service)?

Where else should I look for misconfiguration?

We changed nothing regarding token expiration – we use Azure defaults.

Thank you for your help.

Best regards,
Johannes

VEMULA SRISAI 14,065 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-06T15:43:10.6466667+00:00

Eckhart, Johannes I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.

2 Antworten

Ihre Antwort

VEMULA SRISAI 14,065 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-06T15:43:10.6466667+00:00

Eckhart, Johannes I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.

Answer 1

VEMULA SRISAI 14,065 Externe Microsoft-Mitarbeiter Moderator

Hello Eckhart, Johannes,

Thank you for the detailed explanation. Based on the information shared, this behavior is not expected from Microsoft Entra ID for a client credentials–based access token.

An access token issued via the OAuth 2.0 client credentials flow always has a fixed lifetime (typically ~1 hour by default). The values returned in the token response (expires_in, expires_on, and the exp claim in the JWT) reflect the actual token validity and are enforced by Microsoft Entra ID. There is no supported configuration that would cause a token with expires_in: 3599 to remain valid for a week.

Given this, the most likely causes are on the resource/API validation side, not on the token issuance side:

Token expiration is not being validated by the API The API receiving the token (baseUrl) must explicitly validate the token’s exp and nbf claims. If lifetime validation is missing or incomplete, an expired token can still be accepted. This is the most common cause of the behavior you’re seeing.
Audience / resource mismatch The token is requested for resource=https://management.azure.com/, which means the token’s aud is Azure Resource Manager. If the same token is being accepted by a custom API, that indicates the API is not strictly validating the aud claim, which is a security misconfiguration.
Token lifetime policies / Conditional Access Custom token lifetime policies can change access token lifetime, but only up to 1 day maximum, and Conditional Access / CAE does not allow week‑long validity for app‑only tokens. These settings do not explain a token remaining valid for a week. What to check next

Decode both the old and new tokens (for example using jwt.ms) and verify:
- exp is already in the past for the one‑week‑old token
- aud is https://management.azure.com/
Review token validation logic on the API side (or API Management policies, if used) and ensure:
- Signature, issuer, audience, and expiration (exp) are enforced

Confirm the token is actually being presented directly to Azure Resource Manager and not to a custom endpoint that bypasses lifetime validation

Conclusion

Microsoft Entra ID is issuing the token correctly, and the token does expire as stated. If an old token is still accepted, the issue is almost certainly due to missing or incorrect token validation on the resource/API side, not an Entra ID configuration.

Please let us know if you want help reviewing your API token validation setup.

Eckhart, Johannes 0 Zuverlässigkeitspunkte

2026-05-11T06:50:35.1466667+00:00
Hi all,

big thanks for your advices😊. Finally I understood how Azure AD works and that I have to care myself to validate that everything is correct. Just to clarify: as I assumed that our resources are located in the Azure cloud, Microsoft – much like middleware – automatically checks whether requests are authorized and valid at all times, meaning that I can only gain access with a valid token from the authentication resource. That's wrong and now i know it better.

Also, following your suggestions, I add an audience check too. What I don’t quite understand yet, however, is how this ‘aud’ is included in the user login. I am using for Next-Auth to mange the login and tried to define the following code with this scope: (Maybe you have also advice for this?)

const authOptions: NextAuthOptions = { providers: [ AzureADProvider({ clientId: process.env.AUTH_MICROSOFT_ENTRA_ID_CLIENT_ID || "", clientSecret: process.env.AUTH_MICROSOFT_ENTRA_ID_SECRET || "", tenantId: process.env.AUTH_MICROSOFT_ENTRA_ID_TENANT_ID || "", authorization: { params: { scope: `profile openid email User.Read api://..../access_as_user`, }, }, }), ... ]}

I expected that I receive sth. like "api://..../access_as_user" but I am getting something like this "00000003-0000-0000-c000-000000000000". The default scope of Microsoft aud, so far as I understand.
VEMULA SRISAI 14,065 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-05-13T13:06:27.2566667+00:00
Eckhart, Johannes Thanks for the update, and great to hear you were able to resolve the token validation part 👍

Regarding your follow-up question on the aud claim and scopes in your NextAuth configuration, let me clarify how this works in Microsoft Entra ID.

In your current request:

scope: profile openid email User.Read api://..../access_as_user

``

you are requesting permissions across multiple resources:

User.Read → Microsoft Graph

api://.../access_as_user → your custom API

In Microsoft Entra ID, an access token is always issued for a single resource only. When multiple resources are included in the same request, the platform will issue a token for one of them (in your case, Microsoft Graph). That is why you are seeing:

aud = 00000003-0000-0000-c000-000000000000

This App ID corresponds to Microsoft Graph, so the token you are receiving is a Graph access token, not a token for your custom API.

Why access_as_user is not reflected in aud

The value access_as_user is a scope (permission) exposed by your API, not the audience itself.

The aud claim will always be set to the Application (client) ID or URI of the target API, not the scope name. So unless the token is explicitly issued for your API, you will not see your api://... value in aud.

What you should change

If your intention is to call your custom API, you should not mix Graph and custom API scopes in the same token request.

You can use one of the following approaches:

Option 1 (Recommended): Separate tokens per resource

Use NextAuth only for user sign-in:scope: "openid profile email"

Then acquire a separate access token for your API using: api:///access_as_user

Option 2: Request token directly for your API

Remove Graph scopes from the request:

scope: "openid profile email api://<your-api-client-id>/access_as_user"

This should result in a token where: aud = <your API App ID / URI>

Additional checks

Please also ensure:

Your API is properly configured under Expose an API

The access_as_user scope is defined there

The client application has permission to this scope and consent is granted

Your API validates the aud claim correctly (should match your API)

Answer 2

Hi Johannes,

This is definitely strange behavior for the standard OAuth 2.0 Client Credentials flow. Since Microsoft Entra ID (Azure AD) is quite rigid with its default 1-hour expiration for access tokens, the issue usually isn't that the token isn't expiring—it's usually that the resource (the API) isn't checking the expiration date.

Here is a breakdown of where things might be going sideways and what you should check:

The "Old Token" Test (The Smoke Test)

Take that 1-week-old token and paste it into jwt.ms.

Look for the exp (expiration) claim.

If the date in the exp claim is in the past (which it should be), then Microsoft Entra ID has done its job correctly.

The Conclusion: If the token is expired according to the payload but your baseUrl service still accepts it, the issue lies entirely within your API’s token validation logic, not Azure’s settings.

Validation Logic at baseUrl

Most APIs that receive a Bearer token need to perform several checks. It sounds like your service might be validating the Signature (confirming the token was signed by Microsoft) but skipping the Lifetime Validation.

Check your code: If you are using middleware (like Microsoft.Identity.Web for .NET or passport-azure-ad for Node.js), ensure that ValidateLifetime is set to true.

Clock Skew: Most libraries allow for a 5-minute "clock skew" to account for time differences between servers. However, a week is way beyond any drift settings.

The Audience (aud) Claim Mismatch

You are requesting a token for resource=https://management.azure.com/.

The Risk: If you are sending this token to your own custom API (Service B / baseUrl), your API should technically reject it because the aud (Audience) claim in the token is for Azure Management, not your specific service.

If your API accepts a token meant for a different resource and doesn't check the expiration date, it indicates the validation middleware is likely set to "permissive" or is incorrectly configured.

Are you using a Proxy or WAF?

Sometimes, an Intermediate layer (like an Azure Application Gateway, an F5, or a specialized WAF) might be caching authorization headers or performing its own validation. If the backend never sees the "fresh" request and simply relies on a cached "200 OK" from a previous session, it might appear as if the token is still valid.

Summary Checklist for your Team:

Decode the token: Verify exp via jwt.ms.

Verify API Middleware: Ensure the service at baseUrl is explicitly configured to validate Lifetime and Audience.

Check for Caching: Ensure there is no local cache (Redis, In-Memory) on the API side that stores the "Validated" status of a token indefinitely.

If the exp claim in the JWT actually shows a date in the future (one week away), please let us know, as that would imply a Token Lifetime Policy has been applied to your Service Principal via PowerShell/Graph API, though even then, a 1-week duration for an access token is highly non-standard.

I hope this helps you narrow it down!

Best regards,

OAuth 2.0 Token does not expire as expected

2 Antworten

Additional checks

Ihre Antwort