Authentication tokens are the mechanism through which applications receive proof of identity and authorization. Microsoft Entra ID issues tokens based on defined policies, and those tokens directly affect user experience, security posture, and application behavior.
Token lifetime configuration
You can specify the lifetime of tokens issued by the Microsoft identity platform. Token lifetime settings can be applied at different scopes:
Across all applications in the organization.
To a multitenant application.
To a specific service principal in your tenant.
In Microsoft Entra ID, a policy object represents a set of rules that are enforced on applications. Each policy type has its own structure and applies to specific objects.
A policy can be designated as the default policy for the organization. Default policies apply to all applications unless they are overridden by another policy with a higher priority. Priority handling differs depending on the policy type.
Authentication session management with Conditional Access
In more complex environments, organizations may need to restrict how long authentication sessions remain valid.
Access from unmanaged or shared devices.
Access to sensitive data from external or untrusted networks.
High-impact users such as administrators.
Critical business applications.
Conditional Access allows administrators to target these scenarios precisely, rather than applying restrictive controls to all users.
Token lifetime concepts
Access and ID token lifetime, which controls how long access and ID tokens are valid.
Refresh token lifetime (days), which defines how long a refresh token can be used to request new access tokens.
Refresh token sliding window lifetime, which determines whether the refresh token validity extends with continued use.
Lifetime length (days), after which the user must reauthenticate regardless of activity.
When the refresh token lifetime expires, the user is forced to sign in again. This is a critical security control for long-lived sessions.
Optional claims in tokens
Application developers can configure optional claims to control what information appears in tokens issued to their applications.
Include additional claims in access or ID tokens.
Modify the behavior of certain default claims.
Add custom claims for application-specific logic.
OAuth 2.0 v1.0 tokens.
OAuth 2.0 v2.0 tokens.
SAML tokens.
They are most important when working with v2.0 tokens, because Microsoft intentionally reduced default token size to improve performance. Claims that were automatically included in v1.0 tokens must often be explicitly requested in v2.0.