SAML vs. LDAP: How to Choose The Right Protocol
In this article, we’ll give you a quick overview of which protocol you should pick for your situation.
In this article, we’ll give you a quick overview of which protocol you should pick for your situation, then dive into the details of exactly what each protocol does, what you can use them for and how they can be used together.
SAML vs LDAP: Which protocol should you use?
SAML and LDAP are both open, widely adopted protocols used to securely share information. SAML focuses purely on authentication information, but LDAP covers both authentication and wider directory resource information (e.g. printers and servers on a network).
Use SAML if: You have a cloud-based SaaS app into which you want to control access and authorization with Single-Sign On (SSO).
Use LDAP if: You are deploying software on-premise and behind a firewall and want the most straightforward authentication method, or want users to specifically access local network resources.
Use both SAML and LDAP together if: You want cloud-based authentication via SAML, but want to access user directory information specifically stored on an LDAP instance, and use that LDAP instance to act as an identity provider (idP) platform for a SAML-based authentication flow.
Read more:
What is SAML
Security Assertion Markup Language, more commonly known as SAML, is a standardized protocol for exchanging authentication data between two parties: the identity provider (like Okta or Ping), and the service provider (e.g. a SaaS application).
SAML works via the exchange of assertions - XML-based documents containing authentication information, authorization/permission information and even user profile attributes (like their full name, email address or a profile picture URL).
This exchange lets users sign into multiple applications using just a single login session - otherwise known as Single Sign-On (SSO). Specifically, SAML streamlines access to various applications by passing user data between the SAML service provider and an identity provider.
This is how it typically works:
- First, the user initiates a process to access a service. The service provider intercepts this request and redirects the user to the identity provider.
- Next, the identity provider takes over the reins. It verifies the user's identity, and then formulates SAML assertions that hold information about the authenticated user.
- Finally, these SAML assertions are then transferred back to the service provider, which validates them and subsequently logs the user into the system.
SAML offers an effective alternative to other methods of user authentication like OAuth or OIDC. It enables diverse applications to share authentication data, removing the need for separate user sign-ins when trying to navigate across different systems and applications.
What SAML is great at
- It’s easy to implement: SAML is a standardized, XML-based protocol and while it’s not as easy to implement as RESTful API authentication methods, it’s well-understood with a plethora of pre-made libraries and integrations already available.
- It’s optimized for cross-domain authentication: Unlike LDAP which is optimized for working within a specific domain (e.g. a single enterprise company), SAML is specifically designed for allowing web-based authentication between different services and separate domains. This is ideal for connecting cloud-based apps to corporate domains.
- It’s flexible across IdPs: SAML works similarly across all major identity providers. It’s easy to repeat the same service provider integration across multiple different identity providers.
What SAML is not so great at
- It’s not a directory protocol: While LDAP can work on various types of information, like user accounts, network resources and individual devices, SAML is a simpler, transactional protocol which is designed to handle authentication information only.
- It’s not a real-time protocol: SAML assertions are shared on a login event only. This means that a user’s access to a resource can be revoked by their administrator, but the authorization change won’t take effect on the target app until the user relogs. This isn’t great for securing sensitive data, but can be mitigated when paired with SCIM provisioning.
What is LDAP?
LDAP, or “Lightweight Directory Access Protocol”, is a protocol used for accessing directory services and using or maintaining the directory resources (“entries”). It’s typically used by companies to facilitate access to services like Azure Active Directory (now known as Microsoft Entra ID).
Those directories store information on employee accounts, network resources (like printers or file shares) and physical devices (like phones or laptops). LDAP allows clients to perform actions like searching the directory for specific entries, creating new entries or editing/updating existing entries.
LDAP is a TCP/IP-based protocol, which works by hosting an LDAP server and then allowing LDAP clients to connect to it. For example, an employee using a desktop computer might be using LDAP under the hood to connect to the nearby office printer.
While LDAP is primarily designed for accessing resources across the network, it necessarily has authentication capabilities built-in to allow secure access to these resources. This means that LDAP can function as an intermediary identity provider service between an app and Microsoft Active Directory (where authentication and authorization information can be stored).
What LDAP is great at
- It provides wider access to directory services: Unlike SAML which is broadly “just” an authentication protocol, LDAP has a much broader scope and is able to perform CRUD-style actions on directory entries.
- It excels at on-premise authentication: LDAP is specifically designed to be great at on-premise authentication where a directory service is present, as opposed to SAML which is better-equipped to handle a wider array of cloud-based authentication options.
- It’s incredibly mature: Having been developed in the early 1990s, LDAP is an incredibly mature and battle-tested protocol with extensive, in-depth support - especially on legacy systems that may still be in use at enterprise companies.
What LDAP is not so great at
- Cross-Domain Authentication and Access: LDAP’s protocol is not particularly browser-friendly, lacks token-based authentication and is usually associated with a single directory rather than supporting multiple different IdPs.
- It’s difficult to implement vs SAML: Owing to being an older and broader protocol, LDAP is more complicated to implement than SAML, with more steps required, a client-server architecture to manage and less adoption on modern platforms like Node.
What can you use SAML and LDAP for?
Both of these protocols can be used for very similar purposes:
- Authentication: Both protocols allow user access credentials and access levels to be verified from a central source.
- Single Sign-On: Both protocols can allow users to log in once, and then access multiple different services or apps.
- Secure Resource Access: Both protocols can facilitate tight, granular access to secure systems or physical resources (like printers).
While all three of these use cases are supported by both protocols, SAML excels at enabling these in cross-domain, cloud-based scenarios, whereas LDAP excels in homogeneous, singular environments. LDAP also has much stronger support for non-identity resources.
Frequently asked questions about SAML and LDAP
Can you use SAML and LDAP together?
Yes. SAML is a protocol for sharing assertions - objects with authentication and identity information - between a service provider (e.g. a third-party app) and an identity provider.
LDAP can work with SAML by acting as an IdP, bridging the gap between the service provider and a directory service which stores identity and authentication information. If useful, an enterprise company could configure their LDAP server to act as this IdP rather than using an additional service like Microsoft Entra or Okta.
Which is better, LDAP or SAML?
It depends on your use case.
If you want to support SSO from a cloud-based app to one or more enterprise identity providers, SAML is going to be the better choice thanks to its built-in security, its web and browser compatibility and the ubiquitous support it enjoys from major corporate identity providers.
If you're looking to authenticate users into an app or service deployed on-premise, LDAP provides a fast, convenient and featured way to do this.
Overall, these protocols are not directly comparable - It really depends on exactly what you’re trying to achieve.
What’s the difference between LDAP and SSO?
LDAP and Single Sign-On (SSO) are distinct concepts but can complement each other in identity and access management:
Single Sign-On (SSO) allows users to authenticate once and gain access to multiple services or apps. In a typical SSO flow (often powered by SAML), a user will log in to their employer’s identity provider platform, which will then assert that user’s identity to other apps or services.
LDAP might be used during the initial login within an SSO scenario to communicate with the employer's directory service. LDAP authenticates the user against the directory service, verifying their credentials.
After authentication, LDAP can also provide authorization information, specifying the user's access rights to network resources. This may include file shares, applications, and physical devices.
Note that LDAP and SSO can function completely independently. LDAP is not a prerequisite for SSO, and vice versa. These two concepts can work together to provide a comprehensive identity management solution, but each can be implemented on its own to address specific authentication and authorization needs.
Next steps
If you’d rather not worry about which protocols you need to support to onboard your next enterprise customer, explore using a done-for-you authentication service like WorkOS:
- Get Started Fast: With SDKs for every popular platform, and Slack-based support, you can implement SSO in minutes rather than weeks.
- Avoid The Back-And-Forth: WorkOS’ Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
- Pricing That Makes Sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they bring 10 or 10,000 users to your app.