MSAL Python 1.36.0 interactive authentication returns HTTP 200 with expires_in=0 — documented meaning and supported validity handling?

Question

We use MSAL Python 1.36.0 interactive authentication with a browser-based authorization-code/PKCE flow to obtain a Microsoft Entra access token for Azure Database for PostgreSQL.

The client uses an in-memory token cache, disables the Windows broker and excludes the offline_access scope. No tokens or raw authentication responses are retained.

A single controlled attempt produced these categorical observations:

• Browser authentication completed.
• Token-endpoint response: HTTP 200.
• Response body: valid JSON.
• Independent parsing of the response before returning it unchanged to MSAL found expires_in present as integer 0.
• The final MSAL result also contained expires_in as integer 0.
• Boundary and final expiry metadata matched.
• The client rejected zero expiry and stopped before any PostgreSQL connection.
• HTTP cleanup succeeded.

This establishes that zero was present before final MSAL result handling. We are not asserting that the access token itself had zero actual lifetime.

Questions:

1. Does expires_in=0 in a successful token response have a documented meaning for this interactive flow?
2. Is this a recognized Microsoft identity-platform or MSAL behavior? What documented conditions can produce it?
3. When expires_in is zero, is there a Microsoft-supported way to establish access-token expiration and sufficient remaining validity without inventing a duration or simply ignoring the value?
4. If another metadata source or token-validation method is supported, what validation requirements and limitations apply, particularly for Azure Database for PostgreSQL?
5. Should a security-sensitive client continue rejecting the response unless those requirements can be satisfied?

Please provide authoritative Microsoft documentation or an official issue reference where available. We seek a minimum supported correction to the existing flow, not a replacement authentication architecture.

No account, tenant, application or resource identifiers, credentials, tokens, authorization codes, raw responses or screenshots are included.

Answer 1

There is no documented Microsoft interpretation that makes an explicit expires_in: 0 a normally usable access-token lifetime.

For a security-sensitive client, rejecting that result is the correct conservative behavior. Do not invent a lifetime, substitute ext_expires_in, or parse the access token to create your own client-side validity rule. Microsoft documents that clients should treat access tokens as opaque and use MSAL's supported acquisition/cache behavior; the resource API is responsible for validating the token.

In MSAL Python's cache logic, expires_on is calculated from the current time plus expires_in. The library supplies a fallback only when expires_in is absent; an explicit integer zero therefore represents immediate expiry for cache purposes. That is consistent with the client refusing to use it, even if the token's internal claims might appear different.

A minimum supported diagnostic path is:

1. Upgrade to the latest supported MSAL Python release and reproduce once with a fresh in-memory cache.
2. Use acquire_token_silent() (or acquire_token_silent_with_error() where appropriate) before interactive acquisition and let MSAL decide whether a cached token is usable.
3. If the interactive response again contains integer zero, stop before opening the PostgreSQL connection, as your client already does.
4. Capture the MSAL correlation ID, UTC timestamp, tenant cloud, authority, requested scopes and library version. Do not capture or publish the token or authorization code.
5. Open a Microsoft identity platform support case, or a minimal MSAL Python issue if support confirms a library-specific problem. The raw token-endpoint response proves this is not introduced by your PostgreSQL code.

There is no supported client-side method that can safely convert this response into a reliable positive remaining lifetime. Azure Database for PostgreSQL will validate the presented token, but relying on the database to reject an ambiguously expired token is not a substitute for correct client handling.

References:

• MSAL Python token acquisition and cache guidance
• Microsoft identity platform access tokens
• MSAL Python token-cache implementation