Authentication Emulator Ephemeral/Long Lived ID Tokens

[RafaelZasas]

I have a fairly straightforward stack:
Frontend: Flutter, NextJS
Backend: Go

The core issue I have is working on backend api endpoints/functionality that requires authentication/authorization.

We use Firebase Auth on the frontend, and the firebase admin sdk on the backend to validate ID tokens, and obtain the users auth ID, email verification status and claims.

This works really well when developing the Frontend alongside the backend, since I can use the client to send the ID token along with the request, but it is terrible if I am trying to develop the backend alone.

Our current workaround:

• Spin up frontend (mobile or web)
• Spin up Firebase Emulators
• manually add a console.log or print statement in the authStateChanged listener for the users ID token
• use that token for an hour or so until it expires
• repeat

This works, but it is extremely frustrating.

In an ideal world, I could:

• go to the Firebase Auth Emulator UI
• click on a user account
• get a ID token for that user
• use that ID token when making requests in Postman (or similar)

(NOTE: The above proposal is just an example, but the core point is being able to use Firebase Auth in an application, without constantly fighting to obtain a valid ID token for fake/emulated auth accounts)

It would allow us to easily:

• Test out backend endpoints and functionality that requires authentication or authorization
• Test out permission based features by easily swapping out ID tokens for different user groups

I understand that this is an extremely sensitive area and that security around authentication is of utmost importance.
With that being said, I would like to believe that it is not impossible to do, and that I am not the only person facing the same issue.

If there is work that can be done to make the this a reality, I would love to contribute some time.
Guidance would be much appreciated.

[mgkvibez]

The emulator deliberately deviates from production here: it issues unsigned ID tokens (no real signature) with the same 1-hour expiry shape as production. They're only accepted by other emulators, or by the Admin SDK when FIREBASE_AUTH_EMULATOR_HOST is set on the server side — then verifyIdToken() and createSessionCookie() accept them as-is.

export FIREBASE_AUTH_EMULATOR_HOST="127.0.0.1:9099"

Rules that follow from that:
• Never set that env var in production — it makes the SDK accept unsigned tokens, which defeats verification entirely.
• The Cloud Functions emulator sets it automatically for functions, so function code verifies emulator tokens without extra config.
• There's no "long-lived ID token" in the emulator either — same as production, you refresh with the SDK client, or use createSessionCookie() for longer sessions. If you need a stable identity across emulator restarts, the signed-in user record persists in the emulator's export data (firebase emulators:export), not the token.

So: if you were hoping to mint a token outside the emulator and reuse it — the right move is signing in through the emulator UI or client SDK, and persisting the export instead.