Open-source alternatives to Ping Identity

Open-source alternatives to Ping Identity: which option fits your renewal

If your Ping Identity renewal is forcing a decision, Keycloak fits most SAML and OIDC federation estates, while ZITADEL fits multi-tenant customer identity. authentik or FreeIPA fit narrower needs: authentik when you want a lighter admin experience with LDAP, SCIM and proxy authentication, and FreeIPA when Linux systems and a Microsoft Active Directory trust are the center of gravity. Teams start this search for several reasons: a renewal quote that changes the scope of what they pay for, a licensing or pricing change, a data residency rule that requires identity data to stay in a specific location, or a growing sense of lock-in. The context matters here. Thoma Bravo completed its acquisition of ForgeRock on August 23, 2023 and combined ForgeRock into its portfolio company Ping Identity, so many legacy ForgeRock customers now deal with a different vendor relationship, product roadmap and contract structure than the one they signed.

Before you act on any of this, read your own Ping Identity or ForgeRock contract. Check the term length, notice period for non-renewal, what is licensed per user, per application or per environment, whether data export rights and assistance are included, and whether any support or upgrade obligations change after the combination. Those terms, not general market assumptions, determine your deadline and your leverage. Ask your account team in writing to confirm which products, versions and support tiers are covered after the renewal date, and whether the contract allows a phased exit of individual applications. Also list which protocols each application uses (SAML 2.0, OpenID Connect, LDAP or header-based proxy), because that inventory decides which open-source option can carry each workload.

A useful first step is a short fit assessment with three outputs: an application inventory with protocol and user population for each app, a count of directories and identity sources you must federate, and a list of tenancy and customer-facing login requirements. Keycloak is the default candidate for workforce and partner federation with existing LDAP and Active Directory. ZITADEL deserves a serious look if your product serves many customer organizations that need isolated data and policies. Confirm each candidate against your own integrations in a proof of concept before you commit, and treat the licence differences as a legal review item: Keycloak is Apache 2.0, ZITADEL is AGPL-3.0 with exceptions, and authentik's core is MIT with a separate enterprise licence for its directory features. Decide early who owns the self-hosted platform after cutover, since that ownership drives most of the long-term cost.

Keycloak, ZITADEL, authentik or FreeIPA: which Ping Identity alternative to shortlist

Each platform below covers part of what Ping Identity customers rely on, but none is a drop-in replacement. Shortlist by workload: application SSO, customer identity across tenants, enterprise directory duties, or Linux-centric identity. The trade-offs that matter most are protocol coverage for your application estate, licensing for the features you need, and who supports the platform in production.

Keycloak for broad SSO parity

Keycloak is licensed under Apache 2.0, is a CNCF incubating project, and supports OpenID Connect, OAuth 2.0 and SAML 2.0. It also has built-in user federation with existing LDAP and Active Directory servers, which matters when directories stay in place during a phased cutover. Check each relayed application against its SAML and OIDC settings, and test federated logins with your real directory. Plan backups carefully: the documented realm export and import process has limitations as a backup mechanism and requires all nodes to be stopped while it runs. The latest supplied release is 26.8.1, released on October 13, 2026.

ZITADEL for multi-tenant customer identity

ZITADEL is licensed under AGPL-3.0, with Apache 2.0 and MIT exceptions for specific directories. It supports certified OIDC, SAML 2.0, SCIM 2.0 and LDAP, and it self-hosts with Docker Compose or Kubernetes on PostgreSQL 14 or later. Its Identity System, Organizations and Projects model isolates data and policies at several levels, which suits products that serve many customer tenants. Legal teams should review the AGPL-3.0 obligations before modifying and distributing the code, and platform teams should confirm that the data model fits existing Ping Identity customer tenancy.

authentik for flexible self-managed SSO

authentik's open-source core is MIT licensed, while its enterprise directory is under a separate authentik EE License. The free edition supports OIDC, SAML, LDAP, SCIM, RADIUS, Kerberos and proxy authentication, but support is community-only. Enterprise adds privileged access management and Google Workspace and Microsoft Entra ID integrations with ticket-based support, and Enterprise Plus adds SLAs and FIPS compliance. Confirm with the vendor which features your controls require, because the license split determines which capabilities are free to run in production.

FreeIPA for Linux-centric directories

FreeIPA combines 389 Directory Server, MIT Kerberos, the Dogtag certificate system and SSSD into one identity and access management stack for Linux. It can create mutual trusts with Microsoft Active Directory, which helps when Linux hosts and Windows users must coexist. It is a strong fit for host-based access, Kerberos single sign-on and internal certificate issuance. It is a weaker fit for modern web application SSO and customer-facing login flows, so most organizations pair it with a web SSO platform such as Keycloak or authentik.

How each Ping Identity capability maps to open-source options

This table maps the capabilities a Ping or legacy ForgeRock estate usually relies on to the open-source platform that covers each one. The coverage column marks each row as full, partial or confirm-needed, so you can see where a proof of concept should focus. Verify every row against the specific Ping and ForgeRock modules you run, because product packaging differs between deployments.

Capability	Open-source options	Coverage and what to confirm
SAML and OIDC single sign-on	Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0. ZITADEL supports certified OIDC and SAML 2.0. authentik's free edition supports OIDC and SAML.	Full for standard protocols. Confirm each relying party's required SAML bindings, signing algorithms and attribute mappings.
OAuth 2.0 authorization	Keycloak provides OAuth 2.0 authorization servers. ZITADEL and authentik also issue OAuth 2.0 tokens through OIDC flows.	Partial. Confirm token lifetimes, custom grant types and scope models used by your APIs against the Ping or ForgeRock configuration.
Directory and LDAP federation	Keycloak has built-in user federation with existing LDAP and Active Directory servers. FreeIPA combines 389 Directory Server and Kerberos and can create mutual trusts with Microsoft Active Directory.	Full for read-based federation. Confirm write-back behavior, group mapping and password policy enforcement with your directory.
Multi-factor authentication	Keycloak and ZITADEL provide built-in second factors. authentik's free edition includes MFA through its flow framework.	Partial. Confirm the factor types (TOTP, WebAuthn, push) your users enroll today, because push-based and vendor-specific methods may need a different approach.
Adaptive or risk-based policies	Keycloak and ZITADEL offer conditional flows and policy controls. Risk scoring that uses large threat intelligence feeds is typically not a feature of self-hosted open-source platforms.	Confirm needed. List the risk signals your Ping policies use today and test each one against the chosen platform before committing.
SCIM provisioning	ZITADEL supports SCIM 2.0. authentik's free edition supports SCIM. Keycloak support depends on the extension or version you deploy.	Partial. Confirm the SCIM version and resource types your downstream applications expect, and test deprovisioning explicitly.
Customer identity and multi-tenancy	ZITADEL structures tenants as Identity System, Organizations and Projects with isolation at several levels. Keycloak supports realms for separation.	Full for ZITADEL's model. Partial for Keycloak, where realms may require more operational design for many tenants.
Fine-grained authorization	Keycloak offers authorization services with resource and policy models. ZITADEL uses roles and grants within projects. Externalized policy engines are usually added separately.	Partial. Map each Ping or ForgeRock authorization policy to a concrete model and confirm it with a test suite before cutover.
API and gateway access control	Keycloak and ZITADEL issue and validate tokens that gateways can check. Gateway enforcement is usually provided by a separate proxy or API gateway component.	Confirm needed. Identify which gateway enforces policy today and confirm the token validation method it requires.

Does open-source SAML and OIDC federation match what our apps need?

Federation parity is decided application by application, not by protocol name. Before choosing between Keycloak, ZITADEL and authentik, build an inventory of every relying party that Ping Identity or the legacy ForgeRock stack serves today. For each one, record the protocol (SAML 2.0 or OIDC), the signing and encryption certificates in use, the metadata or redirect URIs, the claims and attribute mappings the app expects, how it handles single logout, and the session length it assumes. These are the details that most often break during cutover, and they rarely appear in a vendor feature list.

All three candidates support SAML 2.0 and OIDC, and Keycloak, ZITADEL and authentik can all federate existing LDAP and Active Directory sources, so a directory-backed user store is a realistic starting point for most estates. The gaps tend to sit in the details: how a given product signs assertions, which attributes it can emit in a SAML response, how it maps group membership into claims, and whether logout propagates to every app. Confirm each of these with the vendor's current documentation and in your own environment instead of assuming parity from the protocol names. Treat certificate rotation as part of the test too, because a rotated signing key that the relying party has not imported will stop logins without any change in the identity provider.

Run each relying party through a test tenant or realm that mirrors production configuration, then check login, attribute release, step-up MFA, logout and token lifetime against written acceptance criteria. Log any app that needs a custom mapper, a script or a changed claim name, because those changes become ongoing maintenance. Applications that cannot meet their criteria are the ones to move last or to rework first, and they should be named in the migration plan before cutover dates are set. Ask the implementation partner to deliver this matrix as part of the scope.

Cost of ownership for open-source Ping Identity alternatives over several years

This table sets the Ping Identity or ForgeRock subscription against the cost components of self-hosting Keycloak or ZITADEL, marking each as one-time or recurring and naming what drives it. Use it to build a quote request, since no Ping, ForgeRock or DeployOpen prices are stated here. The main takeaway is that the software license is usually the smallest recurring item, while staffing, high availability operations and migration effort decide the total.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it
Ping Identity or ForgeRock subscription and support	Ping Identity (the combined company after the 2023 acquisition of ForgeRock)	Recurring	Contracted user or identity volume, modules purchased, support tier, and renewal terms. Confirm the current scope in your contract.
Open-source software license (Keycloak, ZITADEL)	No license fee for the core projects; Keycloak is Apache 2.0 and ZITADEL is AGPL-3.0 with listed exceptions	Not applicable	Check licensing for any add-on or enterprise edition you plan to adopt, since those carry separate terms.
Infrastructure for application and identity nodes	Your cloud account, data center or air-gapped environment	Recurring	Node count for high availability, environments (production, test, disaster recovery), and data residency zones.
Highly available PostgreSQL database	Your platform team or cloud provider service	Recurring	ZITADEL requires PostgreSQL 14 or later. Replication, backups, and failover design raise cost and skills needs.
Implementation and architecture	Internal staff or an implementation partner under a written scope	One-time	Number of realms or tenants, protocol mix (SAML, OIDC, LDAP), and custom authentication flows.
Integration and application onboarding	Internal application teams or a partner	One-time, with ongoing change	Number of applications, each with its own SAML or OIDC configuration, claims mapping and test cases.
Migration and phased cutover	Internal staff or a partner	One-time	Application count, user count, password and MFA enrollment handling, and parallel running time.
Hardening, backup and restore testing	Internal security team or a partner	One-time, then recurring tests	Keycloak's realm export is not a full backup method, so budget for tested backup and restore procedures on the live cluster.
Upgrades and patching	Internal platform team or a support contract	Recurring	Release cadence, the size of custom extensions, and the number of environments to test.
Support contract for the open-source platform	Vendor or partner support provider, if chosen	Recurring, optional	Response expectations, hours of coverage, and whether support covers custom code. Confirm terms in writing.
Internal skills and on-call operations	Your staff	Recurring	Team size, on-call coverage, and training needed for identity operations and incident response.
Compliance evidence preparation	Internal compliance team or a partner	Recurring	Audit scope and the number of controls you must evidence. DeployOpen prepares evidence but does not issue audit reports.

What you give up when leaving Ping Identity and the usual workarounds

Moving off Ping Identity or a legacy ForgeRock deployment usually means losing some vendor-packaged capabilities, not just licenses. The cards below cover the gaps most often found during planning, what to build or buy in their place, and what to confirm with each candidate platform before you commit to a cutover plan.

Adaptive and risk-based authentication

Commercial suites often ship risk scoring, adaptive MFA step-up and behavioral signals as managed features. Self-hosted Keycloak, authentik and ZITADEL provide conditional MFA and policy hooks, but the risk models and threat feeds are usually not included. Plan to rebuild or replace the risk engine with your own rules, a SIEM feed or a third-party service. Confirm which signals each platform exposes, how step-up policies are written, and who maintains the rules after go-live.

Vendor support tiers become a contract

Ping Identity support is part of the subscription. With open-source platforms, support comes from a community, a commercial vendor of that platform, or an implementation partner under a retainer. The community tiers of authentik, for example, are documented as community support only, while its paid tiers add ticket-based support and SLAs. Budget for a named support contract before cutover, and ask each provider for response targets in writing.

Prebuilt connectors need custom integration

Applications often reach identity through prebuilt connectors that a commercial product maintains. Open-source platforms cover the core protocols, OIDC, SAML 2.0, SCIM 2.0 and LDAP, but a specific SaaS app or internal system may not have a ready-made template. Inventory every app and classify it as standard protocol, connector-based or custom. Confirm which SCIM and LDAP profiles each candidate supports for your highest-value applications.

Realm export is not a full backup

Keycloak exports and imports realms as JSON with kc.sh export and kc.sh import. The Keycloak documentation warns that this is limited as a backup and restore mechanism, and that all nodes must be stopped while the export runs. Teams moving from a managed service often assume a single export covers everything. Design a separate backup plan using database-level backups, and test a restore into a non-production cluster before cutover.

Password hashes and MFA enrollments

Exports from many identity platforms do not include password hashes in standard user lists. Vendor-specific hash export may require a support request, and MFA enrollments are usually bound to the source platform. Plan for password reset or re-enrollment for most users, and ask your vendor and the target platform what hash formats they can import. Confirm whether password hashes can move at all before setting user communication dates.

Audit and reporting dashboards

Commercial suites provide prebuilt reports for access reviews, login anomalies and compliance evidence. Keycloak, authentik and ZITADEL emit events and logs, but the dashboards and retention rules are typically built by your team. Map each report your auditors use today to a log source, a SIEM dashboard or a scheduled export. Confirm log retention, event coverage and how evidence for access reviews is generated.

How to migrate off Ping Identity application by application

This sequence moves each application from Ping Identity to a self-hosted target such as Keycloak or ZITADEL one at a time, so every app is proven on the new platform before its users depend on it. The end state is a decommissioned legacy service backed by a restore test you have run yourself.

Inventory applications, protocols and claims
The application owners and the identity team list every relying party that uses Ping Identity, including the protocol (SAML 2.0 or OpenID Connect), the redirect URIs or assertion consumer URLs, the signing and encryption certificates, the attributes and group claims each app expects, and the MFA policy it relies on. Work from the Ping configuration exports and the application owners' records rather than memory, because undocumented claim mappings are the most common cause of a failed cutover. The output is a single register with one row per application and a named owner who signs off on it. Confirm with each owner which claims are read by code and which are only displayed.
Map user sources and export directory data
Identify where the authoritative user records live, whether in the Ping directory, an LDAP or Active Directory store that Ping reads, or a database fed by provisioning. Export the user attributes and group memberships using the tooling your Ping deployment provides, and confirm with your Ping administrators or support channel what can be exported and in which format. Keycloak supports built-in federation with existing LDAP and Active Directory servers, so a common pattern is to keep the directory as the source of truth and point the new platform at it, which avoids copying identities at all. The check for this step is a reconciled user count and attribute comparison between the source and the target, sampled per group.
Plan the password and MFA enrollment strategy
Before any migration, confirm with Ping whether password hashes can be exported and, if so, in which algorithm and format, because standard exports often omit them. The target must support the same hash function or the platform must be able to rehash on first login. If hashes cannot move, plan for users to set a new password through a reset flow, and decide whether existing MFA authenticators (TOTP seeds, WebAuthn credentials, push devices) can move or must be re-enrolled. Document the decision per application population, since workforce and customer users often differ. The output is a written enrollment policy that the service desk and application owners have reviewed.
Pilot with one low-risk application
Choose one application with a small, friendly user group, a non-critical function and a team that will report issues quickly. Configure the client in the target platform with the same protocol, redirect URIs, signing keys and claim mappings recorded in the inventory, then test sign-in, token contents, logout, session timeout and MFA prompts from the browser and any API clients. Run the pilot against a staging copy of the application where possible. The pilot is complete when the owner signs off on a test script covering the happy path and the failure paths, and the rollback steps have been rehearsed once.
Run both providers in parallel
Keep the application registered in Ping and in the target platform at the same time, and route a controlled set of users to the new platform through DNS, a feature flag in the application, or a separate test tenant. Compare authentication logs, failed sign-in rates, token claims and any support tickets between the two paths, and keep the Ping configuration unchanged so that rollback is a routing change. Keep the parallel period long enough to cover the application's normal business cycles, such as month-end or batch jobs, and agree the length with the owner in advance. Exit criteria should be written down before the run starts.
Cut over each application in phases
Move the application's remaining users to the target platform in waves, starting with a small share and increasing only when the exit criteria from the parallel run hold. Announce the change to users with the reset or re-enrollment steps where they apply, and keep the service desk briefed on the expected questions. Record the time of each wave, the number of affected users and any rollback events. The step is complete when all users of the application authenticate through the target platform and Ping issues no further tokens for that client.
Back up, test restore and decommission Ping
Once every application is cut over, retire the Ping configuration only after a full backup has been taken and restored into a separate environment, and the restored system has been tested for sign-in and administration. Keycloak's realm export and import commands are useful for configuration, but its documentation notes limitations as a backup and restore mechanism and requires all nodes to be stopped while it runs, so plan a backup method that covers the database, keys and secrets as well. A realm export is not a backup substitute. The step closes when the restore test passes, the audit logs are archived under your retention policy, and the owners confirm that no application still points at the legacy service.

Which Ping Identity alternative fits your situation

When identity data must stay inside a specific cloud account, data center or air-gapped network, self-hosting is usually the starting point. Keycloak and ZITADEL both run inside the client's own infrastructure, so user records, sessions and audit logs never leave that boundary. Keycloak is licensed under the Apache License 2.0, and ZITADEL is licensed under AGPL-3.0 with Apache 2.0 and MIT exceptions for specific directories, so legal review of the license terms belongs early in the decision.

Deployment footprint: ZITADEL self-hosts with Docker Compose or Kubernetes on PostgreSQL 14 or later. Keycloak has its own clustering and database requirements, which your platform team should size against the target environment.
Air-gapped operation: Confirm that every component, container image and update path can be mirrored into the isolated network before the design is fixed.
Federation to existing stores: Keycloak can federate existing LDAP and Active Directory servers, so user data can remain where it already lives.
Backups: Keycloak's realm export and import is documented as having limitations as a backup mechanism, so plan database-level backups instead.
Operations: Self-hosting moves patching, certificate management and incident response to your team or to a partner.

Before committing, confirm with each vendor which telemetry, licensing checks or update services contact external endpoints, and test that behavior in your own network.

Questions buyers ask before replacing Ping Identity

How much effort does a migration away from Ping Identity take?

The effort depends mostly on how many applications authenticate through Ping, which protocols they use, and how much customization sits in the existing policies and login flows. A migration with a small number of OIDC applications and one directory source is far simpler than one with dozens of SAML service providers, custom authentication journeys, and legacy ForgeRock-era integrations. Other drivers include the number of user stores, whether passwords must move, how many MFA methods are in use, and how well current configuration is documented. Ask your team to inventory each application's protocol, redirect URIs, claims, and session rules before estimating anything.

How long does a phased cutover from Ping Identity take?

No duration has been supplied for this migration, and no reliable timeline can be given without knowing the application count and protocol mix. A phased cutover moves one application or group of applications at a time, so the schedule is driven by how many integrations exist, how many depend on shared claims or groups, and how much testing each business owner requires. Run Ping and the new platform side by side during the transition so that rollback stays possible. Ask any provider for a schedule that lists each wave, its acceptance criteria, and the dependencies that could delay it.

What does the migration need from our internal team?

Your team needs to supply knowledge and access that only your organization holds. This includes application owners who can confirm redirect URIs, claim mappings and session behavior, directory administrators who can grant read access to LDAP or Active Directory, and security staff who approve the target architecture and hardening baseline. You will also need a named owner for MFA policy decisions and someone to run user communications before each wave. Plan for these people to be available during testing windows, since most delays come from waiting on application owners rather than from the platform work itself.

Can our internal identity team complete the migration without outside help?

A capable internal team can complete a migration without outside help if it has hands-on experience with OIDC, SAML 2.0, and directory integration, and if it has time to run a parallel environment. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and offers built-in user federation with existing LDAP and Active Directory servers, so the protocol work is well documented. The usual gaps are backup and restore procedures, upgrade planning, hardening, and evidence collection for audits. Assess these honestly against your staff's capacity before deciding whether to bring in outside support for specific parts of the work.

How should password and MFA enrollments be handled during the move?

Plan for users to re-enroll MFA and, in many cases, reset passwords, because Ping does not export password hashes in a form that a self-hosted platform can usually consume. Confirm with your Ping administrators exactly what export options your contract and deployment allow, and whether hashes can be obtained at all. For applications already using federation, you can often keep users signing in against the existing directory while the new platform sits in front of it, which reduces the number of forced changes. Communicate the enrollment steps to users before each cutover wave and keep a help desk runbook ready.

How does licensing differ between Keycloak, ZITADEL and authentik Enterprise?

Keycloak is licensed under the Apache License 2.0 and is a Cloud Native Computing Foundation incubating project. ZITADEL is licensed under AGPL-3.0, with Apache 2.0 and MIT exceptions for specific directories, which carries obligations that your legal team should review if you modify and offer the software over a network. authentik's open-source core is MIT licensed, but its enterprise directory falls under a separate authentik EE License, and the free edition offers community support only. Enterprise features such as privileged access management and Google Workspace or Microsoft Entra ID integrations sit in the paid tiers. Have counsel confirm the terms against the exact editions you intend to run.

What should a fixed-scope quote for this migration include?

A fixed-scope quote should list the applications in each cutover wave, the protocols and directory sources in scope, the target platform and deployment model, and the hardening and backup tasks included. It should also state the testing approach, the rollback plan for each wave, the training and documentation deliverables, and the client responsibilities such as access grants and approvals. Ask for the assumptions behind the estimate, including how many integrations are excluded, and what happens if discovery reveals additional applications. Scope, deliverables and timelines are agreed in writing before work starts, so request those terms explicitly. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen scopes, migrates and supports a Ping Identity replacement

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For a Ping Identity or ForgeRock replacement, we work application by application, so each federation link is tested and signed off before the next one moves.

How we scope

Inventory every SAML and OIDC application, LDAP or Active Directory source, and policy that Ping Identity serves today.
Agree the target platform choice, such as Keycloak or ZITADEL, in the written scope before any build work starts.
Record deliverables, timelines and out-of-scope items in writing, since most engagements are fixed-scope and quoted from that scope.

How we build

Stand up the self-hosted identity platform in your environment and connect it to your existing directory sources.
Rebuild federation for each application in a staging environment, then test login, logout, attribute mapping and MFA enrollment.
Plan the password and MFA re-enrollment path with your security team, since credential data often cannot move in plain form between platforms.

How we hand over

Document architecture, configuration, runbooks and the cutover order for each application so your team can operate the platform.
Prepare evidence and control records for your compliance assessment, while independent auditors and certification bodies issue any formal reports.
Walk your operations and security staff through backup, restore and upgrade procedures before the Ping Identity contract is closed.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped separately from the build.
Review each platform upgrade against your federation tests before it reaches production.
Ask any provider, including DeployOpen, to confirm in writing what support, response terms and service levels are included.

Open-source alternatives to Ping Identity