Which open-source option replaces Firebase Authentication?
If your Firebase Authentication deployment is under renewal, residency or lock-in pressure, the short answer is that Supabase Auth and Appwrite's auth cover app sign-in bundled with a database, while ZITADEL fits enterprise SAML and OIDC federation. All three run self-hosted in your own infrastructure. The reason this matters is that Firebase Authentication processes data only in the United States, so a residency requirement can't be met by changing Firestore locations alone. Moving identity to a self-hosted platform lets you choose the region and keep user records next to the rest of your data.
Choose by the job, not the brand. Supabase Auth is built around Postgres, so users live in the auth.users table next to your application data and row level security policies can reference them. Appwrite's auth sits inside a stack that also covers databases, storage and functions, which suits teams replacing the whole Firebase product set. ZITADEL is the stronger fit when you need instances, organizations, SCIM v2 provisioning and a different identity provider per customer. Before you commit, confirm which social providers, multi-factor methods and session behavior your apps need, because these differ between the three and between their hosted and self-hosted editions.
How Firebase Authentication capabilities map to open-source options
This table compares Firebase Authentication features with Supabase Auth, Appwrite Auth and ZITADEL. Cells marked as confirm point to items the vendor documentation must settle for your version before you commit. Read the table against your own sign-in flows, and treat ZITADEL as the stronger fit where SAML, SCIM and per-customer identity providers are central.
| Capability | Supabase Auth | Appwrite Auth | ZITADEL |
|---|---|---|---|
| Email and password | Included in the self-hosted Auth service. Confirm scrypt hash import for Firebase users. | Built in. Users API accepts imported Scrypt modified hashes, so existing passwords can carry over. | Built in, with passwords usable alongside passkeys. Firebase migration guide covers the import path. |
| Social providers | Configured per provider in self-hosted settings. Confirm provider list and redirect URLs. | Configured in the Console. Confirm which Firebase OAuth links must be re-established after import. | Federates Google, GitHub, GitLab, Apple, Entra ID and Okta over OIDC or SAML. |
| Anonymous and phone sign-in | Confirm anonymous and phone (SMS or OTP) support and provider costs in Supabase Auth docs. | Confirm anonymous sessions and phone provider setup in Appwrite Auth docs. | Confirm phone and anonymous flows in ZITADEL login documentation for your version. |
| Custom claims and roles | Claims travel in JWTs signed with your project key pair. Confirm how custom claims are added. | Roles and labels on users. Confirm how they map into permissions your app checks. | Projects group applications, roles and grants inside an organization. Claims come from grants. |
| Session tokens | Issues JWTs signed with keys from the self-hosting secret generation scripts. Confirm token lifetimes. | Session and API key model differs from Firebase ID tokens. Confirm token lifetime settings. | Implements OpenID Connect and OAuth 2.0 tokens. Confirm lifetimes in your instance settings. |
| Multi-factor and passkeys | Confirm MFA and passkey support in the Auth version your Docker release pins. | Confirm MFA and passkey options in the Auth reference for your Appwrite version. | Passkeys based on FIDO2 and WebAuthn, with fallback to password login. |
| SAML and SCIM for enterprise sign-in | Confirm SAML SSO and SCIM availability in self-hosted Auth before planning enterprise tenants. | Confirm SAML and SCIM support in Appwrite docs before promising enterprise onboarding. | SAML 2.0 and a SCIM v2 provisioning interface, with a separate identity provider per organization. |
| Admin user management | Studio manages users in a single project. Multi-project admin is not available when self-hosting. | Console manages users and sessions. Confirm bulk operations and audit output for your needs. | Instances, organizations and projects isolate tenants. Admin tasks run through the console and APIs. |
| Operating boundary | Self-hosted Supabase is community-supported. Plan internal ownership of upgrades and incidents. | Helm datastores run a single replica without failover. Use managed or operator-run databases for production. | Recommends a Kubernetes cluster with the official Helm chart for high availability. Database versions 14 to 18. |
When Supabase Auth, Appwrite Auth or ZITADEL fits best
Each option below can replace Firebase Authentication, but they fit different shapes of team. The right choice depends on whether auth sits inside a wider backend you also want to replace, or whether it must serve enterprise sign-in across many customer organizations. Check licensing, database and operating model before committing to a migration path.
Supabase Auth for Postgres-first apps
Supabase Auth (GoTrue) fits teams that already plan to move data into Postgres and want row level security to read the same user identity. Self-hosted Supabase is Apache-2.0 and runs as a Docker Compose stack, with Auth pinned to a specific upstream version in each configuration release. Check that your user migration keeps the Firebase scrypt parameters working, and confirm which social providers you need to re-link. Self-hosted Supabase is community-supported, so plan your own on-call and patching.
Appwrite Auth for a full Firebase-style backend
Appwrite Auth fits teams replacing Firebase Authentication along with Firestore, Storage and Functions, since Appwrite covers those services in one product. Appwrite is BSD-3-Clause and provisions PostgreSQL by default for new installs, with MariaDB and MongoDB also supported. Its Users API accepts several imported hash formats, which helps when moving users without forced resets. The trade-off is that the built-in datastores run a single replica without failover, so production data needs managed services or operators.
ZITADEL for enterprise and multi-tenant sign-in
ZITADEL fits when auth is the main requirement, especially for B2B products where each customer organization brings its own identity provider. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, SCIM v2 provisioning and passkeys, and it uses PostgreSQL with versions 14 through 18 supported. The core, Console and hosted login are AGPL-3.0 since v3.0, while APIs, SDKs and Helm charts remain Apache 2.0. Ask legal whether AGPL terms work for your deployment, and confirm how Firebase password hashes are handled, since ZITADEL uses just-in-time migration.
Choosing on license and lock-in
Supabase and Appwrite use permissive licenses, while ZITADEL's core is AGPL-3.0. If your legal team treats network-copyleft terms as a blocker for internal or customer-facing deployments, that alone can shape the shortlist. Check the license of every component you will ship, including any Helm charts and Terraform configurations, before you write migration code against an API.
Operating and patching the auth stack
Every option means your team owns upgrades, secrets, database backups and high availability. Supabase's Docker releases can include one-way database migrations that require a backup first, and ZITADEL recommends Kubernetes with the official Helm chart for high availability. Before choosing, ask who will apply security releases, how you will test an upgrade against a copy of your user table and what your recovery point objective for sign-in is.
How password hashes move without forcing resets
Firebase Authentication stores password hashes using a modified scrypt algorithm by default. The Firebase CLI can export user records along with the hash algorithm and its parameters, which is the material a receiving system needs to verify an existing password without asking the user to change it. Export is a privileged operation, so the account running it needs project-level access, and the export file itself contains credential material that must be stored and deleted under your own data handling rules.
- Hash algorithm and parameters: Confirm that the export includes the signer key, salt separator, rounds and memory cost for the project, since these values are needed to verify any password later.
- Users without passwords: Social sign-in and phone-only accounts carry no password hash, so they must be re-linked rather than migrated as credentials.
- Export file handling: Restrict access to the export, encrypt it at rest and remove it after the import is verified.
- Project parameters: Parameters are tied to the Firebase project, so record them with the export rather than relying on values recalled later.
- Dry run: Import a sample of accounts into a staging environment and sign in with known test passwords before touching production data.
Before cutover, confirm the exported parameters against the project in the Firebase console and the Firebase CLI auth reference, and keep the export with the migration record.
Appwrite's Users API accepts imported password hashes in several formats, including Scrypt modified, bcrypt, Argon2, MD5, PHPass, Scrypt and SHA. Accepting a format means the server can verify the original password on first sign-in and then rehash it with the target settings. The practical question for a Firebase migration is whether the Scrypt modified parameters from the export map onto the fields the API expects, which should be checked with a test account rather than assumed.
- Supported formats: Use the Scrypt modified option for Firebase hashes and pass the salt, salt separator and signer key exactly as exported.
- Create versus update: Imported users are created through the Users API, so plan whether accounts are pre-created before users return or created on first login.
- Identifiers: Keep user IDs stable so that application data, roles and sessions still reference the correct accounts.
- Error handling: Log each failed import with a reason code and retry only after the cause is fixed, so no account is silently skipped.
- Verification: Sign in with a set of known test users on each supported method, including accounts that were created with social providers.
Confirm the accepted fields and format names in the Appwrite Users API reference and test them against a self-hosted instance, since the self-hosted version you run is the one that matters.
Supabase's documented Firebase path imports Auth users into the auth.users table with the project's scrypt parameters, so the password hashes and their settings travel with each record. ZITADEL takes a different route: its migration guides describe approaches such as just-in-time migration, where a user's credentials are checked against the old system at first sign-in and then stored in ZITADEL. That approach avoids a bulk hash import but depends on the old system remaining reachable during the transition window.
- Supabase import: Map exported fields to auth.users and confirm that the stored scrypt parameters match the Firebase export before loading production data.
- ZITADEL just-in-time: Keep the source authentication endpoint available until every active user has signed in, and plan how dormant accounts are handled.
- Transition period: Decide how long dual operation lasts and who monitors failed logins during it.
- Social accounts: Re-link Google, Apple and other providers separately from password hashes, since they do not use them.
- Failure modes: Test what happens when a user signs in after the legacy system is switched off.
For ZITADEL, read the ZITADEL migration guides and confirm which source versions and Firebase export formats the guide covers before committing to the approach.
Hash moves fail quietly. An account can import without error and still reject a correct password if one parameter is wrong, which users discover only at login. Testing therefore needs a representative set of accounts covering each hash format, each sign-in method and each account state, run on the same self-hosted version you will operate. The migration should also have a rollback position, so a failed batch can be reverted without losing the source data.
- Representative test set: Include old accounts, recently changed passwords, accounts with social links and accounts with unusual characters in passwords.
- Parameter checks: Compare a hash generated by the source system against the imported record and confirm a successful verification in the target.
- Rollback plan: Keep the export and source project intact until users have signed in successfully in the new system.
- Monitoring: Track failed sign-ins by reason during the first days after cutover and assign an owner to review them.
- Security review: Have the security team confirm where exported credential material is stored and when it is destroyed.
Engage your auditors or security reviewers early if the migration touches regulated data, and confirm every parameter in your own environment before cutover, since no vendor test substitutes for it.
Moving users, social logins and sessions off Firebase
This sequence moves user accounts, password hashes and social sign-in links from Firebase Authentication to the new identity service, with sessions handled through a parallel login window so users are not locked out at cutover.
Inventory providers and user counts
The application owner and the identity lead list every sign-in method enabled in the Firebase project: email and password, Google, Apple, other OAuth providers, phone, anonymous and any custom tokens. For each method they record the number of users, whether those users also have a password hash, and which client apps and backend services depend on Firebase ID tokens. Done means the team has a written table of methods, counts and dependent services, and has confirmed the list against the Firebase console rather than memory.
Export users and password hashes
An engineer with project owner or equivalent rights runs the Firebase CLI export for Auth users, which writes the user records and, for email and password accounts, the hashes together with the project's modified scrypt parameters. The export file is stored encrypted in a restricted location, and the team checks record counts against the inventory. Done means the export file exists, the counts match, and the parameters are saved alongside it, because the target cannot verify hashes without them.
Import users into the target identity service
The identity engineer loads the export into the target: Supabase Auth through its documented Firebase path, Appwrite through its Users API import with the Scrypt modified hash type, or ZITADEL through its Firebase migration guide or just-in-time approach. The team runs the import against a staging instance first and confirms the target version of the migration tooling in the current docs before using it. Done means a staging test login succeeds with an imported email and password account without a forced reset, and failed records are logged and explained.
Re-link Google, Apple and other social providers
The identity engineer configures each social provider in the target with its own client ID and redirect URI, then maps provider-specific identifiers to the imported accounts. Firebase user IDs do not carry over as provider subject IDs, so matching usually relies on verified email addresses and must be tested for accounts where the email changed or where a user signed in with more than one provider. Done means each provider completes a test sign-in that lands on the correct existing account, and unmatched or duplicate accounts are listed for a manual decision.
Test OAuth sessions and provider identifiers
The QA lead runs a scripted test matrix covering password logins, each social provider, password reset, email verification, token refresh and sign-out on web and mobile clients. The matrix also checks that any backend that validates Firebase ID tokens is either switched to the new issuer or temporarily accepts both. Done means every test case has a recorded result and an owner for each failure, and the team has confirmed which Firebase sessions remain valid after cutover.
Plan the token and session cutover
The platform lead agrees with the application owner when clients switch their SDK configuration to the new identity service, how long existing Firebase refresh tokens are honored, and how users who are signed in during the change are prompted to sign in again. Client release timing, mobile app store review and any custom token minting code are included in the plan. Done means a written runbook lists the switch steps, the rollback path and the named person who approves each step.
Run the parallel login window
For an agreed period, clients accept sign-ins from both Firebase and the new identity service, and the team monitors failed logins, duplicate account creation and password reset failures. New sign-ups go only to the target once the window opens, and support staff use a checklist for users who report being unable to sign in. Done means error rates are reviewed daily, the duplicate account list is resolved, and the owner signs off that Firebase Authentication can be disabled for sign-in.
Retire Firebase Authentication and archive records
Once the parallel window closes, the team disables Firebase sign-in in the clients, removes Firebase Admin SDK token checks from services, and keeps the encrypted user export and the migration logs under the organization's retention policy. The security lead confirms that secrets and service account keys used only for Auth are revoked. Done means no client or service still accepts Firebase ID tokens, and the archived export is documented for audit purposes.
Adding SAML and OIDC enterprise sign-in
Enterprise customers need SAML or OIDC federation when their own identity provider, such as Entra ID or Okta, must authenticate their staff into your application. Firebase Authentication offers federated providers for the common cases, but a regulated customer will usually ask for its own tenant, its own IdP, and its own offboarding through SCIM. The decision to make early is whether your product will be sold to organizations that each bring a different IdP, because that single fact determines whether you need a multi-tenant identity layer or a single realm with configuration per application. ZITADEL documents both SAML 2.0 and OIDC, along with federation to Entra ID, Okta and any OIDC-compliant provider.
ZITADEL's model fits this case directly. Its instances are virtual tenants with full data isolation, organizations inside an instance hold projects and users, and each customer organization can use a different identity provider. In practice this means one customer's Okta configuration and user store never mix with another customer's, which is the boundary a security reviewer will ask about first. Confirm with ZITADEL's organizations documentation how your chosen version handles per-organization IdP configuration, how administrators are delegated, and whether your audit requirements can be met from the logs it produces.
SCIM v2 adds automated provisioning and deprovisioning, so a user removed in the customer's directory loses access without a manual step in your system. ZITADEL provides a SCIM v2 service provider interface, documented in its SCIM v2 guide. Supabase Auth and Appwrite Auth focus on application sign-in, and you should verify in their current documentation whether either exposes SAML or SCIM for your deployment version before promising enterprise federation to a buyer. Whichever platform you choose, test the full path with a sandbox identity provider, including certificate rotation and a user who is disabled upstream.
Running the new auth layer beside Firestore, Storage and Functions
Most teams cannot move authentication, data and functions in one cutover, so the new auth layer has to coexist with Firebase for a while. The cards below cover the decisions that connect the two sides: what stays on Firebase, how tokens are verified, and where each piece of data ends up.
Choosing what stays on Firebase
Decide whether Firestore, Cloud Storage and Cloud Functions remain on Firebase during the transition or move with authentication. Keeping data on Firebase while users move means the app must accept identities from one system and write records that reference another. Map each collection and bucket to an owner, and list which user identifiers each one stores. Confirm the Firebase plan and billing terms that still apply to the services you keep running.
Re-issuing user identifiers
A user moved to the new auth layer usually receives a new user ID, so every Firestore document, storage path and function reference keyed to the Firebase UID needs a mapping table. Store the old and new IDs side by side during the transition. Plan the mapping before the first user migrates, because records written under one ID and read under another are difficult to repair later.
Verifying tokens in functions and APIs
Firebase Auth issues ID tokens that Cloud Functions and Firebase Admin SDK code verify against Google's keys. After the move, the API must accept tokens from the new issuer, which means changing the verification library, the issuer and audience checks, and the JWKS source. Supabase issues JWTs signed with keys you generate, and Zitadel publishes OIDC discovery metadata. Test expired, revoked and cross-issuer tokens before cutover.
Replacing Firebase security rules
Firestore and Storage security rules check request.auth against the Firebase identity. Those checks have no direct equivalent once data lives in Postgres or Appwrite collections, so every access rule must be rebuilt against the new token claims. Inventory each rule, write the equivalent policy, and test it with real user roles. Do not assume a rule that passes on Firebase is correct on the new platform.
Residency gain across one region
Firebase Authentication processes data only in the United States, while Firestore location is set separately and cannot be changed after provisioning. Supabase Cloud projects are hosted in one main region chosen from 17 AWS regions, so auth, database and files can share a region there. Self-hosting places all of them in the location you choose, including your own data center or an EU facility, which is the main reason to keep auth and data together.
Operating two identity systems
While both systems run, two sets of keys, sign-in flows, user lifecycle events and audit logs exist. Decide which system is authoritative for password resets, account deletion and MFA enrollment, and document it for support staff. Confirm who on your team owns each system, how disabled accounts are propagated, and when the Firebase Auth project can be retired after the last active user has moved.
What self-hosting auth means for operations
Self-hosting Firebase Authentication's replacement moves operational ownership of the sign-in path to your team, and that work recurs for as long as the system runs. Supabase self-hosting is documented as community-supported through GitHub Discussions, GitHub Issues, Discord and Reddit, with enterprises directed to contact Supabase's Growth Team for commercial support. Self-hosted Supabase also runs as a single project, so Studio does not manage multiple organizations or projects, and features such as managed backups, point-in-time recovery and the Management API are not available. Before choosing, confirm with the vendor which support tier, if any, covers the auth service and your deployment pattern.
Appwrite's official Helm chart runs its built-in PostgreSQL, Redis, ClickHouse and object storage as single replicas without replication or failover, and the chart documentation says production data should use managed services or operators. ZITADEL takes the opposite posture for high availability: it recommends a Kubernetes cluster with the official Helm chart and requires PostgreSQL, supporting versions 14 through 18. Whichever platform you pick, the database tier, not the auth application, usually determines your availability design, so plan replicas, failover and backup targets before go-live.
Four tasks recur on every platform. Upgrades mean pulling new Docker configuration or chart versions and recreating containers, and Supabase's self-hosted Docker release 0.8.3 flagged one-way Storage database migrations that require a database backup first. Secrets generation means replacing placeholder values before first start, using the scripts Supabase provides for the secrets and JWT key pair. Backups and restore tests cover the auth schema and user data together, since a restored database without matching signing keys will not validate existing sessions. Patching covers the auth services, the database and the reverse proxy, and the security fixes in each release set the pace. Ask any vendor or partner for a written schedule covering who runs each of these tasks and how often.
Questions buyers ask before replacing Firebase Authentication
What drives the cost of replacing Firebase Authentication?
The cost depends on the number of user accounts, how many sign-in methods you run, how many applications share the identity layer, and how much of the work is done by your own engineers. Costs split into one-time work (planning, user migration, re-linking social providers, client SDK changes, testing and cutover) and recurring work (hosting, backups, upgrades, monitoring and on-call). Self-hosted software itself carries no license fee for Supabase (Apache-2.0), Appwrite (BSD-3-Clause) or Zitadel's APIs and SDKs, but Zitadel's core is AGPL-3.0 since v3.0, so have legal review that license before deployment. Ask any provider for a quote that separates these components and states what is one-time and what recurs.
How long does a Firebase Authentication migration take?
Duration depends on the number of user accounts, the sign-in methods in use, whether hashes can be imported unchanged, and how many clients must be updated before cutover. No supplied figure sets a fixed duration, so ask for a timeline in the written scope. The work usually runs in phases: export and inventory, a staging import, client SDK changes, a parallel-run period, and cutover. Each phase should have an agreed exit condition. Timelines can also be affected by your release calendar and the availability of your security and compliance reviewers.
What does our team need to provide for the migration?
You will need a named technical owner, access to the Firebase project with rights to export users, administrators for the target environment, and the people who own each client application's sign-in code. Security or compliance staff should review data location, retention and access decisions. Ask the implementation partner to list these roles in the scope, along with the decisions your organization must make, such as which identity provider each customer uses and whether password resets are acceptable for any user group.
Can our own engineers migrate Firebase Authentication without a partner?
Yes, if your team has experience with OAuth and OIDC, database administration and secret handling. Supabase documents a Firebase migration path that includes importing Auth users with the project's scrypt parameters, and Appwrite's Migrations feature imports Firebase projects. Zitadel documents migration guides from Firebase using approaches such as just-in-time migration. The main risks in doing it yourself are incorrect hash parameters, lost social links, token and session mismatches, and an untested rollback. Consider a partner for a review of the plan or for high-risk parts of the cutover.
How does password hash compatibility affect the effort?
Compatibility determines whether users keep their passwords. Firebase Auth uses a modified scrypt algorithm by default, and the Firebase CLI exports hashes along with their parameters. Appwrite's Users API accepts imported Scrypt modified hashes, and Supabase's Auth import uses the project's scrypt parameters. When hashes import cleanly, users sign in unchanged. When they do not, expect forced password resets, support tickets and a longer rollout. Test a sample of exported accounts in staging before committing to a plan, and confirm the exact parameters the export produces for your project.
Do social logins like Google or Apple need to be re-linked?
Usually yes. Social providers identify users with provider-specific IDs, and each new identity platform must register its own OAuth client, redirect URIs and consent screens with Google, Apple, GitHub or others. Users who sign in with a social account may need to link their existing account again, depending on how the identity provider matches email addresses and provider IDs. Zitadel can federate login with Google, GitHub, GitLab, Apple, Entra ID and Okta, and each customer organization can use a different identity provider. Plan the redirect URI changes and a user-facing message before cutover.
What do SAML and OIDC add to the project scope?
SAML and OIDC federation add work for enterprise customers who want to sign in with their own identity provider. Zitadel implements OpenID Connect, OAuth 2.0 and SAML 2.0, supports SCIM v2 for user provisioning and deprovisioning, and organizes tenants as instances, organizations and projects. Scope should include metadata exchange, attribute and claim mapping, group or role mapping, test tenants for each customer, and certificate rotation. Ask for these items to be listed as separate deliverables, since each customer connection is repeated work.
How do DeployOpen's fixed-scope engagements and retainers apply here?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for the migration plan, the list of deliverables, the acceptance criteria and the handover documentation in the written scope.
How DeployOpen scopes and delivers an authentication replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Firebase Authentication replacement, that means agreeing in writing which identity platform fits your sign-in requirements, then delivering the user migration, provider setup and documentation as a fixed scope.
How we scope
- Written scope lists which platform is in play: Supabase Auth, Appwrite Auth or ZITADEL, with the reasons stated.
- Inventory covers Firebase sign-in methods, social providers, custom claims, and enterprise SAML or OIDC connections in use.
- Scope records where users, hashes and sessions will live, so the EU or US data location question is answered before build.
How we build
- Deploy the chosen platform in your infrastructure, with secrets generated and placeholder values removed before any user data arrives.
- Test password hash import with a sample export, confirming that existing users sign in without a forced reset.
- Reconnect social providers and configure SAML or OIDC federation, then test each customer organization's login path end to end.
How we hand over
- Deliver runbooks for upgrades, secret rotation, backups and restore tests, written for your platform team.
- Document the user migration steps, rollback plan and known gaps, such as social links or sessions that do not carry over.
- Walk your engineers through the admin console, token settings and provider configuration, then close the scope in writing.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the migration.
- Retainers can cover patching the chosen platform release by release, including security fixes, after your change review.
- Ask any provider to confirm its support terms and maintenance commitments in writing before you choose a retainer level.
