Azure AD service principal token persists after client credential expiry

There is no native, built-in mechanism to instantly revoke access tokens issued to a service principal once the client secret or certificate expires. Because Azure AD access tokens are stateless JSON Web Tokens (JWTs), resource providers validate them locally by checking the digital signature and the exp claim rather than performing a live check against Entra ID (formerly Azure AD) for every request.

The Token Persistence Gap

When a credential expires, any token already issued remains valid until its intrinsic lifetime ends—typically 60 to 90 minutes. Furthermore, Role-Based Access Control (RBAC) permissions are evaluated at the moment of token issuance. If a role is revoked from a service principal after a token has been cached, that token will retain the granted permissions until it naturally expires.

Strategies for Invalidation and Mitigation

To bridge the gap between token lifetime and credential expiry, consider the following technical approaches:

• Service Principal Deletion: This is the only method to instantly invalidate all active tokens. Deleting the service principal object causes all token validation to fail immediately because the identity no longer exists. However, this causes immediate downtime for all legitimate operations.
• Shortening Token Lifetimes: While you cannot globally shorten the default token lifetime for service principals easily, you can configure your application logic to refresh tokens more frequently. This reduces the "window of vulnerability" but increases the load on the Entra ID endpoint.
• Managed Identities: Transitioning from client secrets to Managed Identities eliminates the manual credential rotation lifecycle. While the token persistence issue remains, the risk of a leaked, long-lived secret is significantly mitigated.
• Resource-Side Validation: For high-security environments, implement custom logic at the resource provider (e.g., a custom API gateway) that checks a "revocation list" or a status database before processing the request, regardless of the JWT's signature validity.

Interaction with Credential Rotation

Standard credential rotation (adding a new secret before deleting the old one) is designed for zero-downtime. This creates an overlap period where both credentials are valid. If the original credential is compromised, rotation alone does not invalidate the tokens generated by the compromised secret; it only prevents new tokens from being issued using that secret.

Note: Is your application using a custom middleware that caches tokens in-memory, or is it requesting a new token for every transaction? Understanding the caching behavior is critical for determining the actual window of risk.