Firebase Auth Token Expiry: How Long ID Tokens Last

TL;DR — A Firebase Auth short-lived access token (officially the ID token) expires exactly 1 hour (3,600 seconds) after it is minted. This value is fixed and not configurable — despite what some tutorials imply, there is no setting, flag, or API to change it. The client SDKs silently swap in a fresh token using a long-lived refresh token, so end users stay signed in without noticing.

As of 25 May 2025 (UTC). Verify against the Firebase session-management docs.

What is the Firebase Auth token expiry time?

A Firebase ID token expires 1 hour (3,600 seconds) after it is issued. This lifetime is hard-coded by Firebase and cannot be shortened or extended. The client SDK automatically refreshes it in the background, so your users are not signed out every hour.

That one-line answer covers the intent behind most searches for "Firebase Auth short-lived access token expiry time." The rest of this article explains the naming, why the TTL is locked, how refresh works, and how to inspect expiry in your own code.

"Access token" vs "ID token": clearing up the terminology

The phrase "access token" trips up a lot of developers coming to Firebase from generic OAuth 2.0. In Firebase Authentication, the short-lived credential your app actually carries around is the ID token — a signed JWT (RS256) — not an OAuth "access token."

Here is how the pieces map:

ConceptFirebase nameLifetimeConfigurable?
Short-lived bearer credentialID token (JWT)1 hourNo
Long-lived credential used to mint new ID tokensRefresh tokenUntil a session-ending eventNo
Field name in the refresh REST responseid_token, with expires_in: "3600"1 hourNo

So when a developer asks about the "short-lived access token expiry," they are almost always asking about the ID token, which lasts one hour. (Note: the oauthAccessToken you sometimes see in sign-in responses is a provider token from Google/Facebook/etc. — a separate thing governed by that provider, not by Firebase.)

Why you can't configure the Firebase token TTL

This is the false-premise correction worth stating plainly: there is no "token refresh interval" setting to configure. The Firebase team has repeatedly confirmed that ID tokens expire one hour after creation and that this expiration cannot be changed.

A few concrete reasons and constraints:

  • Fixed exp ceiling. For custom tokens you sign yourself, the JWT exp claim can be at most 3,600 seconds later than iat. Set it higher and Firebase rejects the token. For ID tokens minted by Firebase, the one-hour window is chosen for you.
  • It's a security design, not a bug. A short window limits the blast radius if a token leaks, while the refresh token keeps the UX seamless.
  • This wasn't always true. The legacy (pre-Google) Firebase system let you pick TTLs from one hour up to years, including a never-expire option. Modern Firebase Authentication removed that flexibility and standardized on one hour.

If you were hoping to set a 15-minute or 24-hour lifetime, the honest answer is: you can't. What you can control is the refresh token lifecycle (revoking it) and how you treat an expired ID token on your backend.

How Firebase token refresh actually works

You almost never manage this yourself — the SDKs do it for you. Under the hood:

  1. On sign-in, Firebase exchanges the user's credentials for an ID token + refresh token pair.
  2. The ID token is valid for one hour and is what you send to Firebase services (Firestore, Realtime Database, Cloud Storage) or your own backend.
  3. When the ID token is near or past expiry, the SDK POSTs the refresh token to the Secure Token endpoint (securetoken.googleapis.com/v1/token) and gets a brand-new ID token back with expires_in: "3600".
  4. Your app keeps working; the user notices nothing.

Historically the client SDK only refreshed reactively (after a call failed with an expired token); Firebase has since moved toward proactive refresh. Either way, you should treat token refresh as automatic and never hard-code assumptions about the exact refresh moment.

When refresh tokens (and sessions) actually end

The one-hour clock is on the ID token. The refresh token is long-lived and keeps the user signed in indefinitely until one of these happens:

  • The user is deleted or disabled in the Firebase console or Admin SDK.
  • A major account change is detected — for example, a password or email address update.
  • You explicitly revoke the refresh token via the Admin SDK (revokeRefreshTokens(uid)).
  • A password reset occurs (Firebase revokes existing tokens automatically).

After revocation, the user is signed out and must re-authenticate. On the server you can detect this by calling verifyIdToken(idToken, true) (the checkRevoked flag), which costs an extra network round trip, or by wiring up a Security Rules check against a stored revocation timestamp to avoid that cost.

How to inspect Firebase token expiry in your code

You rarely need to, but when debugging it helps to read expiry directly.

Client (JavaScript, getIdTokenResult):

import { getAuth } from "firebase/auth";  const auth = getAuth(); const result = await auth.currentUser.getIdTokenResult(); console.log(result.expirationTime); // ISO string ~1 hour ahead console.log(result.issuedAtTime);

Force a fresh token (does not change the TTL — the new token still lasts one hour):

const freshToken = await auth.currentUser.getIdToken(/* forceRefresh */ true);

Decode the JWT yourself. The exp and iat claims are UNIX timestamps in seconds; exp - iat will equal 3600.

REST refresh call returns the lifetime explicitly:

curl 'https://securetoken.googleapis.com/v1/token?key=[API_KEY]' \   -H 'Content-Type: application/x-www-form-urlencoded' \   --data 'grant_type=refresh_token&refresh_token=[REFRESH_TOKEN]' # -> { "expires_in": "3600", "token_type": "Bearer", "id_token": "...", "refresh_token": "..." }

Firebase Authentication vs Google Cloud Identity Platform

Google Cloud Identity Platform (GCIP) is the enterprise-tier product built on the same backend as Firebase Auth. The token behavior is identical: the refresh endpoint returns expires_in: "3600", meaning ID tokens still last one hour and the TTL is still not exposed for configuration. Upgrading to Identity Platform gets you features like multi-tenancy and SAML/OIDC — but not an adjustable ID-token lifetime.

Common pitfalls and what to do instead

  • Don't persist ID tokens server-side. Their one-hour life makes caching brittle. Have the client send the current token with each request.
  • Don't build logic around "the token refreshes at minute 59." Refresh timing is an implementation detail; call getIdToken() and let the SDK decide.
  • Handle expiry gracefully on custom backends. If you validate tokens yourself (Admin SDK or a third-party RS256 JWT library), return a clear 401 so the client can fetch a fresh token and retry.
  • Need shorter effective sessions? You can't shorten the ID token, but you can revoke refresh tokens to force re-auth, and check revocation on each request.

 

Conclusion

The Firebase Auth short-lived access token — the ID token — expires 1 hour after issuance, a value that is fixed and cannot be configured. That number has been stable for years and is shared by Google Cloud Identity Platform. The takeaway for developers: stop looking for a TTL setting that doesn't exist, and instead lean on the SDK's automatic refresh, treat expired tokens as a normal 401 on your backend, and use refresh-token revocation when you genuinely need to end a session. Next step: skim the Manage User Sessions guide and confirm your backend re-checks token validity on each request.

References