Firebase public-key rotation in a FastAPI backend: test the unavailable-key path

A Firebase token verifier needs an explicit unavailable-key path as well as a valid-token path. Distinguish an ID token from a Firebase custom token or an MCP credential, verify the required claims and signature, and test what happens when a new signing-key ID arrives during a certificate-fetch outage. An unverified subject must never become an application account simply because a key refresh failed.

Use the right token family

The Firebase client SDK obtains ID tokens after sign-in; custom tokens are used to establish a Firebase sign-in and are not interchangeable backend access tokens. Keep MCP authorization credentials on their own issuer and audience path. At the API boundary, choose the verifier from a trusted configuration, not from an arbitrary claim inside an unverified token. Record the expected Firebase project and accepted token type with the endpoint contract.

Firebase's verification documentation lists signature and claim requirements and describes public certificate caching using the response's Cache-Control max-age. Prefer the supported Admin SDK unless a custom verification path has a concrete need. A cached key set helps availability, but a cache entry does not replace signature, issuer, audience, expiry and subject validation.

Firebase: ID-token verification requirements and public keys

Model key discovery and acceptance separately

Use a synthetic local key source with key IDs K1 and K2, not Google's real signing material. Start with K1 cached, then publish K2 and present a fixture token signed by K2. Observe whether the selected verifier refreshes according to its documented behavior. Next make the key endpoint unavailable and present an unknown key ID. The test must distinguish unable to verify from a known invalid signature without accepting either as authenticated identity.

These are proposed cases, not a live Firebase rotation test. If you build a local cryptographic fixture, generate disposable keys and tokens entirely within the harness. Do not copy customer ID tokens into a repository. Keep the verifier package version, cache policy, synthetic clock and redacted failure category with the output. A fake key ID alone tests lookup behavior; it does not test signature verification unless the fixture also creates and checks signatures.

Outage handling needs a written policy

Decide which verified cached keys can remain usable under the documented cache and outage policy, how unknown keys fail, and when the API reports temporary verification unavailability. Never turn a network exception into a permissive decode. Also avoid reporting every unavailable-key request as wrong password: the user may already be signed in, while the backend cannot currently establish trust in the presented token.

Synthetic trace fields
expected_project: fixture-project
presented_kid: K2
cache_generation: K1-only
refresh_attempt: failed
signature_verified: false
identity_resolution: not started
public_result: authentication unavailable or rejected by policy

Coordinate refresh work so a burst of unknown keys cannot create an unbounded fetch storm. Use a bounded timeout and concurrency policy appropriate to the verifier library rather than adding independent retry loops at every middleware layer. Measure any recovery behavior in the isolated fixture before describing it as supported. Keep key URLs fixed to trusted configuration; a token-provided URL should not become a new arbitrary network destination.

Resolve the product account after verification

Once the signature and claims pass, map the verified subject to the internal account through the application's identity contract. A failed profile lookup is different from a failed token signature. Return a recoverable unlinked or unavailable-account state where appropriate, and keep the distinction in operator logs without exposing raw token contents. Membership and record authorization still happen after account resolution.

Before release, run current-key, rotated-key, unknown-key, wrong-audience, wrong-issuer and expired-token cases through the actual endpoint. Include a certificate outage and restored service. This article does not assess a private deployment's security; it defines a bounded negative-test worksheet. The evidence needed for a compatibility statement is the observed verifier behavior on the pinned release, not the presence of a function named verify.

MCP server authentication: trace the identity all the way to the record

Building UltraFit360: the app, coach portal and shared backend

Bring one API or data workflow and a sanitized failure example for a bounded implementation assessment.

AptixLabs saas development