Firestore Security Rules: Enforcing a Revocation Boundary for Revoked Sessions

Goal

Enforce least-privilege in Firestore Security Rules so a revoked session — say, after a password reset handled with the Admin SDK's refresh-token revocation — stops authorizing reads and writes immediately instead of up to an hour later.

Constraints

• ID tokens are short-lived JWTs that the client SDKs refresh automatically; a token generally stays valid until its exp claim even after refresh tokens are revoked.
• Rules have no built-in revocation check; the usual workaround is a custom claim such as a token version, but claims only reach the token on the next refresh, leaving a propagation window where stale privileges still authorize access.
• Token persistence differs between the Web SDK and the native iOS and Android SDKs, so refresh timing is not uniform across platforms.

Open points

Assuming a recent firebase-admin release (v6 or later, to be verified against current documentation) and the modular Web SDK, it is unclear whether request.auth.token exposes standard claims such as auth_time reliably enough to compare against a per-user revocation timestamp, and whether the Emulator Suite reproduces production revocation timing.

• Is there a supported Rules-only pattern to reject tokens issued before a revocation timestamp without adding a per-request lookup?
• What is the practical upper bound on custom-claims propagation, and does a forced client-side token refresh close the gap consistently across Web and native?