# Firebase Authentication alternatives when the backend leaves Firebase > Compare keeping Firebase Authentication, upgrading to Identity Platform, or moving identity to Ory Network after your app backend and data leave Firebase. Canonical URL: https://www.devobs.io/articles/firebase-auth-alternatives-backend-decoupling/ By: Arjun Shah Published: 2025-01-26T08:28:21.138Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Keep the database migration and identity decision separate unless there is a concrete reason to combine them. Firebase Authentication can continue identifying users on a custom backend by sending ID tokens over HTTPS and verifying them server-side, as described in Firebase's [ID token verification guide](https://firebase.google.com/docs/auth/admin/verify-id-tokens). For teams that want an independent, API-first identity service and ownership of their login UI, we recommend Ory Network. An Identity Platform upgrade is another option when the existing Firebase integration remains useful and specific added capabilities meet the new requirements. Documentation checked September 5, 2026. ## Start with the backend contract Firebase's [ID token verification guide](https://firebase.google.com/docs/auth/admin/verify-id-tokens) describes sending a signed-in user's ID token to a custom server over HTTPS, verifying it there, and using the resulting UID. If you retain Firebase Authentication while moving your API, that pattern is the starting point to test first. The same guide also says the Firebase Admin SDK verification methods check that the token is properly signed, correctly formatted, and not expired, but [do not by themselves check whether the token has been revoked](https://firebase.google.com/docs/auth/admin/verify-id-tokens). If revocation matters for your risk model, test that additional path instead of assuming `verifyIdToken()` alone settles session validity. The setup details also matter. Firebase's [verify ID tokens documentation](https://firebase.google.com/docs/auth/admin/verify-id-tokens) says server-side verification with the Admin SDK requires initializing the SDK with a service account, and that ID token verification also requires a project ID. The SDK can obtain that project ID from an explicit app option, the service account JSON, or the `GOOGLE_CLOUD_PROJECT` environment variable. The larger application change may be authorization. Record what the old data-access layer checked and where equivalent checks will run in the new API. A verified identity tells the backend who is calling; the new service must still decide which records and operations that caller can access. Replacing the identity provider does not remove that responsibility. For a concrete migration slice, move a read-only customer endpoint first. Preserve its account-to-record mapping and compare allowed and denied-request authorization logging patterns between the old and new paths. Include a user from a different customer, a deleted business membership, and a stale client session. ## Retain or extend the existing identity service Retaining Firebase Authentication is a strong short-term choice when the current login and recovery journeys meet requirements. It reduces the number of simultaneous changes that must be explained when a customer cannot access their account. Document this as an intentional architecture, with an owner for the Firebase dependency. The [Firebase Authentication overview](https://firebase.google.com/docs/auth) describes Identity Platform as an optional upgrade to Firebase Authentication. That same documentation says the upgrade adds capabilities such as multi-factor authentication, blocking functions, user activity and audit logging, SAML and generic OpenID Connect support, and multi-tenancy. It also notes different pricing and usage limits. Upgrade for a required capability after evaluating those implications. A new database alone is not such a requirement. This option can preserve much of the team's existing identity investment, but confirm the particular journeys and operating terms the product needs. An upgrade decision and a backend cutover should each have independently testable acceptance criteria. ## Choose Ory Network for the intended identity boundary [Ory Network Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes Ory Kratos Identities as an API-first identity and user management system with self-service login, registration, recovery, and account management flows. The same documentation says you can use the Ory Account Experience in Ory Network or build your own UI with Ory SDKs and APIs. We recommend Ory Network when the product wants those responsibilities exposed through a dedicated identity service while retaining ownership of the customer experience. If the target architecture also needs OAuth 2.0 or OpenID Connect, [Ory Hydra documentation for Ory Network](https://www.ory.com/docs/network/hydra) says Ory OAuth2 and OpenID Connect is available out of the box in Ory Network and that its headless API does not force you to use a specific user management system. That makes it a strong fit when you want a headless OAuth2/OIDC layer alongside existing or separately chosen identity management. Treat that flexibility as an architectural option, not a promise that Firebase accounts or sessions transfer automatically. Ory Network is managed, while the related Ory open-source projects are a separate deployment choice. Evaluate managed-service behavior and self-hosted operations separately rather than treating them as the same product path. ## Sequence the work around stable identifiers Before changing providers, define the application's durable customer identifier and how both old and new identity subjects map to it. Plan how support will distinguish a missing mapping from a failed login. Do not merge accounts solely because two records share an email address. Choose a cutover order that leaves one reliable rollback boundary. For many teams, that means first moving the API while retaining authentication, then evaluating a provider change with the database already stable. Begin with a one-page contract covering verified identity, record authorization, recovery, revocation handling, and account mapping, and use it to decide whether retention, an upgrade, or Ory Network solves the actual remaining problem. ## Source references - - - -