Firebase Authentication: Verify Identity Before Applying Resource Rules

A custom backend should derive identity from a verified Firebase ID token, then apply its own resource authorization rules. A user identifier sent in a request body is not proof that the caller owns that account or its records.

Firebase's ID-token verification guide describes verifying token format, signature and expiry through the Admin SDK. It also distinguishes ordinary verification from checking revocation. Your session policy should make that distinction explicit.

Draw the identity handoff

Identify where the client obtains its token, how it sends the token to the backend and which verified identifier the backend uses. Keep transport secure and avoid logging the raw token.

Then identify any application-specific account record associated with that identity. Mapping an external identity to a workspace or profile is a separate data relationship that can fail or change.

Do not let a convenient client field override the verified account context.

Separate account identity from record ownership

A signed-in person may have several profiles, projects or save files. Permission to sign in does not automatically grant access to every identifier supplied in a request.

Stardew Valley Tracker describes tracking several save files and is declared in the Firebase collection. Its listing does not disclose the authentication implementation. The category nevertheless illustrates why profile ownership needs a clear rule.

For an application you control, verify the caller's relationship to the specific record before reading or changing it.

Define session changes deliberately

Decide what sign-out, account disablement and credential revocation mean for the backend. Some operations may require fresher or stronger verification than an ordinary read.

Use the provider's documented mechanisms for the chosen policy. Do not assume that every token becomes invalid everywhere at the moment a client screen changes.

Keep the user-facing correction understandable: sign in again, select an accessible profile or contact support. An opaque error should not encourage repeated guessing with credentials.

Test account switching

Create two synthetic accounts and distinct records in an isolated environment. Sign in as one, open a record, then switch to the other and attempt the relevant application action.

Confirm that cached interface state does not become backend authority. Also test a request with an expired or malformed token and a valid token paired with another account's record identifier.

The expected results should be explicit denials or authorized responses, not accidental differences caused by which screen was open.

Keep diagnostic evidence safe

Log operation references and failure categories without copying tokens, private profile contents or unnecessary personal data. Give operators enough context to distinguish authentication failure from ownership failure.

Review the actual production configuration separately from local tests. Project identifiers and allowed token audiences must match the intended environment.

The companion Firebase Emulator Suite guide explains how to exercise these cases without touching production records. Together, the tests establish who the caller is, what the caller may do and where the evidence was collected.

Maintain this fixture set when login providers, account-linking behavior or backend middleware change. Those changes can alter identity mapping even when the visible sign-in button remains the same.