Firebase双令牌作用解析及微服务架构下认证流程疑问

Great question—let’s break this down step by step, since Firebase’s token system can feel confusing at first, especially in microservices setups.

Do you need to generate a Custom Token server-side and exchange it for an ID Token client-side in microservices? #

It depends on your authentication flow, but yes, you’ll need this setup if you’re using a custom or existing user system that isn’t directly integrated with Firebase’s built-in providers (like email/password, Google Sign-In, etc.).

If you’re using Firebase’s native authentication UI/SDK directly, clients can get an ID Token without ever touching a Custom Token—Firebase handles the entire flow for you. But in microservices where you have your own user database or authentication logic (e.g., validating credentials against your backend, or using an enterprise SSO system that Firebase doesn’t natively support), the Custom Token acts as a bridge between your system and Firebase Auth.

Here’s the typical flow in that scenario:

• User submits credentials to your authentication microservice.
• Your service verifies the credentials against your own database.
• If valid, your service uses the Firebase Admin SDK to generate a Custom Token tied to the user’s UID (you can even add custom claims here for authorization).
• The client receives the Custom Token, then uses Firebase’s Client SDK method signInWithCustomToken() to exchange it for an ID Token (and a Refresh Token).
• From there, the client uses the ID Token to authenticate requests to Firebase services (Firestore, Storage) or your other microservices, and Firebase automatically refreshes the ID Token when it expires.

Why do we need both Custom Tokens and ID Tokens? #

These two tokens serve entirely different purposes, designed to split responsibilities between your backend and Firebase’s auth system:

Custom Tokens (Admin SDK-only) #

• Who generates it? Only your trusted backend servers (using the Firebase Admin SDK, which requires service account credentials with elevated permissions).
• Purpose: It’s a "voucher" that tells Firebase: "This user has been authenticated by my system—allow them to access Firebase services." It’s meant to map users from your existing system to Firebase’s user ecosystem.
• Limitations: It’s short-lived (5 minutes max), can’t be used to call Firebase client APIs directly, and isn’t meant for long-term sessions. It’s a one-time use token to bootstrap the client’s Firebase session.

ID Tokens (Client SDK) #

• Who generates it? Firebase’s Auth service, after verifying a valid authentication method (including a Custom Token).
• Purpose: It’s the client’s primary session token. It contains user identity data (UID, email, custom claims) and is valid for 1 hour. The Client SDK automatically refreshes it using a Refresh Token, so users stay logged in without re-authenticating.
• Use cases: Clients send this token in requests to Firebase services (which validate it automatically) or your microservices (which can use the Admin SDK’s verifyIdToken() method to confirm the user’s identity and check custom claims for authorization).

The key separation of concerns #

Custom Tokens let you retain control over user authentication (using your own systems) while still leveraging Firebase’s auth infrastructure for session management. ID Tokens handle the day-to-day session maintenance, so you don’t have to build token refresh logic from scratch—Firebase takes care of that.

For microservices, this is powerful: once a client has an ID Token, all your services can validate it independently (without needing to call your auth service every time) using Firebase’s Admin SDK, which simplifies cross-service authentication.

内容的提问来源于stack exchange，提问作者Kishore Karunakaran