LDAP vs SAML: a directory protocol and a browser SSO protocol, compared

Short answer: LDAP is a directory protocol. It stores accounts and attributes and lets a client look them up and authenticate against them. SAML is a browser single sign-on protocol. It lets an identity provider tell an application, with a signed assertion, that a user has already signed in. LDAP answers "who exists and what do we know about them"; SAML answers "this user just authenticated, trust them".

They are not competitors. Most large organizations run both: the identity provider reads users from LDAP or Active Directory, then speaks SAML or OIDC to the applications. The confusion comes from the fact that both can be used "for login", but they do different jobs at different layers.

What LDAP does

LDAP (Lightweight Directory Access Protocol, RFC 4511) is a protocol for accessing a directory: a tree of entries, each with a distinguished name and a set of attributes.

• Bind. The client authenticates to the directory, usually with a distinguished name and password (simple bind), or with SASL.
• Search. The client queries the tree with a filter, for example all users in an organizational unit, and gets back attributes: mail, displayName, memberOf.
• Modify. Authorized clients can add, change and delete entries.

OpenLDAP, 389 Directory Server, FreeIPA and Microsoft Active Directory all speak LDAP. Active Directory is not "the same thing as LDAP": it implements LDAP, but it also adds Kerberos, DNS and Group Policy. That is why "LDAP vs Active Directory" is a separate question.

LDAP is not a web single sign-on protocol. There is no browser redirect, no signed assertion and no federation between organizations. An application that "logs in with LDAP" typically takes the username and password from its own login form, opens a bind to the directory, and keeps its own session.

What SAML does

SAML 2.0 (OASIS) is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP).

1. The user opens an application (the SP) and has no session.
2. The SP redirects the browser to the IdP with a SAML AuthnRequest.
3. The IdP authenticates the user, or reuses an existing IdP session.
4. The IdP returns a signed SAML Response containing an assertion about the user, usually through the browser with an HTTP POST.
5. The SP verifies the signature and the conditions, then starts its own session.

The IdP and SP trust each other through metadata and certificates. SAML does not store users; it asks the IdP. It also does not replace LDAP: the IdP still needs a user store, and that store is often LDAP or Active Directory.

LDAP vs SAML at a glance

LDAP vs SAML vs OAuth and OIDC

People often search for "LDAP vs SAML vs OAuth" as if they were three ways to do the same thing. They are three layers:

So the practical rule is: if you are choosing how a user signs in to an app, the choice is SAML or OIDC. If you are choosing where the accounts live, the choice may be LDAP, Active Directory or the IdP's own database. OAuth alone is not a login protocol; it is the authorization layer under OIDC.

How LDAP and SAML work together

The common enterprise architecture has three layers:

1. Directory. Active Directory or OpenLDAP holds the accounts, groups and attributes, and is often the system of record for joiners, movers and leavers.
2. Identity provider. Casdoor, Keycloak, Entra ID or another IdP syncs users from the directory, adds MFA, sessions and application assignments, and speaks SAML or OIDC to applications.
3. Applications. The apps trust the IdP. Most never talk to LDAP at all.

This split is why "move off LDAP" rarely means "remove the directory". It usually means "stop letting every app bind directly to the directory, and let the IdP broker authentication instead". The directory stays; the direct binds go away.

Some systems still need LDAP: VPN concentrators, network devices, older Java applications, and tools that only support a directory bind. For those, keep LDAP available, but put it behind the same governance as everything else. Casdoor, for example, can act as an LDAP server as well as a SAML and OIDC identity provider, so an application that only speaks LDAP can still be covered by the same user store and policies.

When to use each

Use LDAP when:

• the application only supports a directory bind and cannot do SAML or OIDC,
• you need a central directory for internal systems, not browser SSO,
• you are synchronizing users into an identity provider,
• the client is a VPN, a network device or an operating system login.

Use SAML when:

• an enterprise customer requires SAML for their users,
• the application is a SaaS product that supports SAML but not OIDC,
• you need browser SSO with signed assertions and a familiar metadata exchange,
• you are federating with another organization.

Use OIDC when:

• you are building a new web, mobile or single-page application,
• you want a JSON token and modern libraries,
• you need the same login across your own apps and APIs.

Common misconceptions

"LDAP is single sign-on." Not by itself. LDAP authenticates a bind; each application still creates its own session. You can build SSO on top of LDAP, but that is the application's or the IdP's job.

"SAML replaces LDAP." No. SAML is the protocol between the IdP and the app. The IdP still needs a user store, which is often LDAP or AD.

"LDAP is insecure." Simple bind without TLS sends the password in the clear, which is insecure. LDAPS on port 636 or StartTLS on 389 fixes the transport, and SASL or certificate-based bind can avoid passwords entirely. The protocol is not the problem; the deployment is.

"We need one or the other." Most organizations need both, at different layers. The question is which systems are allowed to talk to which layer.

FAQ

Is LDAP a type of SSO? No. LDAP is a directory access protocol. It can be the user store behind an SSO system, but it does not provide browser SSO by itself.

Can SAML use LDAP as the user store? Yes. The identity provider reads users from LDAP or Active Directory, then issues SAML assertions to applications. The application never talks to LDAP.

Which is more secure, LDAP or SAML? Neither is inherently more secure. SAML avoids sharing passwords with each application and gives you a central place for MFA and policy. LDAP simple bind over plaintext is unsafe; use LDAPS or StartTLS. The deployment matters more than the protocol name.

Do I need LDAP if I already have SAML? Only for applications that cannot use SAML or OIDC. If every application supports SAML or OIDC, you can keep the directory behind the IdP and stop exposing LDAP to applications.

What about Active Directory? Active Directory speaks LDAP, but it is a broader product. If your question is specifically AD, see Active Directory alternatives and Kerberos vs LDAP.

If you need a directory and a SAML/OIDC identity provider in one place, Casdoor can serve both roles, and its pricing starts at a flat monthly price rather than a per-user fee. For the protocol side, see what SAML is, SAML SSO and LDAP authentication.