The Identity Protocol Landscape
Every Zero Trust implementation depends on a reliable identity stack, and the choice of authentication and federation protocols shapes the architecture’s flexibility, security posture, and operational complexity. Three protocols dominate enterprise identity: OIDC (OpenID Connect), SAML (Security Assertion Markup Language), and LDAP (Lightweight Directory Access Protocol). Each was designed for a different era and use case, and understanding their strengths, limitations, and appropriate deployment contexts is essential for building a coherent identity architecture rather than an accidental collection of incompatible integrations.
LDAP: The Legacy Directory Protocol
LDAP, defined in RFC 4511, is a directory access protocol — not an authentication protocol, despite decades of being used as one. LDAP provides a hierarchical data store for identity information (users, groups, organizational units) and a query interface for retrieving and modifying that data. Active Directory, OpenLDAP, and 389 Directory Server are the most common LDAP implementations.
How LDAP Authentication Works
LDAP “authentication” is actually an LDAP bind operation. The application receives a username and password from the user, constructs a distinguished name (DN) such as “cn=jsmith,ou=engineering,dc=example,dc=com”, and performs a bind operation against the LDAP server with the DN and password. If the bind succeeds, the user is authenticated. The application then queries LDAP for group membership and attributes to make authorization decisions.
This model has fundamental limitations for Zero Trust. The application must receive the user’s plaintext password to perform the bind — there is no token-based delegation. LDAP has no concept of SSO; each application performs its own bind, requiring the user to enter credentials repeatedly. There is no standardized way to enforce MFA through LDAP alone. Session management is application-specific, with no protocol-level session handling. And LDAP traffic, while encryptable via LDAPS (LDAP over TLS) or StartTLS, was historically deployed unencrypted on many networks.
When LDAP Still Makes Sense
- Backend directory store: LDAP remains an excellent backend for storing identity data that your IdP queries. Active Directory as an identity source for Azure AD or Okta is a standard pattern.
- Legacy application integration: Older enterprise applications (on-premises ERP systems, network appliances, RADIUS servers) may only support LDAP. Plan to front these with an identity-aware proxy or SSO gateway rather than expanding LDAP-based authentication.
- Linux system authentication: SSSD (System Security Services Daemon) on Linux systems uses LDAP for user lookup and Kerberos for authentication, providing centralized identity for server fleets.
SAML 2.0: Enterprise Federation Standard
SAML 2.0, ratified in 2005 by OASIS, was designed to solve the SSO problem for web applications. It uses XML-based assertions exchanged between an Identity Provider (IdP) and a Service Provider (SP) to convey authentication and authorization information. SAML introduced the concept of federated identity — a user authenticates once at the IdP and receives a signed assertion that the SP trusts, eliminating the need for the SP to manage credentials directly.
SAML Authentication Flow
In the SP-initiated flow (the most common pattern), a user navigates to a service provider application. The SP generates a SAML AuthnRequest and redirects the user’s browser to the IdP’s SSO endpoint. The IdP authenticates the user (via password, MFA, certificate, or any configured method), generates a SAML Response containing a signed Assertion with the user’s identity attributes and group memberships, and redirects the user back to the SP’s Assertion Consumer Service (ACS) URL. The SP validates the XML signature against the IdP’s certificate, extracts the assertion, and creates a local session.
SAML Strengths and Weaknesses
- Strengths: Mature ecosystem with support across virtually all enterprise SaaS applications. Strong security model with XML digital signatures and encryption. IdP-initiated and SP-initiated flows. Attribute statements can convey rich authorization data. Well-understood by enterprise security and compliance teams.
- Weaknesses: XML-based — verbose, complex to parse correctly, and historically prone to XML signature wrapping attacks and canonicalization vulnerabilities. Designed for browser-based flows — poorly suited for mobile applications, SPAs (Single Page Applications), and API authentication. No native support for refresh tokens or incremental consent. Configuration requires exchanging metadata XML files, which is error-prone at scale.
OpenID Connect: The Modern Standard
OpenID Connect (OIDC), finalized in 2014, is an identity layer built on top of OAuth 2.0. Where SAML uses XML assertions, OIDC uses JSON Web Tokens (JWTs) — compact, URL-safe, and easily parsed by any modern programming language. OIDC was designed from the ground up for modern application architectures including SPAs, mobile applications, and API-driven microservices.
OIDC Authentication Flow
In the Authorization Code flow with PKCE (Proof Key for Code Exchange, pronounced “pixie”), the client application redirects the user to the IdP’s authorization endpoint with a code challenge derived from a random code verifier. The IdP authenticates the user and returns an authorization code to the client’s redirect URI. The client exchanges the authorization code and the original code verifier for an ID Token (a JWT containing identity claims), an Access Token (for API access), and optionally a Refresh Token (for obtaining new access tokens without re-authentication). The client validates the ID Token’s signature using the IdP’s published JSON Web Key Set (JWKS), verifies the claims (issuer, audience, expiration), and establishes a session.
Why OIDC Is the Default Choice for New Deployments
- JSON-native: JWTs are compact, easy to parse, and well-supported across all platforms. No XML parsing vulnerabilities.
- API-friendly: Access tokens are designed for API authentication. Include them in the Authorization header, and your API gateway or service mesh validates them against the IdP’s JWKS endpoint.
- Dynamic discovery: OIDC providers publish a .well-known/openid-configuration endpoint that clients auto-discover, eliminating manual metadata exchange.
- Refresh tokens: Enable long-lived sessions with short-lived access tokens. The access token expires in minutes, but the refresh token (stored securely) obtains a new access token without user interaction.
- Scopes and claims: Fine-grained consent model where applications request only the identity information they need (openid, profile, email, custom claims).
Decision Framework: Choosing the Right Protocol
The choice between OIDC, SAML, and LDAP depends on the application type, the existing identity infrastructure, and the target architecture.
- New web applications and APIs: OIDC is the default choice. It provides modern token-based authentication, API authorization, and the flexibility to support web, mobile, and machine-to-machine flows from a single integration.
- Enterprise SaaS integration: Many established SaaS applications support SAML but not OIDC. Salesforce, Workday, and ServiceNow have mature SAML integrations. Use SAML where required by the SP, but prefer OIDC when both are available.
- Kubernetes and cloud-native: OIDC is the standard. Kubernetes API server natively supports OIDC token validation. Service meshes (Istio) validate JWTs for east-west traffic authentication. Workload identity federation (GCP, AWS, Azure) uses OIDC token exchange.
- Legacy on-premises applications: LDAP may be unavoidable for applications that cannot be modified. Deploy an SSO gateway (Keycloak, Azure AD Application Proxy) that authenticates users via OIDC/SAML and translates to LDAP bind or header-based authentication for the legacy application.
Building a Unified Identity Stack
A mature Zero Trust identity stack typically involves all three protocols in complementary roles. Active Directory or an LDAP-compatible directory serves as the identity data store, holding user attributes, group memberships, and organizational hierarchy. The IdP (Azure AD, Okta, Keycloak) federates with this directory and exposes both SAML and OIDC endpoints. Modern applications integrate via OIDC. Legacy applications integrate via SAML or through an application proxy. Infrastructure components (Linux servers, network appliances) authenticate via LDAP or Kerberos, ideally with the IdP mediating through SSSD or RADIUS integration.
The strategic direction is clear: consolidate on OIDC wherever possible, maintain SAML for legacy SaaS integrations, and restrict LDAP to backend directory queries. Invest in building OIDC expertise on your engineering team, because every new service, API, and microservice should authenticate through OIDC from day one. The protocol choice is not merely technical — it determines how flexible, secure, and maintainable your identity architecture will be as the organization evolves.