7 Key Steps to Secure Your MCP Server with Firebase Authentication

Model Context Protocol (MCP) servers empower AI assistants to access real user data. Without proper authentication, that power becomes a liability—the difference between a valuable tool and a catastrophic data breach. This guide distills how Can Tax Pro locks down its Python MCP server using Firebase Authentication. We'll walk through the two-token architecture, step-by-step implementation, and production best practices that keep user data safe while enabling seamless integration with clients like Claude.ai.

1. Why Authentication Is Non-Negotiable for MCP Servers

Think of authentication as the bouncer at an exclusive club—only verified guests get in. Without it, any AI assistant—or attacker—could query sensitive financial data, modify records, or exfiltrate personal information. For MCP servers that handle real user data, auth isn't optional; it's the core security layer. This approach uses two token types: Firebase ID tokens for direct access and custom OAuth tokens for third-party clients like Claude.ai. Both are verified at every request, ensuring only authorized users and apps can interact with the server. By investing in robust authentication upfront, you prevent costly breaches and build trust with users who expect their data to remain private.

2. Understanding the Two-Token Architecture

The system juggles two token flavors to balance security and flexibility. Firebase ID tokens are cryptographically signed by Firebase Auth—they're ideal for direct browser-to-server calls, where the user signs in via FirebaseUI or similar. Custom OAuth tokens (prefixed ctpo_) are issued by the web app's own OAuth authorization server for third-party integrations. Each token carries a user ID, and the MCP server resolves it to isolate data per user in Firestore. This dual-token approach provides a clean separation: one for first-party use, another for delegated access. As Step 4 explains, Firebase ID tokens are verified via the Admin SDK, while Step 5 details how custom hashed tokens are stored and validated.

3. Initializing Firebase Admin SDK Correctly

Bootstrapping Firebase Admin is straightforward but environment-aware. In development, you load the service account JSON from an environment variable (FIREBASE_SERVICE_ACCOUNT). On Google Cloud Run, you omit it entirely—the SDK automatically picks up Application Default Credentials via Workload Identity. This means zero secrets in production. The initialization code checks for existing apps to avoid re-initialization, then uses either explicit credentials or default ADC. The key requirement: your Cloud Run service account must have the Firebase Admin SDK Administrator Service Agent IAM role. This setup ensures the server can verify tokens and access Firestore without hardcoded keys, a critical best practice for production systems.

4. Handling Firebase ID Tokens Securely

Firebase ID tokens are JSON Web Tokens (JWTs) issued by Firebase Authentication. The Admin SDK's verify_id_token() method does all the heavy lifting—it checks the signature, expiration, and audience. Once verified, you extract the uid (user ID) for data isolation. This process is both fast and cryptographically strong. However, you must never trust the token without verification. In production, implement a middleware or decorator that calls this on every protected endpoint. If verification fails, return a 401 Unauthorized. Since these tokens typically expire after one hour, your client should refresh them via Firebase Auth's refresh token flow. This approach is ideal for web apps where the user is already authenticated with Firebase.

5. Managing Custom OAuth Tokens with Hashing

For third-party clients (like Claude.ai) that can't directly integrate Firebase Auth, you issue custom OAuth tokens. These tokens are never stored in plaintext. Upon creation, the server hashes the token with SHA-256 and stores only the hash in Firestore, along with user ID, expiration, and refresh token metadata. When the MCP server receives a custom token, it hashes the incoming value and looks up the hash. If the document exists and hasn't expired, the user is authenticated. This means even if the Firestore database is compromised, an attacker can't recover the original tokens. Revocation is instant—delete the Firestore document and the token becomes invalid on the next request. This design balances security with the need for externally integrated AI assistants.

6. Immediate Token Revocation via Firestore

One of the biggest advantages of the custom OAuth token approach is instant revocation. Since every request checks the token hash against a Firestore document, removing that document immediately invalidates the token. There's no need to wait for TTL expiration or maintain a blacklist. All it takes is a simple doc.delete() call from your admin interface. This is especially powerful for handling compromised tokens or revoking access when a user disconnects an integration. For Firebase ID tokens, revocation relies on Firebase's built-in mechanisms (like disabling the user or calling revokeRefreshTokens). Combining both methods gives you fine-grained control over access. For best security, monitor token usage logs and implement automatic revocation for suspicious activity.

7. Seamless Deployment on Cloud Run

Deploying your secured MCP server on Google Cloud Run maximizes simplicity and security. With Workload Identity, your Cloud Run service account automatically inherits the IAM roles needed to call Firebase Admin and access Firestore. This eliminates the need to store or rotate service account keys—a huge win for operational security. Just set the FIREBASE_PROJECT_ID environment variable and ensure the service account has the required IAM role. The server container is stateless, so you can scale to zero and handle bursts seamlessly. For local development, the same code works with the service account JSON. This unified deployment strategy reduces friction while enforcing best practices. Follow this path, and you'll have a production-ready, authenticated MCP server that both first-party and third-party clients can trust.

Conclusion
Securing your MCP server with Firebase Authentication doesn't have to be complex. By adopting a two-token architecture—Firebase ID tokens for direct access, custom hashed tokens for third-party clients—you create a robust defense against unauthorized data access. Each step, from careful SDK initialization to instant token revocation, builds a security posture that scales with your user base. The result: your AI assistant integrations remain powerful yet locked down. Whether you're building for a tax platform or any data-sensitive application, these seven strategies will keep you on the right path. Start implementing them today and sleep better knowing your users' data is protected.