Microsoft Entra ID vs ZITADEL

ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0, and it provides a device authorization grant for devices such as smart TVs. For most modern web and mobile applications, the OIDC route is the cleaner migration path, because the client registration, redirect URIs and token claims can be reviewed directly. SAML applications take more work, since the signing certificate, the assertion attributes and the name ID format each have to match what the service provider expects.

• OIDC and OAuth 2.0: Confirm which grant types each application uses, such as authorization code with PKCE, and whether any app relies on the implicit flow.
• SAML 2.0 signing: Check whether each service provider requires signed assertions, signed requests or encrypted assertions, and which certificate it trusts.
• Token claims: Compare the claims Entra ID emits today, such as roles, groups and preferred username, with what ZITADEL places in tokens for the same app.
• Device flows: Only apps that use the device authorization grant can rely on it, so confirm this with each vendor before assuming it works.
• Test environment: Run a staging client against a test organization and record the exact claims and assertion attributes received.

Before cutover, verify each protocol path against the application vendor's documentation rather than the product comparison alone.

ZITADEL provides a SCIM v2 service provider interface for standardized user provisioning and lifecycle management. That lets an upstream system create, update and deactivate users in ZITADEL without manual steps, which is the function that Entra ID's provisioning service performs for enterprise applications. The question for each application is whether it accepts SCIM as the push mechanism, or whether it needs group sync, custom attributes or a different connector.

• Lifecycle coverage: Confirm which operations each target application needs, such as create, update, deactivate and group membership changes.
• Attribute mapping: List the attributes Entra ID currently sends, including department and on-premises identifiers, and map each to a ZITADEL user attribute.
• Deprovisioning behavior: Test how a disabled user is handled in each target app, since some apps keep local accounts after a SCIM disable.
• Source of truth: Decide whether Entra ID, a directory such as Active Directory, or ZITADEL holds the authoritative record during the transition.
• Group and role mapping: Confirm how groups become ZITADEL roles and grants, and how those grants appear in application tokens.

Confirm SCIM details, filters and patch support with the ZITADEL SCIM documentation and the target application before you rely on automated provisioning.

ZITADEL supports passwordless login with passkeys based on FIDO2 and WebAuthn, and it falls back to password login when a user has no passkey registered. Passkeys are registered per user, so the rollout depends on how many users enroll, which authenticators they use and whether the fallback policy is set to match your risk tolerance. Entra ID offers passkey and FIDO2 sign-in as well, so the comparison is about enrollment flows, recovery and policy control rather than the existence of the feature.

• Enrollment path: Decide whether users register passkeys at first login, through a self-service page, or through an administrator-assisted process.
• Fallback policy: Confirm when password login remains available and whether any group, such as administrators, should be forced to passkeys only.
• Recovery: Define how a user recovers access when a device is lost, and who verifies the request.
• Relying party configuration: Passkeys are bound to the domain, so confirm the domain and subdomain plan before enrolling users.
• Device support: Test the authenticators your staff actually use, including platform authenticators and hardware security keys.

Where a regulator or internal policy sets authentication assurance levels, have your assessor or compliance lead confirm how passkey sign-in maps to those requirements.

ZITADEL can federate login with upstream providers, including Entra ID, Okta, Google, GitHub, GitLab, Apple, Keycloak, LDAP and OpenLDAP, and any OIDC-compliant provider. Each customer organization can use a different identity provider, which matters when some users sign in through Entra ID while others sit in a directory that ZITADEL reads directly. Federation to Entra ID is a useful bridge during a phased move, because the existing tenant can remain the source for Microsoft 365 while ZITADEL handles application login.

• Entra ID as upstream: Register ZITADEL as an application in the Entra tenant and confirm which claims come back and which user identifiers are stable across the two systems.
• LDAP and OpenLDAP: Confirm the bind account, the search base, the attributes used for login and whether group membership is read.
• Per-organization providers: Map which customer organizations or tenants use which upstream provider, and document the fallback when one provider is unavailable.
• Account linking: Decide how an existing local account is matched to a federated identity when the same person signs in through two providers.
• Entra ID features: Conditional Access and other Entra ID P1 or P2 policies apply only to sign-ins that pass through Entra ID, so confirm which controls still run there.

Validate each federation path end to end with test accounts, and confirm the LDAP and Entra ID settings against the current ZITADEL identity provider documentation.

Entra ID is paid for through Microsoft licensing, usually per user and per month, and the amount depends on the plan and the add-ons your tenant holds. Some Microsoft 365 plans already include Entra ID features, so part of the cost may already sit in a contract you pay for. Check which Entra features your current plans include before you attribute any cost to identity alone.

• Base and add-on tiers: Entra ID P1 and P2 are separate per-user licenses, and features such as conditional access and risk-based policies depend on which tier you hold.
• Bundled entitlements: Some Microsoft 365 plans include Entra ID capabilities, so the incremental cost may be lower than the list price suggests.
• Application re-registration: Moving apps to a new identity provider means rebuilding enterprise app registrations, claims, groups and policies, which is staff time and testing rather than a license line.
• Recurring versus one-time: Licenses recur every billing period, while re-registration and rollout work is usually a one-time project.
• Cost drivers: User count, which tiers you need, and whether Microsoft 365 contracts already cover the features you use.

Ask your Microsoft partner or account team to itemize each Entra license against the features you actually use.

Self-hosted ZITADEL is open source, so there is no per-user license fee. The cost is the infrastructure it runs on, the PostgreSQL database behind it, the staff who operate it and the integration work to connect your applications. ZITADEL documents PostgreSQL versions 14 through 18 and supports Docker Compose, Kubernetes and binaries, so the platform choice affects the operations effort.

• Infrastructure: Compute, storage, load balancing and, for high availability, a Kubernetes cluster with the official Helm chart, which ZITADEL recommends.
• Database: A managed or self-run PostgreSQL service, including backups, replication and patching.
• Upgrades and support: Staff time for upgrades, security patches and monitoring, plus any paid support contract you choose.
• Integration work: Re-pointing applications, configuring identity providers and migrating users, which is often the largest one-time item.
• Cost drivers: Required availability, number of instances and organizations, the operating model and in-house skills.

Ask for the infrastructure and operations assumptions behind any estimate, including who patches the database and who answers incidents.

A useful quote puts both options on the same line items, over the same period, with the same user counts and features. Without that, a comparison mixes subscription fees with one-time labor and hides the costs that recur. Written scope also matters, because integration and migration effort varies with the number of applications and identity sources.

• Licensing baseline: Per-user Entra ID licenses by tier, with the features each tier covers, and which are already included in your Microsoft 365 plans.
• Infrastructure plan: Sizing for compute, storage and PostgreSQL, with the high availability design and recovery targets you require.
• Operations scope: Who handles upgrades, patching, backups, monitoring and on-call support, and the response commitments in writing.
• Migration scope: The applications, protocols (OIDC, SAML, SCIM) and identity sources to integrate, plus testing and cutover steps.
• Recurring and one-time totals: A split of annual recurring costs from the one-time project costs for both options over the same period.

Request these in a fixed-scope written proposal so that every assumption is visible before work starts.