Open source customer identity for SaaS

Open source customer identity for SaaS companies starts with the B2B tenant

A SaaS company selling to enterprises usually discovers the identity requirement during a deal: the buyer's security team wants single sign-on through its own identity provider, and its IT team wants users created and removed automatically through SCIM. Keycloak, ZITADEL and Ory can all run this self-hosted, and the choice turns on how tenants are modeled, how much of the tenant administration your team wants to build, and which protocols and provisioning features you must support on day one. Keycloak is the broadest option with mature SAML and OIDC brokering and a large operator community. ZITADEL models tenants natively as instances and organizations and documents SCIM v2 and per-organization identity providers. Ory splits the job into Kratos for identity and Hydra for OAuth 2.0 and OpenID Connect, which suits teams that want to assemble the tenant model in their own code.

Tenancy matters more here than in consumer login because one weak boundary exposes many customers at once. Each enterprise customer expects its users, its federated identity provider, its role grants and its audit trail to stay separated from every other customer, and those expectations usually appear in the contract as data processing and confidentiality terms. Ask each candidate how it isolates tenants (separate databases, separate instances or logical separation within one realm), how a tenant administrator is prevented from seeing another tenant's configuration, and how a customer's identity provider can be added or rotated without a platform release. Confirm these answers against the current documentation and a proof of concept, not against marketing summaries.

The practical test is whether your team can onboard a new enterprise tenant with its own SAML or OIDC identity provider and a SCIM feed without custom engineering each time. Keycloak and ZITADEL both document per-customer identity provider configuration, so the work becomes a repeatable runbook rather than a code change. Ory requires more of your own code for tenant administration, which is a sound trade if your product already has that layer. Whichever platform you choose, write the tenant onboarding steps, the isolation model and the contract clauses that depend on them before you select the product.

Which requirements SaaS buyers and regulators put on customer identity

This table maps the identity requirements that SaaS buyers, auditors and privacy regulators raise against a multi-tenant login layer, with the evidence each one tends to expect. Read each row as a design input: the right-hand column names what it changes in the build. Confirm NIS2 and Cyber Resilience Act applicability with counsel before relying on either.

Requirement	Source	What it means for the build
Per-customer SAML and OIDC federation	Enterprise buyer security questionnaires; SOC 2 logical access criteria	Each tenant needs its own identity provider configuration, with separate metadata, claim mapping and domain routing. Test sign-in with each customer's IdP before go-live.
SCIM provisioning and deprovisioning	Enterprise buyer security reviews; SOC 2 access removal expectations	Create, update and disable accounts from the customer directory without manual tickets. Removing a user at the source must end sessions and tokens in your platform, and you should test this path.
Tenant data isolation	GDPR Article 32 (security of processing); buyer architecture reviews	Decide between instance-level, organization-level or schema-level separation for users and credentials. Document the boundary and show how cross-tenant access is blocked and logged.
MFA and passkeys for customer accounts	Buyer policy requirements; FTC Safeguards Rule 16 CFR 314.4(c) where the SaaS serves financial customers	Offer MFA as a tenant-level policy, with passkeys as a phishing-resistant option and a documented fallback. Confirm which tenants must enforce MFA and whether that applies to all users.
Audit logging of authentication events	45 CFR 164.312 audit controls (HIPAA); SOC 2 CC7 monitoring; FTC Safeguards Rule logging	Log sign-ins, failures, MFA changes, admin actions and federation changes with tenant identifiers. Retention and access to logs should be defined so an assessor can sample them.
Unique user identification and person authentication	45 CFR 164.312 (HIPAA) for healthcare customers; SOC 2 CC6 logical access	Each person needs a unique identifier that survives IdP changes. Avoid shared accounts for support staff and record which operator acted on a tenant.
Processor obligations under GDPR Article 28(3)	GDPR Article 28(3), Regulation (EU) 2016/679	Your customer contracts must limit processing to documented instructions, including transfers. Identity data flows, subprocessors and hosting locations must match what the contract states.
Security of processing under GDPR Article 32	GDPR Article 32, Regulation (EU) 2016/679	Encryption of credentials and tokens, least-privilege administration and tested recovery paths are the evidence points. Document the measures chosen for each risk level.
SOC 2 security common criteria CC1 to CC9	AICPA 2017 Trust Services Criteria, security category	Buyers commonly ask for this frame. Map identity controls (access provisioning, MFA, logging, change management) to CC6 and CC7 and keep Type 1 or Type 2 evidence ready. An auditor issues the report, not the implementer.
NIS2 and Cyber Resilience Act applicability	Directive (EU) 2022/2555 Annex I; Regulation (EU) 2024/2847	Whether a SaaS product or provider falls in scope depends on its classification and what it sells. Confirm applicability with counsel before assuming either regime applies.

Which open source customer identity platform fits multi-tenant SaaS

Multi-tenant SaaS needs a identity platform that separates tenants cleanly, federates each customer's own identity provider and provisions users from customer directories. The options below differ mainly in how they model tenants, which licenses apply to the parts you would run, and how much login experience you build yourself. Confirm each feature against current documentation before you shortlist.

ZITADEL for tenant-native design

ZITADEL models tenants as instances with full data isolation, and organizations inside an instance can each federate a different identity provider over OIDC or SAML. It also provides a SCIM v2 interface for provisioning from customer directories and supports passkeys based on FIDO2 and WebAuthn. The license change matters: from v3.0, core, Console and hosted login are under AGPL-3.0, while APIs, SDKs and Helm charts remain Apache 2.0. Have counsel review the AGPL obligations before you modify and host it for customers. Confirm the database versions and HA design in the self-hosting docs.

Keycloak for brokering and directory federation

Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, identity brokering, and LDAP and Active Directory user federation, which suits customers whose users sit in on-premises directories. Multi-tenancy is usually handled with realms or organizations, so validate how tenant isolation and per-customer branding map to your model. Its Operator manages Keycloak and client resources, and you should set operator updates to manual approval to avoid unplanned upgrades. Production needs a synchronously replicated, supported database.

Ory Kratos and Hydra for custom login

Ory Kratos handles identity and user management, and Ory Hydra is the OAuth 2.0 and OpenID Connect server, both under Apache-2.0. This pairing fits teams that want to build their own login, registration and consent screens and keep full control of the user experience. The trade-off is that tenant administration, customer SSO onboarding and SCIM-style provisioning are more work to assemble and must be confirmed against current Ory documentation. Budget engineering time for the UI and account flows your product team owns.

authentik as a candidate

authentik is MIT licensed except the authentik/enterprise directory, which carries a separate enterprise license. If you adopt it, confirm that the features you need sit outside the enterprise directory, and record which parts you run. It is a reasonable candidate to evaluate alongside the three above for federation and provider configuration. Check tenant isolation, SCIM support and passkey coverage against current documentation before you rely on them for customer organizations.

Shared instance or isolated instance per customer: how the tenancy choice changes the build

A shared platform runs one identity deployment and places each customer in its own organization inside a common instance. ZITADEL organizes tenants as instances (virtual tenants with full data isolation), with organizations inside an instance holding users, projects and grants. Teams using Keycloak or an equivalent should confirm how realms or equivalent containers map to their model, because that mapping decides how much isolation one deployment provides.

Data isolation: Isolation is logical. Every customer shares databases, keys and administrative tooling, so access controls and tenant-scoped queries carry the isolation burden.
Operational load: One deployment, one backup routine and one monitoring stack serve all customers, which keeps the recurring work lowest of the three models.
Upgrade coordination: You upgrade once for everyone, so you need a test plan that covers every tenant's federation and branding settings before each release.
Per-tenant branding: Login pages can be themed per organization, but the theming scope and any limits should be confirmed in the version you plan to run.
Contract and data processing terms: Your processor contract must describe shared processing and the controls that keep one customer's data away from another, and it should name the subprocessors that touch the shared database.

Before committing, ask the vendor or your own test team to demonstrate tenant isolation in a staging environment with two test customers.",

How SCIM provisioning from customer directories keeps accounts current

Deprovisioning speed is a security requirement for enterprise buyers, and SCIM v2 is how a customer's directory keeps your platform in step with its own joiner, mover and leaver decisions. The customer's identity provider calls your SCIM endpoint to create users, update attributes and deactivate accounts when someone leaves or changes role, so access is removed without a support ticket. Zitadel provides a SCIM v2 service provider interface for standardized user provisioning and lifecycle management, documented in its SCIM v2 guide. Confirm equivalent SCIM v2 support, including deactivation rather than hard deletion, in any other platform you evaluate, and ask how it is exercised with each customer's directory (Entra ID, Okta or similar).

Map directory groups to what your application actually needs. In Zitadel, users and projects sit inside organizations within instances, and projects group applications, roles and grants, so a directory group should map to a role grant on a specific project for a specific customer organization, not to a global permission. Write the mapping down as a table: directory group, customer organization, project, role, and who approves changes. Before go-live, test with a customer directory in a non-production tenant: create, change group membership, deactivate, and reactivate a user; confirm that existing sessions end after deactivation; confirm that a removed group revokes the grant; and confirm that a renamed group does not orphan users. (Illustrative: a contractor removed from a customer's engineering group should lose the admin role in your product within the sync interval the customer agreed to.)

Every SCIM create, update and deactivation should appear in your audit trail with the source, the actor and the change, so you can answer a customer's question about when a user lost access. Decide where these events are stored, how long they are retained, and who can read them, and confirm with the platform vendor which events are logged and whether they can be forwarded to your SIEM. Control evidence for the security common criteria in SOC 2 and access control and audit controls in HIPAA both depend on this record existing and being complete.

Evidence SOC 2 auditors and enterprise security reviews ask for from customer identity

This table maps the identity evidence that SOC 2 auditors and enterprise buyers typically request to the component that produces it in a self-hosted customer identity stack. Read each row as a question to answer before the audit window opens, not as a finished control. DeployOpen prepares this evidence; independent auditors issue the SOC 2 report.

Evidence item	What the auditor or buyer looks for	Component that produces it
Authentication and MFA configuration exports	Proof that MFA and password policy are enforced for customer and administrator logins, with the settings as of a date and changes over the period	Realm or instance configuration export from Keycloak, ZITADEL or Ory, captured on a schedule and stored under change control
SSO and SCIM provisioning logs	Records showing which customer identity provider authenticated which user, and that SCIM created, updated and removed accounts as expected	Identity platform event and admin logs, SCIM service provider logs, forwarded to the central log platform
Deprovisioning timestamps	Evidence that a user removed in the customer directory lost access within the period the customer's policy and your commitments state	SCIM delete events, session revocation records and token lifetime settings, matched against directory change events
Change records for identity provider configuration	Approval, reason and reviewer for each change to a federated identity provider, client or tenant setting	Ticketing or change system linked to infrastructure-as-code commits for realms, organizations and identity provider definitions
Access reviews of administrator roles	Periodic confirmation that only current staff hold platform admin, realm admin or support impersonation roles, with reviewer sign-off	Role assignment export from the identity platform, reviewed in a recorded campaign and retained as evidence
Logging and monitoring of administrator actions	Records that privileged actions are logged, retained and examined, including who changed what and when	Admin event logs and audit trail forwarded to a SIEM with retention and alerting configured
System description for a SOC 2 Type 1 or Type 2 report	A description of the customer identity system, its boundaries, subservice components and controls, which the auditor tests against the Trust Services Criteria	Architecture diagram, control narratives and the inventory of identity components prepared by the operator and reviewed with the auditor

What self-hosted identity costs compared with per-user CIAM pricing

Self-hosting customer identity replaces a per-user invoice with costs you pay in several places at once. The main cost components are infrastructure that scales with login volume, a database and high availability design, upgrades, the one-time migration of existing users and password hashes, custom login UX, on-call support, and internal engineering time. Infrastructure grows with peak logins, token issuance and session load, so the load test results from your own peak scenarios drive the sizing. Keycloak's supported high availability designs need a synchronously replicated database, and Zitadel recommends Kubernetes with the official Helm chart for high availability, so the database and cluster are a recurring platform cost, not a one-off setup fee.

Some costs are one-time and some recur. Migration, theming, B2B tenant onboarding design and integration with each customer's identity provider are largely one-time or project work, while upgrades, patching, monitoring, on-call coverage and database operations recur every year. Keycloak plans four minor releases a year, and its operator documentation strongly recommends manual approval for updates, so someone must test and schedule every upgrade. Ask any implementation partner to price these as separate line items in a written scope, including who carries the on-call rota and who approves each upgrade.

SaaS identity pricing is usually charged per monthly or daily active user, and the vendor's terms decide what counts as active. Self-hosting costs are fixed in part and variable in part, so the break-even point depends on user volume and tenant count, not on a single figure. A B2B platform with many small tenants can carry higher fixed operating cost than a consumer app with the same login volume, because each tenant adds onboarding, identity provider configuration and support. Check the vendor's terms on the Zitadel pricing page and get written quotes for each option, then build the comparison from your own forecast of active users and tenants over three to five years. Confirm with each vendor whether tenant count, organizations or instances affect billing.

How the open source customer identity rollout moves tenants onto SSO and SCIM

The sequence turns a set of tenant-specific login requirements into a tested platform that moves each customer organization onto its own SAML or OIDC identity provider and SCIM provisioning, one tenant at a time, with a rollback path at every cutover.

Inventory tenants and their identity providers
Your product, identity and customer success teams list every B2B tenant, the identity provider each one uses (for example, Entra ID, Okta or a SAML directory), the protocol it supports, whether it needs SCIM, and which tenants already have local accounts. DeployOpen reviews the inventory with you and records the open questions per tenant. The step is done when each tenant has a named protocol, a named owner on the customer side and a migration category agreed in writing.
Choose the platform and design tenancy
Compare Keycloak, ZITADEL and Ory against your tenancy model, SCIM needs, database standards and upgrade appetite. ZITADEL maps tenants to instances and organizations, while Keycloak typically models tenants as realms or organizations depending on version and scale, so the choice shapes isolation and administration. The output is a written architecture decision record covering tenancy, database, hosting and the upgrade method, which you approve before build starts.
Build a non-production environment with two pilot tenants
DeployOpen builds the platform in a non-production environment and configures two pilot tenants, one using SAML and one using OIDC, against test identity providers you control. Login, logout, role mapping and branding are tested end to end. The step closes when both pilot tenants sign in successfully, claims map to the expected roles, and the configuration is stored as code so it can be reproduced.
Test SCIM provisioning with a customer directory
Using a directory from a pilot customer or a realistic test directory, the team tests create, update, deactivate and group sync through the SCIM interface, including how removed users lose sessions. Edge cases such as duplicate emails, renamed users and attribute mismatches are logged and resolved. The step is done when a full lifecycle test passes with evidence retained, and the customer's directory administrator confirms the behavior matches their expectations.
Migrate existing users with a password hash strategy
Existing customer accounts are moved using a migration method chosen with you, such as just-in-time migration on first login or a bulk import that keeps existing password hashes where the source format is supported. Each option is tested against sample accounts, and users who cannot be migrated without a reset are identified in advance. The step is done when migrated test accounts log in with their existing credentials and the reset list is agreed with the business owner.
Cut over tenant by tenant with rollback
Each tenant moves to the new login path in its own change window, with the previous path kept available until the tenant confirms successful sign-in and provisioning. DeployOpen runs the cutover runbook, verifies sign-in for a named test user, and records the rollback steps before each change. The step is done for a tenant when its administrator signs off, and it is only closed for the program when every tenant in the inventory has a recorded outcome.
Hand over the run state and upgrade cadence
The runbook for operations covers monitoring, backups, certificate renewal, and the upgrade method. For Keycloak, the runbook must state how database schema migration is applied, whether automatically at startup or manually, and that operator updates use manual approval mode, which the Keycloak Operator documentation strongly recommends. Upgrades are tested in non-production first. The handover is complete when your team has run one supervised upgrade, and the on-call and support responsibilities are documented. Timing for each phase depends on the scope agreed in writing.

Questions to ask an implementation partner for SaaS customer identity

Ask how the partner onboards a new enterprise tenant and its identity provider before anything else, because this is where multi-tenant designs usually break. A good answer walks through the sequence: creating the tenant boundary, choosing between a separate instance and an organization inside a shared instance, registering the customer's SAML or OIDC identity provider, and testing a login with a real customer test account before go-live. For ZITADEL, the partner should explain how instances, organizations, projects and grants are used and why each customer organization can point at its own identity provider. For Keycloak, they should explain how realms or clients are isolated per tenant and what that means for administration at scale. Ask for the written runbook and the rollback steps if a tenant's federation fails. Vague answers such as "we configure it per customer" with no runbook are a warning sign.

Ask how they test SCIM provisioning against customer directories such as Entra ID or Okta, and how they handle password hash migration and upgrades. For SCIM, a strong partner describes a test matrix covering create, update, deactivate and delete events, group membership changes, and attribute mapping, run against a sandbox tenant from each directory type you expect to support. They should also explain what happens when a deprovisioning event is missed. For migration, ask whether they use just-in-time migration so existing password hashes are verified at first login and then rehashed, rather than forcing resets. For upgrades, ask how they avoid downtime: the answer should cover a tested upgrade path, database schema migration handled deliberately (Keycloak applies schema changes at startup by default and can also run them manually), and manual approval for operator updates. Ask for load test results against your expected login peaks, and who owns that test.

Ask how they review AGPL obligations for the platform you choose. ZITADEL's core, Console and hosted login are licensed under AGPL-3.0 since v3.0, while its APIs, SDKs and Helm charts remain Apache 2.0. Keycloak is Apache-2.0. A good partner separates these components in writing, explains which modifications would trigger source disclosure if you offer the modified software to users over a network, and states whether any custom login theme or extension changes that analysis. Ask for their written opinion on the license position and recommend that your own counsel confirms it. Finally, ask how the contract covers GDPR Article 28(3) processor terms: processing only on documented instructions, including for transfers, and the security measures required by Article 32. The strongest answer names the data processing agreement template, the sub-processors involved, the breach notification path, and who is named as controller and processor for each environment.

What open source customer identity for SaaS costs, takes and needs from my team

What drives the cost of open source customer identity for a SaaS company?

Cost is driven by scope, not by a per-user meter. Self-hosted Keycloak, ZITADEL or Ory carry no license fee for the core software, so the spend falls into four buckets: the infrastructure that runs the identity platform, the one-time design and build of tenancy and federation, migration of existing users, and ongoing operations and upgrades. Infrastructure grows with login volume, and the design work grows with the number of identity provider patterns you must support. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. Ask any partner to itemize one-time work, recurring support and infrastructure separately so you can compare options on the same basis.

How long does onboarding the first B2B tenant take on self-hosted identity?

The first tenant takes longest because it sets the pattern that later tenants reuse. The time depends on how many tenant-specific steps exist, such as creating the organization, mapping the customer's SAML or OIDC identity provider, configuring SCIM provisioning from their directory, and testing login and deprovisioning end to end. Each new tenant after the first usually follows a shorter, repeatable procedure if you automate it. No fixed duration is supplied for this work here, so ask any partner to state their onboarding steps and the assumptions behind each step, and confirm the sequence against your own customer directories before you agree a timeline in writing.

What does my internal team need to run customer identity after launch?

Your team needs ownership of four skills: identity protocols (OpenID Connect, OAuth 2.0, SAML 2.0 and SCIM), the database and cluster that hold identity state, release management for the platform, and the process that onboards and offboards tenants. Zitadel, for example, uses PostgreSQL with versions 14 through 18 supported, and recommends a Kubernetes cluster with the official Helm chart for high availability. Keycloak documents that both supported high availability designs need a synchronously replicated database. Keycloak also recommends manual approval mode for Operator updates. Your team should own the on-call rota, the upgrade calendar and the tenant request queue, even if a partner handles build and support.

Can an in-house team deploy and operate open source customer identity without a partner?

Yes, a capable platform team can deploy and operate these platforms without a partner, but the decision depends on the skills and capacity already in place. Teams that already run Kubernetes, PostgreSQL and certificate management, and that have engineers who understand OAuth and SAML, can start with the official documentation. The harder parts are usually the first multi-tenant design, migrating existing password hashes, and building repeatable SCIM and identity provider onboarding. Keycloak's upgrade path also requires planning for schema migration, which it runs automatically at startup by default. Compare the cost of hiring or training against a fixed-scope engagement, and ask a partner what they would hand over, document and test.

Does AGPL-3.0 require a SaaS company to publish its code if it modifies and hosts ZITADEL?

AGPL-3.0 can require source disclosure when you modify the licensed program and let users interact with it over a network, so a SaaS company that changes ZITADEL's core and hosts it for customers should not assume the license is harmless. Zitadel moved its core, Console and hosted login from Apache 2.0 to AGPL 3.0 with v3.0 on 31 March 2025, while its APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay Apache 2.0. Keycloak and Ory Kratos and Hydra use Apache-2.0, which carries different obligations. Have counsel review how your modifications, deployment and customer access interact with the license before you build, and confirm which components your design touches.

Should a SaaS company use one shared identity instance or isolated instances per customer?

Use one shared instance when customers accept logical separation within a common platform and your operating model favors fewer clusters. Use isolated instances when customers or their regulators require stronger separation, separate upgrade windows, or separate data locations. Zitadel organizes tenants as instances with full data isolation, and organizations inside an instance hold users and projects, so the choice is a structural one with operational consequences. Isolated instances multiply infrastructure, upgrades and monitoring. Shared instances concentrate risk and blast radius. Write the decision criteria down, including data residency, contractual isolation and upgrade ownership, and test the chosen model with a pilot tenant before committing.

What does open source customer identity cost compared with per-user CIAM pricing?

Open source removes the license fee for the core platform, but it moves cost into infrastructure, engineering and support, which scale differently from SaaS pricing. SaaS CIAM typically charges by monthly or daily active user, so cost rises with growth. Self-hosted cost rises more in steps, driven by cluster capacity, database sizing, and the team needed to run it. Build a model with your expected active users, peak logins, number of tenants and migration volume, then compare the recurring totals over your planning horizon. Ask every vendor and partner for the same assumptions so the comparison reflects your numbers rather than their marketing.

How DeployOpen scopes and supports SaaS customer identity

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source identity platforms inside the client's own cloud accounts, data centers or air-gapped networks. For SaaS teams, that means a multi-tenant login layer, customer identity provider federation and provisioning built to a written scope that sets out what the platform will and will not do.

How we scope

We agree in writing which tenant model, instances and organizations the SaaS platform needs before any build work starts.
We inventory each enterprise customer's SAML or OIDC identity provider and SCIM directory, noting which attributes and groups must map into roles.
We confirm the expected login volumes, peak periods and data residency constraints so the deployment sizing reflects the real service.

How we build

We deploy the chosen platform, such as ZITADEL, Keycloak or Ory, with PostgreSQL, high availability and backup designed for the agreed architecture.
We configure per-customer identity provider federation, SCIM provisioning, passkey login with password fallback, and branded login pages per tenant.
We run security testing against login, token and admin interfaces and document the findings and fixes before handover.

How we hand over

We deliver architecture diagrams, runbooks for onboarding a new tenant, and configuration records kept under your change control.
We document the upgrade path, including how the operator or Helm update approval mode and database migration choices are set and tested.
We provide evidence packs mapped to your existing access control and audit controls, prepared for your auditors, without issuing any attestation ourselves.

How we support

Ongoing support, upgrades and continuous security testing are available as a retainer, scoped separately from the build.
Support covers patching the identity platform, reviewing new releases, and re-testing federation and provisioning after changes.
Engagements are fixed-scope, so any change to tenant volume, providers or features is agreed in writing with its own deliverables.

Open source customer identity for SaaS companies