Keycloak vs authentik for LDAP: which direction do your legacy apps need?
Keycloak federates users from an LDAP or Active Directory directory, while authentik's LDAP provider exposes its users to LDAP-only applications. That difference in direction decides where user accounts live. A team whose legacy apps speak only LDAP and must keep working has to answer one question first: do those apps need to bind to the directory where people already exist, or can they bind to a new one? If your HR-fed directory is the source of truth, Keycloak lets you keep it there and place modern single sign-on in front of it. If the accounts should move into the identity provider, authentik can serve them to LDAP clients.
Confirm the details for each application before choosing. For every LDAP-dependent app, record the bind method, the search base and filters it uses, whether it writes attributes or group memberships, and any object classes or schema it expects. Then check the directory side: which product holds the users today, who owns password changes and account lockout, and whether those rules must stay in that directory. Keycloak's server administration guide covers its user federation settings, which is where you should verify whether federated users and attributes meet each app's needs. Confirm the authentik LDAP provider's bind and attribute behavior in its documentation and in a test environment.
Keep a separate directory in the design if any of these apply: an application can only read from the directory it already binds to, other systems depend on that directory for purposes outside this comparison, or your joiner, mover and leaver process runs there. In those cases, the open question is which system is the authority for passwords, MFA and provisioning, not which product offers LDAP. Ask your identity team to document that decision and test one representative application against a non-production bind before you commit. Treat any answer you cannot confirm for your own apps as an open risk, not an assumption.
How Keycloak and authentik handle LDAP in each direction
This table compares how Keycloak and authentik fit an LDAP or Active Directory estate. Keycloak reads users from a directory, while authentik serves its own users to LDAP-only applications. Read each row by asking where accounts live and which direction your legacy apps need, and confirm the marked items with each vendor.
| Aspect | Keycloak | authentik |
|---|---|---|
| LDAP direction | Federates users from an LDAP or Active Directory directory into Keycloak | LDAP provider exposes authentik users to applications that bind to it over LDAP |
| Where accounts live | Accounts stay in the directory and Keycloak reads them. Confirm where password checks happen for your setup | Accounts and configuration live in authentik's PostgreSQL database. Confirm how LDAP binds are verified for your sources |
| Protocols served | OpenID Connect, OAuth 2.0 and SAML 2.0 to applications. LDAP is a user source, not a served protocol | OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy provider types |
| Database and runtime | Relational database required in production, including PostgreSQL 14 to 18, MariaDB, MySQL, SQL Server, Oracle and Aurora PostgreSQL | Server container with embedded outpost, a worker container and PostgreSQL. Redis is no longer used since 2025.10 |
| High availability | Three documented designs, and both supported designs need a synchronously replicated database | Confirm outpost placement and high availability layout for your environment with the vendor |
| Editions and license | Upstream project is Apache-2.0. Red Hat build of Keycloak is a separate supported distribution | Core is MIT. Code under authentik/enterprise needs a paid subscription for production use |
| Paid pricing | Upstream Keycloak has no paid edition in the supplied facts. Confirm support options with the vendor or distributor | Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, per the authentik pricing page |
| Connecting an existing directory | Configure a user federation provider with connection and attribute mapping, then test in a non-production realm | Create an LDAP provider and application, then point LDAP clients at the outpost. Confirm bind and search settings with the vendor |
| Is a separate directory still needed? | Yes, if the directory remains the source of truth for accounts that Keycloak reads | Yes, if other systems still depend on the directory, since authentik holds its own user store |
When each direction fits your legacy apps
When a legacy application binds to an LDAP server and cannot be modified, the question is which product can answer that bind. The authentik LDAP provider exposes users to applications like this, so authentik can serve as the directory endpoint the app talks to. Keycloak works in the other direction: it federates users from an LDAP or Active Directory directory and handles web logins, so it does not by itself give a bind-only application a directory to query. This tab fits when the application's configuration is fixed and everything around it can move.
- Direction that fits: the authentik LDAP provider, which presents users to the application.
- Condition that matters: the application needs only bind and search against a directory, not SAML or OIDC.
- Keycloak's role: usually upstream, federating from an existing directory for web sign-in.
- Confirm: the exact LDAP operations, attributes and group checks the application performs, as described in the authentik provider documentation.
- Confirm: that the application tolerates the schema and group structure the provider presents in the version you deploy.
Test the application's bind and group queries in staging before cutover, because a mismatch found after go-live is costly to fix.
If Active Directory or another LDAP directory must remain the source of truth for accounts, passwords and group membership, Keycloak's federation model fits. Keycloak reads users from that directory, so HR and directory administrators keep their existing processes. The authentik LDAP provider works differently: it presents users from authentik's own store to LDAP clients, so using it as the front door tends to make authentik the place where accounts are managed. That conflicts with a directory that other teams already own.
- Direction that fits: Keycloak LDAP or Active Directory user federation.
- Condition that matters: the directory owner must stay the system that creates and disables accounts.
- Trade-off to weigh: federated users still need Keycloak-side configuration for roles, clients and sessions.
- Confirm: whether Keycloak needs read-only or write access to the directory, and how often it imports and synchronizes users, as set out in the Keycloak server administration guide.
- Confirm: where password validation happens and how group and attribute mappings will be maintained.
Write down which system owns each attribute before deployment, since two directories that both claim ownership produce drift.
When the applications are new and speak OpenID Connect, OAuth 2.0 or SAML 2.0, the legacy LDAP question matters less. Keycloak supports those protocols, offers an admin console and fine-grained authorization services, and is licensed under Apache-2.0. authentik also covers OAuth2/OIDC, SAML and proxy providers, and its core is MIT licensed. The difference that often decides the choice is edition: authentik code under its enterprise directory is covered by a separate license and needs a paid subscription for production use, which includes the Google Workspace and Microsoft Entra ID integrations.
- Keycloak fit: a single platform for web SSO, brokering to external OIDC or SAML providers, and administration through its console.
- Keycloak database: a relational database is required in production, with PostgreSQL 14 to 18 among the supported options.
- authentik fit: a lighter Python-free footprint of server and worker containers backed by PostgreSQL, with proxy and RADIUS providers.
- Condition that matters: if you need Entra ID or Google Workspace integration, the authentik Enterprise license applies.
- Confirm: which protocols each application requires and which integrations your identity provider must support in the chosen edition.
Many estates have modern applications and legacy LDAP clients at the same time. A common pattern keeps the directory authoritative, lets Keycloak federate it for modern apps, and uses the authentik LDAP provider only for the applications that cannot change. This works when each identity question has one clear owner. It becomes fragile when two products both decide who is active, which groups apply, or where a session ends. The pattern is an architecture choice, not a verdict on either product.
- Direction that fits: Keycloak federation for web apps, with authentik's LDAP provider limited to bind-only clients.
- Condition that matters: each attribute and group must have one documented source of truth.
- Operating effort: two platforms mean two upgrade cycles, so check supported lines before scheduling work. Per the authentik security policy, 2026.5.x and 2026.8.x receive security fixes.
- Upgrade behavior: Keycloak minor releases make breaking changes opt-in, which should be confirmed against your version.
- Confirm: which system handles MFA, session lifetime and account disablement for each application group.
Document the mapping of applications to systems before deployment, and review it whenever either product changes its supported versions.
What changes the LDAP result in practice
The LDAP question rarely has one answer. Five or six factors decide whether a team needs a provider that exposes users to legacy apps, a federation layer that reads an existing directory, or a separate directory alongside either. Work through each card before you compare feature lists.
Bind or OIDC and SAML
Check whether each legacy app performs simple LDAP binds against a directory, or whether it can be moved to OIDC or SAML. Apps that can switch protocols reduce the role of LDAP entirely, which narrows the decision. Apps that only bind need a service that answers LDAP requests, and authentik's LDAP provider is built for that case. Ask each application owner which protocols the software supports and whether a vendor upgrade is planned.
Active Directory or another LDAP server
Identify the directory that holds users today. If it is Active Directory, Keycloak can federate users from it, so the directory stays the source of identity. If the users sit in a different LDAP server, confirm which schema, bind account and search base the apps expect. Do not assume that a federation or provider feature will map every attribute your applications read. Test a sample account against each candidate before you commit.
Who owns passwords and lifecycle
Decide where passwords are changed, reset and locked, and who creates and removes accounts. With Keycloak federation, the directory usually keeps the password and Keycloak reads from it. With an authentik LDAP provider, authentik becomes the place where users and their credentials are managed for the apps that bind to it. Confirm with your identity team which system is the authoritative source, because two systems that both accept changes produce drift.
Number and bind patterns of legacy apps
List every legacy app with its bind method, search pattern and whether it reads group membership. A few apps with one service account are a small change. Many apps with different bind accounts, nested group lookups or hard-coded attributes need more mapping work and more testing. Ask each vendor for its supported LDAP behavior, and run a test bind from each app before you choose a path.
Database and runtime skills
Both platforms store their state in PostgreSQL. Keycloak needs a relational database in production, and its supported list includes PostgreSQL 14 to 18 alongside MariaDB, MySQL, Microsoft SQL Server, Oracle Database and Amazon Aurora PostgreSQL. authentik runs as a server container with an embedded outpost plus a worker container, all backed by PostgreSQL. Confirm which database engines and container or Kubernetes skills your team already runs, because the operating burden follows those skills.
Edition needed for required features
Check every feature the project needs against the license terms before you design around it. authentik core is MIT licensed, but code under authentik/enterprise needs a paid subscription for production use, and the pricing page places features such as Microsoft Entra ID integration, mTLS and enhanced audit logging in the Enterprise tier. Ask the vendor which features are in each edition, what the subscription covers, and whether the license terms allow your intended production use.
When a separate directory is still needed
Neither Keycloak nor authentik replaces a directory when the directory is the system of record for accounts, groups and computer objects. Keycloak federates users from LDAP or Active Directory, and authentik's LDAP provider exposes its own users to legacy applications, so in both cases the identity platform reads or serves identities rather than owning the authoritative copy. If your HR feed, group policy, or device management already depends on an existing directory, that directory stays the source of truth and the SSO or LDAP layer sits in front of it. Active Directory Domain Services is a Windows Server role that stores users, computers and other objects, replicates directory data to every domain controller in a domain, and provides a schema and global catalog. Where that role is in place, plan for it explicitly: confirm which attributes your legacy apps read, whether nested group membership is evaluated by the application or by the directory, and which domain controllers your platform will bind to. Windows Server 2025 is the current Windows Server release, and the Windows Server 2025 lifecycle page lists its support end dates, which belong in your planning.
FreeIPA is the other common case. As its project describes, it combines a 389 Directory Server LDAP directory, an MIT Kerberos KDC for single sign-on and a Dogtag certificate authority, so it can cover Linux host identity, Kerberos and certificates in one platform. If your legacy estate needs Kerberos or certificate issuance, neither Keycloak nor authentik provides that role, and you should evaluate a directory like FreeIPA as a separate component. Confirm in your own environment how schema extensions, group membership and replication are handled between any directory and the identity layer, and test a password change and a group removal end to end, since a stale replica or an unmapped group can grant or block access without any error in the application.
How to test LDAP compatibility before you commit
This sequence shows whether each legacy application can bind, search and authenticate against each candidate, and how identity changes travel between the directory and the platform. The output is a tested record of what works in each direction, which you can use to decide before any purchase.
Inventory every legacy application and its bind method
The application owner and the platform engineer list each legacy app that touches LDAP, including batch jobs, appliances and scripts that nobody has documented recently. For each one, record whether it binds with a service account or with the end user's credentials, whether it uses LDAPS or StartTLS, and whether it only reads or also writes. The step is complete when every app has a row in a shared inventory and every row has an owner who has confirmed the bind method.
Record bind DN, search base and attributes per app
For each inventory row, capture the exact bind DN, the search base, the search filter and the attributes the app reads, such as the login name, mail, memberOf or the group attribute it expects. Pull these values from the application configuration files or admin screens, not from memory. The output is a per-app LDAP contract that a tester can replay against a lab directory. Note any app that hard-codes an attribute name, because that drives the mapping work in later steps.
Build a lab instance of each candidate platform
The platform engineer deploys a non-production instance of Keycloak and of authentik in an isolated network, using the vendor installation documentation and a production-grade database rather than a development file store. Load a copy of the directory data or a representative test directory into each one. The step is complete when each lab instance starts cleanly, the database is reachable, and the admin console or API responds. Keep a record of the versions and configuration used, since edition and version details affect what you can test.
Test one non-production app in each direction
Configure one low-risk legacy app against the lab directory exposed by the candidate, then test the reverse path for the same app: an identity from the platform's own or federated store used to reach the app. For Keycloak, check user federation from the LDAP or Active Directory source. For authentik, check that its LDAP provider exposes users to the app's bind. Record which direction each product supports for that app, and whether the app can authenticate a user with a correct password and reject a wrong one. Do not count a successful bind as proof of authorization.
Verify group-based access for each test user
Create test users in at least two groups that map to different app roles, then sign in to the app as each user. Confirm that membership changes made in the source directory are reflected in the app after the sync or lookup interval you configured, and that a user removed from the group loses access. Record any app that expects a nested group attribute or a specific group format, since many legacy apps read membership differently from how the platform publishes it. The output is a pass or fail table for each group and role.
Check password change and account disablement propagation
Change a test user's password in the source directory, then attempt a login through the app with the old and the new password. Repeat the test with the account disabled or locked in the source. Note whether each candidate caches credentials, how long a session survives after disablement, and whether the app keeps a local copy of the user. Write down the observed behavior, since it determines how quickly offboarding takes effect. Confirm the expected behavior with the vendor documentation before relying on it.
Confirm edition-gated features with the vendor before purchase
List every feature your tests depended on, such as LDAP provider support, directory integrations, audit logging, and support tiers, then check each against the current edition documentation of each vendor. authentik's enterprise-only features are listed on its pricing page, and Keycloak's feature coverage should be confirmed against its current documentation for your target release. Ask each vendor, in writing, which edition or subscription includes each feature you need and what the license terms are for your deployment. The step closes when you hold written answers for every dependency, and any gap is reflected in the scope of your quote.
What the license and edition lines mean for LDAP deployments
The license lines settle the server cost, but they do not settle the LDAP question on their own. Keycloak is licensed under Apache-2.0, and its LDAP support is user federation: Keycloak reads users from an LDAP or Active Directory directory, so the directory remains the source of record. authentik core is MIT licensed, but code under authentik/enterprise is governed by the authentik Enterprise Edition license and needs a paid subscription for production use. That split matters here because authentik's LDAP provider is the component that exposes users to your legacy applications. Before you design around it, read the repository's license file and the enterprise directory, and confirm which provider code your deployment would actually load.
The authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, with Enterprise Plus starting at $20k annually. Its enterprise-only list names Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management and enhanced audit logging, but it does not name LDAP. Do not read that silence as a yes or a no. Ask the vendor in writing whether the LDAP provider you plan to use is part of the open source edition, which source files contain it, and whether any LDAP behavior you rely on, such as group handling or bind settings, sits behind the enterprise license. Get the answer for the version you will deploy, because a pricing page is a point-in-time document.
Plan cost in two parts. Keycloak's server carries no license fee under Apache-2.0, so its recurring cost is the production database, the hosting, and the staff time to patch and upgrade it. authentik's cost depends on whether your LDAP feature requires the enterprise license. If it does, the subscription recurs and is driven by the number of users and external users, so those counts are the main lever. Under either product, one-time work includes mapping LDAP attributes and groups, testing how each legacy application binds and searches, and planning cutover. Ask any implementation partner, DeployOpen included, for a fixed-scope written quote that names the deliverables, the directories in scope and the support terms. Ask authentik for the subscription tier, how external users are counted, and whether support covers the LDAP provider.
Questions buyers ask about LDAP with Keycloak or authentik
Can Keycloak serve LDAP to legacy apps that only speak LDAP?
The documented LDAP capability for Keycloak is user federation: it reads users from an LDAP or Active Directory directory and lets them sign in through OpenID Connect, OAuth 2.0 or SAML. The supplied material does not show Keycloak exposing its own users to LDAP clients, so confirm that in the Keycloak server administration guide before you design around it. If your legacy apps need an LDAP bind target, plan for one of two paths: keep the existing directory as that target and let Keycloak federate from it, or add a component that serves LDAP, and test it with the exact bind and search patterns each app uses. Modern apps can move to OIDC or SAML through Keycloak in parallel.
Can authentik read users from an existing Active Directory?
The documented authentik LDAP provider works in the other direction: it exposes users that authentik manages to applications that speak LDAP. Reading users from an external Active Directory into authentik is a separate question, and the supplied material does not confirm a generic AD source for the core edition. The Enterprise-only feature list names Google Workspace and Microsoft Entra ID integrations, which is not the same as a general directory source. Check the authentik providers documentation and test the exact sync you need against a copy of your directory before you commit to the design.
How much effort does a directory connection take?
The effort depends on how many directories you connect, how many applications bind to them, and how cleanly your attributes and groups map. The main work items are the service account and its permissions, TLS for directory traffic, attribute and group mapping, the sync or lookup schedule, and cutover testing for each application. One-time work covers design, mapping, testing and cutover. Recurring work covers monitoring, patching both the identity server and its database, and handling schema or group changes when HR or AD administrators change how they structure data. Ask any implementation partner for a written breakdown of these items against your actual applications.
What drives the cost of an LDAP integration project?
Cost has three parts: software licensing, infrastructure and people. Keycloak is licensed under Apache-2.0, so the software itself carries no license fee. authentik's core is MIT licensed, but its pricing page lists an Enterprise edition at $5 per user per month billed annually plus $0.02 per external user per month, and an Enterprise Plus edition starting at $20k annually. Infrastructure covers a production database and redundant hosts. People costs cover design, integration, testing and ongoing operations, whether in-house or from a partner. DeployOpen does not publish a price list. Engagements are fixed-scope, so a quote follows from a written scope that names the directories, applications and deliverables.
Can our in-house team run this integration without outside help?
Your team can run it if it already operates a relational database, container platforms and directory administration well. Keycloak needs a relational database in production, and its Operator is installed through the Operator Lifecycle Manager, which Keycloak recommends, or with kubectl. authentik runs as a server container with an embedded outpost plus a worker container, and stores its configuration in PostgreSQL. Since release 2025.10, authentik no longer uses Redis, and its release notes warn of roughly 50% more PostgreSQL connections after upgrading, so plan database capacity first. Run a pilot with one application and one directory before you commit. DeployOpen plans, implements and supports self-hosted platforms, and a written scope can cover the parts your team does not want to own.
Does a separate directory still make sense with an identity provider?
Often it does. A separate directory such as Active Directory, OpenLDAP or FreeIPA remains the source of record when HR, endpoints and other systems already depend on it. In that model, Keycloak federates users from the directory and handles SSO for modern apps, while authentik's LDAP provider can serve bind requests for legacy apps. Keep the directory if group membership, password policy or device management lives there. A directory alone may be enough when the only need is LDAP for a few legacy apps, with no SSO or MFA requirement. Decide the authoritative source for each attribute before you connect anything, because two systems writing the same attribute creates drift.
Which licensing terms should we review before choosing between them?
Start with the license of the exact components you will deploy. Keycloak is licensed under Apache-2.0. authentik's core is MIT licensed, but code under authentik/enterprise is covered by the authentik Enterprise Edition license and needs a paid subscription for production use. If your design depends on enterprise directory features, the subscription becomes part of the architecture and the total cost. Confirm the license terms in the authentik LICENSE file and have your legal or procurement team review the subscription terms, support scope and any obligations that apply when you modify or redistribute the software.
How DeployOpen works on this
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an LDAP decision, we start by mapping which legacy apps need LDAP and which direction of user flow each one requires, then build and hand over the chosen design.
How we scope
- We inventory which legacy applications need an LDAP bind and which need a directory they can query.
- We confirm where the source of truth for users and passwords lives, including any Active Directory domains.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen platform in your environment, with the production database your chosen platform supports.
- We configure LDAP federation or the LDAP provider and test bind, search and group mapping with each legacy app.
- We run security testing on the LDAP-facing services and document the findings and remediation steps.
How we hand over
- We document the directory design, connection settings, backup and upgrade procedures in your own environment.
- We walk your operations and identity teams through the runbooks and the decision record behind the design.
- We prepare configuration and evidence for compliance assessments, while independent auditors issue any reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover upgrade planning for LDAP connectors, including checks against each release's notes.
- You receive a quote that follows from the written scope, since DeployOpen does not publish a price list.
