Notifications
Clear all
Topic starter
15/08/2026 6:45 pm
TL;DR: A native in-app login flow can mint a Firebase custom token and sign users in without building a separate auth backend, while preserving existing Firestore rules and extending to Realtime Database, Storage, and Functions, according to Descope’s Android guide. The identity pattern matters because it shifts authentication plumbing out of the app and into a token exchange that IAM teams still have to govern.
NHIMG editorial — based on content published by Descope: How to Add External Tokens to Your Android + Firebase App
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read Descope's guide to adding external tokens to Android and Firebase auth →
Android external tokens and Firebase auth: what changes for IAM teams?
Explore further
15/08/2026 6:45 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: External tokens for Firebase auth reduce Android auth backend sprawl
