External tokens for Firebase auth reduce Android auth backend sprawl

At a glance

What this is: This is a walkthrough for adding external tokens to an Android app so Descope can authenticate users and hand Firebase a custom token, keeping existing Firebase authorization in place.

Why it matters: It matters because external token exchanges change where trust is established, which means IAM teams must govern token issuance, service account handling, and session boundaries across mobile and backend identity flows.

👉 Read Descope's guide to adding external tokens to Android and Firebase auth

Context

External token exchange is a pattern for letting one identity system complete authentication and then hand another platform a short-lived token that it accepts as proof of identity. In this Android and Firebase setup, the practical identity problem is not user login itself, but how much backend authentication logic teams are willing to own and secure.

For IAM and application security teams, the real governance question is whether moving sign-in into a native flow reduces friction without creating new secret-handling and token-lifecycle risks. The article is about human user authentication in a mobile app, but the control points still sit inside broader identity lifecycle and federation design.

The article is a hands-on implementation guide, so the important part is the mechanics of the token handoff, not the vendor branding around it. That makes it most relevant to teams comparing hosted authentication, mobile SDK integration, and Firebase-backed authorization models.

Key questions

Q: How should teams govern external token exchange in mobile apps?

A: Treat external token exchange as a federation pattern with its own trust boundary. Define who can mint tokens, how long they live, where they can be stored, and which downstream services accept them. Then validate that authorization remains consistent when the same identity is used across Auth, data stores, and backend functions.

Q: What breaks when a mobile app depends on a privileged service account to mint backend tokens?

A: If that service account is exposed, an attacker can mint valid sessions without using the intended user journey. The app may still look normal, but the trust chain is broken at the signing step. That is why the signing credential must be governed as a high-value non-human identity.

Q: How do IAM teams know whether Firebase custom token use is expanding blast radius?

A: Check whether one authenticated session unlocks several Firebase services with the same trust decision. If Firestore, Storage, Realtime Database, and callable functions all accept the session, the blast radius is broader than the login screen suggests. Scope review has to include downstream service access, not just authentication success.

Q: Should organisations prefer native passkey flows over browser-based sign-in for mobile apps?

A: Native flows can improve usability and reduce browser friction, but they do not remove identity governance responsibilities. The decision should hinge on whether the organisation can secure token issuance, protect client callbacks, and govern the service account that bridges the two systems. Usability gains are only acceptable when control ownership is clear.

Technical breakdown

How the external token handoff works in Firebase auth

The integration uses a token connector to mint a Firebase custom token after the primary login flow completes. Descope authenticates the user, then returns an externalToken value that the Android app passes into signInWithCustomToken(). Firebase treats that token as the basis for an authenticated session, so the user identity becomes available to downstream rules and services without the app building its own auth backend. The key architectural point is that identity proof is exchanged once and then consumed by Firebase as an ordinary Auth session.

Practical implication: teams must treat the token minting step as part of the trust boundary, not as a UI convenience.

Why the Firebase service account becomes a high-value secret

The connector requires Firebase service account JSON so it can mint custom tokens on the app’s behalf. That secret is not a runtime user credential, but it is still a privileged signing capability, which means compromise of the JSON file would let an attacker create valid Firebase tokens outside the intended flow. In identity terms, the service account is a non-human identity with broad authority, and it must be governed like production access rather than treated as build-time configuration.

Practical implication: isolate the service account, restrict its use to token minting, and review where its JSON ever appears in tooling or storage.

What native passkey flows change on Android

The guide uses Descope Native Flows and Android Credential Manager so passkeys and social login appear as system prompts inside the app. That reduces browser bounce, but it also means the authentication flow is embedded more deeply into the mobile runtime. From a governance perspective, the app is no longer just a consumer of a remote login page. It participates directly in rendering, callback handling, session management, and token transfer, which makes client-side integrity part of the identity control surface.

Practical implication: protect the mobile client as an identity endpoint and review callback handling, token storage, and app integrity controls together.

Threat narrative

Attacker objective: The attacker’s objective is to mint trusted Firebase sessions and move laterally into protected application data and backend functions without using the legitimate mobile authentication experience.

1. Entry would occur through compromise of the Firebase service account JSON or another privileged token-minting secret used by the connector.
2. Escalation would come from the attacker using that secret to generate valid Firebase custom tokens and obtain authenticated sessions without the intended user flow.
3. Impact would be unauthorized access to Firebase-protected data and services that trust those sessions, including Firestore, Storage, Realtime Database, and callable functions.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

External token exchange is a federation pattern, not a simplification pattern: the app still depends on a privileged non-human identity to mint trust for Firebase. That makes the security boundary more explicit, but it does not make the boundary smaller. Practitioners should read this as a shift in control placement, not a removal of control responsibility.

Service account JSON is the real control plane in this design: the mobile app never signs Firebase tokens itself, so the connector’s credential becomes the authority that matters. This is classic NHI governance, because the question is not who logs in, but which secret can assert identity into another system. The practitioner conclusion is straightforward: if the secret is exposed, the trust chain collapses.

Native mobile authentication moves identity risk into the client runtime: once passkeys, social login, and OTP are rendered in-app, the mobile application becomes part of the identity assurance surface. That means callback integrity, token handling, and session management deserve the same scrutiny as backend authorization rules. The conclusion for teams is that mobile auth architecture and identity governance can no longer be separated cleanly.

Firebase custom tokens create a portability layer that can hide governance debt: the same token can unlock multiple Firebase services, so one success path can create broad downstream access. That is useful for user experience, but it also means entitlement scope is easy to underestimate if teams focus only on the login moment. Practitioners should govern the downstream blast radius, not just the sign-in screen.

What this signals

External token bridges can make authentication feel simpler while making governance more distributed. The more a mobile app depends on short-lived token exchange, the more important it becomes to separate user experience from authority. Teams should expect the identity programme to span mobile runtime integrity, connector secret management, and downstream authorization review rather than a single login control.

Service account governance is the hidden differentiator in these architectures. If the credential that mints tokens is not treated as a production NHI, the integration inherits a silent single point of failure. Practitioners should watch for secret sprawl across CI/CD, support tooling, and console exports because that is where token-bridging architectures usually drift.

Downstream session scope is the named concept to track here: token portability. Once one signed assertion unlocks multiple Firebase services, the practical question becomes how far that trust can travel before it exceeds the original business need. For identity teams, the next programme step is to review which platforms accept the same session and whether that scope still matches the application’s intended boundaries.

For practitioners

• Map the token minting trust boundary Document where the Firebase custom token is created, which service account signs it, and which systems accept it after issuance. Treat that path as a production identity dependency, not an app implementation detail.
• Harden the service account credential Store the Firebase service account JSON in tightly controlled secret storage, limit who can retrieve it, and verify that it is never embedded in source code, build logs, or mobile artifacts.
• Review downstream Firebase entitlements Check which Firebase products trust the same signInWithCustomToken() session and confirm that Firestore, Storage, Realtime Database, and functions all reflect the minimum required scope.
• Test client-side identity failure paths Validate what happens when externalToken is missing, expired, replayed, or intercepted, and confirm the app fails closed rather than silently falling back to weaker auth behavior.
• Separate user experience from identity assurance Use native passkey and social login flows for usability, but keep session issuance, token lifetime, and revocation review tied to the identity programme rather than the UI team.

Key takeaways

• External token exchange shifts trust into a signing and federation boundary that identity teams must govern explicitly.
• The Firebase service account is a privileged non-human identity, so its protection matters as much as the Android login experience.
• Native mobile auth improves user flow, but downstream Firebase blast radius and token lifecycle still determine the real security posture.

Key terms

• External Token Exchange: An external token exchange is a federation pattern where one system authenticates a user and then issues a token that another system accepts as proof of identity. The security burden shifts to token issuance, claim mapping, expiry, and the trust relationship between issuer and relying party.
• Firebase Custom Token: A signed assertion that lets Firebase create an authenticated session for a user or service account. It is useful for federation and app integration, but it also concentrates authority in the signing identity, so lifecycle control, credential protection, and session scope all become governance concerns.
• Token Connector: A component that transforms one completed authentication event into a token accepted by another platform. It simplifies integration, but it also creates a privileged bridge that must be secured, monitored, and treated as part of the identity control plane rather than as a simple configuration toggle.
• Native Authentication Flow: An in-app login experience rendered inside the mobile application instead of bouncing the user through a browser page. It improves usability and can support passkeys and social login, but it also means the app runtime becomes part of the identity assurance surface and must be controlled accordingly.

What's in the full article

Descope's full post covers the operational detail this post intentionally leaves for the source:

• Exact Kotlin implementation steps for wiring the DescopeFlowView into an Android activity
• Firebase console configuration details for creating and pasting the service account JSON into the token connector
• Gradle and google-services setup needed for automatic Firebase initialization on Android
• The full flow handling pattern for storing and refreshing the externalToken in the app runtime

👉 Descope's full post shows the complete Kotlin flow, connector setup, and Firebase session handoff.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.