Key takeaways
- Azure AD (Entra ID) access tokens expire after roughly 60 to 90 minutes by default, and the exact value varies by client, sign-in session, and Conditional Access policy.
- You cannot change the access token lifetime tenant-wide; the supported approach is Conditional Access sign-in frequency, while legacy token lifetime policies via New-AzureADPolicy only work for some clients.
- Google OAuth and gcloud CLI access tokens last about one hour with no policy to change that, so scripts must read the exp claim and refresh rather than cache printed tokens.
- LinkedIn member tokens expire after 60 days with refresh tokens limited to approved partners, Facebook long-lived tokens last about 60 days, and GitLab personal access tokens can be created with no expiration at all.
- Vaults store secret values but not ownership or expiry metadata, so track each credential's owner, expiry date, and rotation deadline as separate attributes to prevent outages.
The default azure ad access token expiration time is 60 to 90 minutes, and you can only change it with Conditional Access or token lifetime policies, not tenant-wide settings. Google, Facebook, LinkedIn, and GitLab each handle it differently, which is why this guide puts default, maximum, and configurability for all of them in one comparison table.
What is the default Azure AD access token expiration time?
Access tokens issued by Entra ID (Azure AD) expire after roughly 60 to 90 minutes by default, and the exact value varies by client and protocol. Microsoft does not publish a single fixed number because the lifetime is tuned per client, per sign-in session, and per Conditional Access policy. Microsoft's documentation on configurable token lifetimes covers the defaults and the preview policies that change them.
Default lifetime for Entra ID issued tokens
For most sign-ins, expect an access token valid for about an hour. Refresh tokens last longer, up to 90 days for single-page apps and 14 days in older scenarios, but they are revoked by password changes, Conditional Access, or user disablement.
What varies the default: client, sign-in session, and Conditional Access
Conditional Access sign-in frequency overrides the default: set it to 4 hours and tokens re-issue on that cadence. Token lifetime policies only apply to some clients, and Microsoft recommends leaving defaults alone for most tenants. Either way, expiry is only half the problem: someone still has to track which token expires when and who owns it, which is where credential expiration reminder tooling fits in.
How do you change Azure AD token lifetime with Conditional Access or PowerShell?
The old way was a token lifetime policy in PowerShell. Microsoft deprecated that for most scenarios and now steers you to Conditional Access sign-in frequency, which controls how often users must re-authenticate rather than the access token itself.
Configurable token lifetime policies via PowerShell (New-AzureADPolicy)
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"AccessTokenLifetime":"02:00:00"}}') creates a policy, and Add-AzureADApplicationPolicy attaches it to a service principal. This still works for some legacy cases, but Microsoft's guidance is that lifetime policies are no longer generally configurable for tokens issued by Azure AD to first-party resources.
Conditional Access sign-in frequency as the supported replacement
Set sign-in frequency (for example, every 12 hours) in a Conditional Access policy targeting specific users or apps. The access token default stays around 60-90 minutes, but re-authentication is enforced at the interval you choose.
Refresh token and session token maxima
Refresh tokens default to 90 days of inactivity before revocation, and session tokens follow the same pattern. If you are also governing non-Microsoft API keys with fixed expiry dates, the same ownership-and-deadline discipline applies; see https://keyguardrail.com/blog/api-key-expiration-policy-examples for worked examples.
How does Azure AD token expiration compare to Google and gcloud access tokens?
Azure AD gives you control; Google gives you a fixed default. Entra ID access tokens default to roughly 60-90 minutes, and you can shorten or lengthen the effective session through Conditional Access sign-in frequency, per Microsoft's sign-in frequency documentation. Google issues OAuth access tokens for about one hour and does not expose a policy to change that.
| Provider | Default access token lifetime | Configurable? |
|---|---|---|
| Azure AD (Entra ID) | ~60-90 minutes | Yes, via Conditional Access |
| Google OAuth | ~1 hour | No |
| gcloud CLI | ~1 hour | No, auto-refreshed |
Google OAuth access token expiration
Google access tokens expire in about an hour. Your code refreshes them with the refresh token, so the expiry rarely surfaces unless the refresh token is revoked or your service stores an access token past its lifetime.
gcloud CLI access token expiration and refresh behavior
gcloud auth print-access-token returns a token valid for roughly an hour. The CLI refreshes it on your behalf, which works well interactively but breaks scripts that cache the printed value.
Google Drive API tokens in practice
Drive API calls follow the same one-hour pattern. If you are tracking expiring tokens across AWS, Google, and SaaS providers, a metadata-only inventory like KeyGuardRail's automation brief covers why ownership and expiry tracking matter more than the value itself.
What are the expiration rules for Facebook, LinkedIn, and GitLab access tokens?
Facebook app access token expiration: short-lived vs long-lived vs never-expiring page tokens
Facebook issues short-lived user tokens (about an hour) that you exchange for long-lived ones (about 60 days). Page tokens derived from a long-lived user token can be non-expiring, which is why a page token buried in a Postman collection can quietly outlive every rotation policy you wrote.
LinkedIn access token expiration time: 60-day member tokens and refresh limits
LinkedIn member access tokens expire after 60 days. Refresh tokens are only available to approved partners, so most integrations re-run the OAuth flow on a 60-day clock and need an owner who knows it.
GitLab personal access tokens: optional no-expiration and admin-enforced maxima
GitLab lets you create personal access tokens with no expiration date at all, while instance administrators can enforce a maximum lifetime. That combination means your expiry posture depends on who created the token and under what policy. The pattern across all three: expiration is set by the provider's defaults, the token type, and whoever clicked "create", in that order. A 60-day LinkedIn token, a never-expiring GitLab PAT, and a Facebook page token with no deadline all land in the same vault as opaque strings, and the vault stores the value, not the metadata. The fix is treating expiry as a tracked attribute with a named owner and a deadline, which is the gap KeyGuardRail covers by monitoring credential lifecycle metadata without taking custody of the secret value; the same principle applies to the integration credentials tracked in our October 2026 brief.
Why do some OAuth access tokens have no expiration and is that safe?
Providers that issue non-expiring tokens and why
A few providers still issue tokens with no exp claim at all. GitHub personal access tokens (classic) never expire unless you opt into expiration at creation. Some legacy OAuth integrations, and certain third-party APIs built on the Google Identity Platform's OAuth 2.0 model, treat the refresh token as effectively permanent and the access token as the only short-lived credential. The usual reason is developer convenience: nobody wants a script to break at 2am.
Risk trade-off: blast radius vs rotation burden
A non-expiring token trades rotation burden for blast radius. If it leaks, it works indefinitely, and your only remediation is manual revocation. An expiring token caps that window but adds a rotation deadline someone has to own. For long-lived tokens you keep, record the owner and the review cadence so "no expiry" becomes "reviewed quarterly," not "forgotten." We cover the tracking workflow in how to track API key expiry.
How should refresh tokens and access token lifetimes be configured together?
Treat the two as one policy, not two settings. A short access token (15–60 minutes) only buys you anything if the refresh token behind it is bounded, because a refresh token that lives for a year lets an attacker mint fresh access tokens indefinitely. The pattern most teams land on: short access tokens, refresh tokens capped at 30–90 days, rotation on every refresh.
Short access token, bounded refresh token pattern
Short access tokens limit the blast radius of a leaked token, since scope and audience are enforced at issuance and the damage window is the token lifetime. The refresh token is the real crown jewel, so bind it to a client ID, rotate it on use, and revoke it when a rotation deadline hits. This is the same 30/60/90 day discipline you already apply to long-lived API keys.
Sliding vs absolute refresh token windows
Sliding windows extend the refresh token on every use, which keeps active services alive but means a continuously used token never expires. Absolute windows expire on a fixed deadline no matter how often it's refreshed. For service credentials, prefer absolute; for human logins, sliding with an absolute cap is a reasonable compromise. Whichever you pick, the expiry date needs an owner and an audit trail, or it becomes another secret nobody tracks.
How do you handle token expiry in long-running services without hardcoding lifetimes?
Hardcoded lifetimes break the moment a provider changes a default: Azure AD tokens moved from 60 to about 60-90 minutes depending on policy, and Google's gcloud access tokens expire after roughly one hour (gcloud CLI documentation). A constant in your code will drift from reality.
Read exp from the token, not from a constant
Decode the JWT and read the exp claim at runtime. Your service then tracks whatever lifetime the issuer configured, whether that is a Conditional Access policy change or a provider default. Cache the decoded claim and re-check before each call.
Proactive refresh with jitter and 401 retry backoff
Refresh when exp is within a threshold, say 5 minutes, plus random jitter so a fleet of instances does not stampede the token endpoint simultaneously. Treat any 401 as a signal to force a refresh and retry once, with exponential backoff, rather than crashing the job.
How do you track expiring tokens across providers when your vault only stores values?
Vaults store secrets, not ownership and expiry metadata
AWS Secrets Manager, HashiCorp Vault, and Infisical encrypt and deliver secret values. None of them answer the operational questions that actually cause outages: who owns this key, when does it expire, and when is the next rotation deadline in your 30/60/90 day policy? A GitHub PAT with no expiry, a Stripe key, and an Entra ID client secret all look the same once stored: an opaque value with no owner attached. That gap is why secrets sprawl persists even after a vault rollout.
Metadata-only lifecycle monitoring with KeyGuardRail
KeyGuardRail tracks credential lifecycle metadata — owner, provider, expiry date, rotation deadline, audit trail — without taking custody of the secret value itself. Your vault keeps storing values; KeyGuardRail tells you what expires next and who owns it. That means you can see an expiring Entra ID token, a stale Postman collection key, and a long-lived AWS credential in one inventory, and assign each an owner before it fails. It does not rotate secrets for you and does not replace your vault; it coordinates the deadlines your vault cannot see. Self-serve signup starts with the Starter tier.
FAQ
Do Azure AD access tokens expire even if the user is still signed in?
Yes. Access tokens from Entra ID expire after roughly 60 to 90 minutes regardless of session state. The user stays signed in because refresh and session tokens keep the session alive, and a new access token gets issued on the next sign-in or token request. Conditional Access sign-in frequency controls re-authentication, not the access token itself.
How long is a Google access token valid before it expires?
About one hour. Google issues OAuth access tokens with a fixed lifetime near 60 minutes and offers no policy to change it, unlike Azure AD's Conditional Access options. The gcloud auth print-access-token command returns a token on the same clock, and the CLI refreshes it automatically, which breaks scripts that cache the printed value past its expiry.
Can I make a GitLab personal access token that never expires?
Yes. GitLab lets you create personal access tokens with no expiration date at all. The catch is that instance administrators can enforce a maximum lifetime, so whether a non-expiring token is possible depends on your instance's policy. If you create one, record its owner and a review cadence, since remediation for a leak is manual revocation only.
What happens when a Facebook long-lived access token expires and how do I renew it?
After roughly 60 days, the long-lived user token stops working and there is no refresh endpoint for it. The standard path is re-running the OAuth flow to mint a fresh short-lived token, then exchanging it for a new long-lived one. Page tokens derived from a long-lived user token can be non-expiring, so check which token type you actually hold.
Is there one standard oauth access token expiration time all providers follow?
No. Azure AD defaults to roughly 60 to 90 minutes, Google fixes at about one hour with no configurability, LinkedIn member tokens run 60 days, Facebook short-lived tokens last about an hour while long-lived ones reach 60 days, and GitHub classic PATs can carry no expiry at all. Read the exp claim at runtime instead of hardcoding a constant.