Qué es LDAP: ¿sigue siendo relevante en 2026?

LDAP (Lightweight Directory Access Protocol) es un protocolo cliente-servidor para leer y escribir servicios de directorio a través de una red. Definido en RFC 4511, proporciona a las aplicaciones una forma estándar de consultar un directorio — respondiendo preguntas como «¿existe este usuario?», «¿a qué grupos pertenece?» y «¿a qué recursos puede acceder?»

A pesar de haber sido estandarizado por primera vez a principios de los años 90, LDAP sigue siendo la columna vertebral de la infraestructura de identidad empresarial en 2026. Active Directory, que funciona sobre LDAP, todavía está implementado en aproximadamente el 90% de las organizaciones en todo el mundo.

Puntos clave

LDAP es un protocolo. Define cómo las aplicaciones consultan un directorio — cuentas de usuario, membresías de grupos, derechos de acceso. Active Directory lo implementa, pero LDAP funciona de forma independiente en OpenLDAP y otros servidores sin ningún software de Microsoft.
AD no puede funcionar sin LDAP. Cada sistema que no es Windows y que se autentica contra Active Directory lo hace a través de LDAP. Si se elimina, AD pierde la capacidad de servir a aplicaciones de terceros, dispositivos de red e infraestructura Linux.
El puerto 389 no es aceptable en producción. LDAP estándar transmite credenciales en texto plano. LDAPS en el puerto 636 cifra toda la sesión. Microsoft ha estado aplicando requisitos de firma y vinculación de canal desde 2020.
Dos vulnerabilidades críticas fueron parcheadas en 2025. CVE-2025-26663 permite la ejecución remota de código no autenticada en controladores de dominio a través de un fallo de memoria en el servicio LDAP de Windows. CVE-2025-54918 elude las protecciones de vinculación de canal y firma mediante retransmisión NTLM. Ambas tienen parches — los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
LDAP y los protocolos modernos no son alternativas. SAML maneja SSO basado en navegador. OAuth maneja la autorización de API. LDAP maneja las búsquedas de directorio para sistemas que no hablan ninguno de los dos. La mayoría de los entornos empresariales ejecutan los tres simultáneamente.
La gestión manual de accesos crea brechas. Cuando los cambios en grupos de AD no se propagan automáticamente a los sistemas dependientes, las cuentas permanecen activas más tiempo del debido. Sincronizar el acceso a credenciales con la membresía de grupos del directorio elimina ese retraso.

Entendiendo LDAP: Los fundamentos

LDAP es un protocolo estándar para acceder y gestionar servicios de información de directorio distribuidos. Opera en un modelo de datos jerárquico derivado del estándar X.500 y permite a los clientes autenticar usuarios, buscar atributos y recuperar membresías de grupos desde un directorio central. Las organizaciones lo utilizan para responder una pregunta fundamental a escala: ¿quién tiene permitido hacer qué y dónde?

Los datos que LDAP organiza residen en un Árbol de Información de Directorio (DIT) — una estructura jerárquica de entradas, cada una identificada por un Distinguished Name (DN). Un DN típico tiene este aspecto:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Cada entrada contiene atributos: una entrada de usuario puede contener mail, uid, memberOf y userPassword. Las aplicaciones consultan estos atributos para tomar decisiones de autenticación y autorización.

¿Cómo funciona LDAP? (modelo cliente-servidor)

Un cliente LDAP envía una solicitud a un servidor LDAP (llamado Directory System Agent, o DSA). El servidor procesa la operación contra su base de datos de directorio y devuelve una respuesta. Las operaciones principales definidas en RFC 4511 incluyen:

Bind — autenticar un cliente en el directorio
Search — consultar entradas que coincidan con un filtro
Compare — verificar si una entrada tiene un valor de atributo específico
Modify / Add / Delete — operaciones de escritura en entradas del directorio
Unbind — terminar la sesión

La operación bind es donde ocurre la autenticación. Un cliente envía un DN y credenciales. El servidor las valida y concede o deniega la sesión. La mayoría de las aplicaciones empresariales utilizan LDAP bind para verificar la identidad del usuario antes de conceder acceso.

Puerto LDAP 389 vs. puerto LDAPS 636

LDAP estándar funciona en el puerto TCP 389 y transmite datos en texto plano. Esto significa que las credenciales, incluidas las contraseñas, viajan por la red sin cifrar. En cualquier entorno donde el tráfico de red pueda ser interceptado (que es cualquier entorno) esto es inaceptable.

LDAPS (LDAP sobre SSL/TLS) funciona en el puerto TCP 636 y envuelve toda la sesión LDAP en TLS, cifrando todo el tráfico incluyendo las credenciales de bind. Una tercera opción, StartTLS, actualiza una conexión existente del puerto 389 a TLS a mitad de sesión, pero introduce complejidad en la negociación y es más propenso a errores de configuración.

	LDAP (puerto 389)	LDAPS (puerto 636)
Transporte	TCP en texto plano	TCP cifrado con TLS
Credenciales en tránsito	Expuestas	Cifradas
Certificado requerido	No	Sí
Susceptible a MITM	Sí	No (con certificado válido)
Riesgo de retransmisión NTLM	Alto	Reducido (con vinculación de canal)
Aplicación de Microsoft	Obsoleto para producción	Requerido (ADV190023)
Uso en producción	No	Sí
Alternativa StartTLS	Puerto 389 + actualización STARTTLS	N/A

Microsoft ha estado exigiendo progresivamente la vinculación de canal LDAP y la firma LDAP desde 2020, con aplicación reforzada en actualizaciones posteriores de Windows Server. Ejecutar LDAP sin cifrar en el puerto 389 en producción es una brecha de seguridad. El puerto 636 es el valor predeterminado correcto.

¿Qué es el puerto TCP 389?

Puerto TCP 389 — el puerto estándar sin cifrar utilizado para las comunicaciones LDAP (Lightweight Directory Access Protocol). Permite a los servicios de directorio consultar y gestionar información de usuarios, credenciales de autenticación y datos organizacionales en servidores LDAP sin cifrado. Comúnmente utilizado en entornos empresariales para búsquedas de directorio, pero transmite datos en texto plano, lo que lo hace menos seguro que las alternativas cifradas.

¿Qué es el puerto TCP 636?

Puerto TCP 636 — el puerto estándar para LDAPS (LDAP sobre SSL/TLS), que es la comunicación LDAP cifrada con protocolos de seguridad SSL/TLS. Proporciona conexiones seguras y cifradas para consultas de servicios de directorio y autenticación, protegiendo datos sensibles de la interceptación. Este puerto es preferido sobre el puerto 389 en entornos conscientes de la seguridad y se utiliza comúnmente en servicios de directorio empresariales como Active Directory.

¿Qué es SSL/TLS?

SSL/TLS (Secure Sockets Layer / Transport Layer Security) — protocolos criptográficos que establecen conexiones seguras y cifradas entre clientes y servidores a través de redes. SSL es el protocolo más antiguo (ahora obsoleto), mientras que TLS es su sucesor moderno. Proporcionan autenticación, cifrado e integridad de datos para comunicaciones sensibles como HTTPS, correo electrónico y servicios de directorio. TLS utiliza certificados digitales para verificar la identidad del servidor y cifra todos los datos transmitidos para prevenir la interceptación.

¿Qué es StartTLS?

StartTLS — una extensión de protocolo que actualiza una conexión sin cifrar existente a una conexión cifrada utilizando cifrado TLS. En lugar de requerir un puerto seguro separado, StartTLS permite que un cliente se conecte a un puerto estándar (como el puerto LDAP 389 o el puerto SMTP 25) y luego emita un comando STARTTLS para actualizar la conexión a cifrado. Esto proporciona flexibilidad al soportar modos cifrados y sin cifrar en el mismo puerto, aunque requiere soporte del servidor y es menos seguro que los puertos cifrados dedicados como LDAPS (puerto 636).

LDAP vs. Active Directory: ¿Cuál es la diferencia?

Active Directory (AD) no es un reemplazo de LDAP — es un servicio de directorio que utiliza LDAP como uno de sus protocolos de acceso. Confundir los dos es uno de los conceptos erróneos más comunes en TI empresarial. La dependencia solo va en una dirección: LDAP funciona de forma independiente, AD no.

¿Se puede ejecutar LDAP sin AD?

Sí. LDAP es un protocolo — define cómo un cliente solicita información a un servidor de directorio y cómo ese servidor responde. Se puede implementar independientemente de cualquier software de Microsoft.

OpenLDAP es la implementación de código abierto más utilizada. 389 Directory Server y Apache Directory Server son alternativas comunes. Estos servidores independientes almacenan identidades de usuarios y membresías de grupos y los sirven a sistemas Linux/Unix, servidores de correo y aplicaciones personalizadas.

¿Se puede ejecutar AD sin LDAP?

No. Active Directory es un servicio de directorio completo construido por Microsoft sobre el modelo de datos X.500. Los controladores de dominio utilizan LDAP internamente para leer, escribir y replicar datos del directorio: usuarios, equipos, políticas de grupo. Cualquier aplicación de terceros o máquina que no sea Windows que se autentique contra AD lo hace hablando LDAP.

Si se elimina LDAP, AD no puede comunicarse con el resto de la infraestructura.

Cómo se relacionan en la práctica

Tipo	LDAP	Active Directory
Tipo	Protocolo abierto (RFC 4511)	Servicio de directorio propietario
Proveedor	Estándar IETF	Microsoft
Método de autenticación principal	Simple bind, SASL	Kerberos (Windows), LDAP bind (todo lo demás)
Plataforma	Multiplataforma	Windows Server
Funciona de forma independiente	Sí	No — requiere LDAP
Implementaciones comunes	OpenLDAP, 389 Directory Server, Apache DS	Active Directory Domain Services

Cuando un servidor Linux se autentica contra Active Directory, habla LDAP. Cuando una estación de trabajo Windows inicia sesión, utiliza Kerberos. AD soporta ambos — pero LDAP es lo que hace que AD sea accesible para el resto de la infraestructura.

Alternativas modernas: LDAP vs. SAML, OAuth y OpenID Connect

LDAP fue diseñado para la autenticación de red interna — consultar un directorio dentro de un perímetro corporativo. Los protocolos que le siguieron fueron diseñados para un mundo diferente: identidad federada a través de límites organizacionales, aplicaciones web y clientes móviles.

Protocolo	Caso de uso principal	Transporte	Exposición de credenciales
LDAP	Consultas de directorio interno	TCP (puerto 389/636)	Credenciales enviadas al servidor
SAML	SSO federado (aplicaciones web empresariales)	HTTP/XML	Credenciales permanecen en el IdP
OAuth 2.0	Autorización delegada (acceso a API)	HTTPS	No se intercambian credenciales
OpenID Connect	Autenticación federada sobre OAuth	HTTPS	No se intercambian credenciales

Estos protocolos no reemplazan a LDAP — operan en una capa diferente. SAML y OpenID Connect manejan SSO basado en navegador. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan todos ellos simultáneamente.

¿Sigue siendo relevante LDAP en 2026? (la realidad de la nube híbrida)

LDAP sigue siendo el protocolo de autenticación empresarial dominante, presente en aproximadamente el 90% de las organizaciones en todo el mundo a través de sus implementaciones de Active Directory. La adopción de la nube no ha cambiado esto.

La mayoría de las empresas no son completamente nativas de la nube. Ejecutan un modelo híbrido: algunas cargas de trabajo en Azure o AWS, otras en las instalaciones, con Active Directory como ancla de identidad para ambos. Microsoft Entra ID (anteriormente Azure AD) se conecta al AD local a través de sincronización, pero el AD local (y por lo tanto LDAP) sigue siendo la fuente autorizada para muchas decisiones de identidad.

El rol de LDAP en la arquitectura de confianza cero

La confianza cero requiere verificación continua: cada solicitud de acceso debe ser autenticada y autorizada, independientemente de la ubicación en la red. LDAP se encuentra en una intersección crítica en este modelo porque a menudo es el sistema que responde a esas solicitudes de verificación.

El desafío es que LDAP no fue diseñado con los principios de confianza cero en mente. Asume proximidad de red, utiliza conexiones persistentes y en su forma sin cifrar expone credenciales en tránsito. Adaptar LDAP a una arquitectura de confianza cero requiere controles compensatorios:

LDAPS obligatorio
reglas de firewall estrictas
limitar qué sistemas pueden alcanzar el puerto 636
aplicación de firma LDAP
monitorización de intentos de bind para detectar patrones anómalos

LDAP no rompe la confianza cero pero requiere un endurecimiento deliberado para soportarla. Las organizaciones que tratan LDAP como un componente heredado y lo dejan sin configurar están creando exactamente el tipo de confianza implícita que la confianza cero está diseñada para eliminar.

DevOps y gestión de secretos en CI/CD

Los pipelines automatizados presentan un desafío específico de LDAP. Los sistemas CI/CD (Jenkins, GitLab CI, ejecutores de GitHub Actions) a menudo necesitan autenticarse contra LDAP para acceder a recursos internos. Esa autenticación típicamente implica una cuenta de servicio: un DN de bind LDAP dedicado con una contraseña estática.

Las credenciales estáticas de cuentas de servicio son un riesgo persistente. Rara vez se rotan, a menudo se comparten entre pipelines, y cuando aparecen en registros de compilación o archivos de configuración, son difíciles de detectar y revocar. La respuesta es gestionar estas credenciales a través de un gestor de secretos dedicado en lugar de codificarlas en la configuración del pipeline.

Las herramientas CLI y REST API de Passwork permiten a los equipos DevOps obtener credenciales de cuentas de servicio en tiempo de ejecución en lugar de almacenarlas en configuraciones de pipeline. Los permisos heredan de los grupos de AD, por lo que el acceso permanece sincronizado con el directorio sin intervención manual. Comience su prueba gratuita hoy y pruébelo en su infraestructura

Riesgos críticos de seguridad de LDAP en 2026

LDAP no es solo un protocolo heredado con riesgos teóricos. Es una superficie de ataque activa con vulnerabilidades documentadas y explotadas.

La amenaza del robo de credenciales y ransomware

Según el X-Force Threat Intelligence Index 2026 de IBM, la recolección de credenciales fue el impacto de ataque más común observado en 2025. Los actores de amenazas recolectaron datos de inicio de sesión mediante phishing e infostealers, luego se mezclaron en flujos de autenticación normales para moverse lateralmente. Las credenciales de cuentas de servicio LDAP encajan precisamente en este patrón: reutilizadas entre aplicaciones, rara vez rotadas y casi nunca monitorizadas para detectar actividad de bind anómala.

La cadena de ataque está bien documentada: comprometer una credencial LDAP a través de phishing o password spraying, usarla para enumerar el directorio, identificar cuentas privilegiadas y escalar. El Digital Defense Report de Microsoft ha vinculado consistentemente el compromiso de credenciales AD/LDAP con el despliegue de ransomware. El directorio es un mapa de toda la estructura de acceso de la organización, y los atacantes lo leen antes de actuar.

Vulnerabilidades recientes: CVE-2025-26663 y CVE-2025-54918

Dos vulnerabilidades críticas divulgadas en 2025 demuestran que la superficie de ataque de LDAP se está expandiendo activamente.

CVE-2025-26663 es una vulnerabilidad de ejecución remota de código use-after-free en Windows LDAP, divulgada en abril de 2025. Un atacante puede explotar un fallo de gestión de memoria en el servicio LDAP de Windows (específicamente en wldap32.dll) para ejecutar código arbitrario en un servidor objetivo sin credenciales válidas.

El ataque solo requiere acceso de red al servicio LDAP. Los controladores de dominio, que exponen LDAP por diseño, son los objetivos principales. Los controladores de dominio sin parchear que ejecutan esta vulnerabilidad están efectivamente abiertos a Ejecución Remota de Código (RCE) no autenticada desde cualquier sistema que pueda alcanzar el puerto 389 o 636.

CVE-2025-54918, divulgada en septiembre de 2025, es una vulnerabilidad de escalada de privilegios que combina retransmisión NT LAN Manager con autenticación forzada para eludir las protecciones de vinculación de canal y firma LDAP. Un atacante con una cuenta de dominio de bajo privilegio puede forzar a un controlador de dominio a autenticarse en un sistema controlado por el atacante, manipular los paquetes de autenticación NTLM en tránsito y retransmitir la autenticación modificada de vuelta al controlador de dominio — logrando acceso de nivel SYSTEM. El ataque es particularmente peligroso porque elude controles en los que las organizaciones comúnmente confían como medidas de endurecimiento.

⚠️

Ambas vulnerabilidades tienen parches disponibles. Si los controladores de dominio no han recibido las actualizaciones de seguridad de Windows de abril de 2025 y posteriores, el parcheo es la prioridad inmediata.

Mejores prácticas para asegurar LDAP en la empresa

La siguiente lista de verificación cubre los controles mínimos para una implementación LDAP en producción. Estas son recomendaciones que abordan un vector de ataque específico y documentado.

Aplicar LDAPS en el puerto 636. Deshabilitar LDAP en texto plano en el puerto 389 para todo el tráfico de producción. Configurar certificados TLS de su CA interna o una CA pública de confianza.
Habilitar firma LDAP y vinculación de canal. Previene ataques de retransmisión. Requerido para la mitigación de CVE-2025-54918 — aunque tenga en cuenta que CVE-2025-54918 elude estos controles en sistemas sin parchear, por lo que el parcheo sigue siendo obligatorio.
Aplicar todas las actualizaciones de seguridad de Windows. CVE-2025-26663 y CVE-2025-54918 tienen parches. Los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
Restringir el acceso LDAP por IP. Solo los sistemas que legítimamente necesitan consultar LDAP deberían poder alcanzar el puerto 636. Las reglas de firewall deberían aplicar esto, no solo las suposiciones de segmentación de red.
Auditar credenciales de cuentas de servicio. Identificar cada DN de bind en uso en su entorno. Rotar contraseñas según un calendario. Eliminar cuentas que ya no se necesitan.
Monitorizar intentos de bind. Patrones de bind inusuales — fallos repetidos, binds desde IPs de origen inesperadas, binds a horas inusuales — son indicadores tempranos de credential stuffing o movimiento lateral.
Deshabilitar binds LDAP anónimos. Las consultas anónimas permiten la enumeración no autenticada del contenido del directorio. La mayoría de las implementaciones modernas no tienen un uso legítimo para binds anónimos.
Separar cuentas de servicio por función. Una cuenta de servicio utilizada por una VPN no debería tener los mismos permisos que una utilizada por un sistema de respaldo. El principio de mínimo privilegio también aplica a las cuentas de bind LDAP.

Optimizando el acceso empresarial con la integración LDAP de Passwork

La carga operativa de la gestión de acceso basada en LDAP se acumula con el tiempo. Los usuarios cambian de equipo, se unen a proyectos y abandonan la organización, y cada transición requiere cambios de acceso en múltiples sistemas. Cuando esos cambios son manuales, se retrasan. Las cuentas permanecen activas más tiempo del debido. Las credenciales se acumulan en lugares que nadie está rastreando.

Passwork se conecta directamente a Active Directory o cualquier directorio compatible con LDAP y mapea la membresía de grupos al acceso a bóvedas automáticamente:

Añadir un usuario al grupo SRE en AD — las credenciales correctas aparecen en su bóveda de Passwork, sin necesidad de acción administrativa separada
Eliminarlo del grupo — el acceso se revoca
El directorio permanece como la única fuente de verdad para quién tiene acceso a qué

Para entornos autoalojados, Passwork se implementa completamente dentro de su propio perímetro. Las credenciales nunca lo abandonan. SSO SAML está soportado junto con LDAP, por lo que los equipos que usan ambos protocolos para diferentes capas de aplicación no necesitan reconstruir su arquitectura de identidad.

Cada lectura, escritura, compartición y exportación se registra en el registro de auditoría — relevante tanto para revisiones de seguridad internas como para demostrar cumplimiento con SOC 2 CC6.1 y GDPR Artículo 32.

Conclusión

LDAP no va a desaparecer. El mercado de software de directorio se valoró en 8,4 mil millones de dólares en 2025 y se proyecta que alcanzará los 19,7 mil millones de dólares para 2034, según la investigación de mercado de Dataintelo — una cifra que refleja la inversión empresarial continua en infraestructura de directorio, no una tecnología en declive. Con el 90% de las empresas todavía ejecutando Active Directory, LDAP sigue siendo el tejido conectivo de la gestión de identidad corporativa.

Lo que ha cambiado es el entorno de amenazas. CVE-2025-26663 y CVE-2025-54918 son vulnerabilidades activamente parcheadas que apuntan a los servicios LDAP que sus controladores de dominio exponen ahora mismo.

La acción práctica es sencilla: aplicar LDAPS, parchear los controladores de dominio, auditar las credenciales de cuentas de servicio y asegurarse de que los cambios de acceso en el directorio se propaguen automáticamente a los sistemas que dependen de él. La gestión manual de acceso a la escala a la que operan la mayoría de las empresas es donde aparecen las brechas.

Passwork se integra con Active Directory y LDAP para mantener el acceso a credenciales sincronizado con los grupos de su directorio — automáticamente, sin scripts personalizados. Autoalojado, cifrado AES-256, ISO 27001, con un registro de auditoría completo. Pruébelo en su infraestructura

Preguntas frecuentes sobre LDAP

¿Para qué se utiliza LDAP?

LDAP se utiliza para autenticar usuarios y buscar información de directorio — membresías de grupos, direcciones de correo electrónico, atributos de cuentas — en aplicaciones empresariales. Los casos de uso comunes incluyen autenticación VPN, búsqueda de usuarios en servidores de correo, SSO de aplicaciones y gestión centralizada de usuarios. La mayoría de las aplicaciones empresariales que necesitan verificar identidad contra un directorio corporativo utilizan LDAP.

¿Cuál es la diferencia entre LDAP y Active Directory?

LDAP es un protocolo abierto (RFC 4511) para acceder a servicios de directorio. Active Directory es el servicio de directorio de Microsoft, que utiliza LDAP como uno de sus protocolos de acceso. AD también utiliza Kerberos para la autenticación de Windows. Se puede usar LDAP sin Active Directory (a través de OpenLDAP, por ejemplo), pero Active Directory depende de LDAP para servir consultas de directorio a aplicaciones que no son de Windows.

¿Qué es LDAPS y por qué es importante?

LDAPS es LDAP sobre TLS, funcionando en el puerto 636. LDAP estándar en el puerto 389 transmite credenciales en texto plano, haciéndolas visibles para cualquiera que pueda interceptar el tráfico de red. LDAPS cifra toda la sesión. En 2026, ejecutar LDAP sin cifrar en producción es indefendible — Microsoft ha estado aplicando requisitos de firma LDAP y vinculación de canal desde 2020, y tanto CVE-2025-26663 como CVE-2025-54918 apuntan directamente a servicios LDAP.

¿Todavía se usa LDAP en 2026?

Sí. Active Directory, que depende de LDAP, está implementado en aproximadamente el 90% de las empresas en todo el mundo. La adopción de la nube no lo ha desplazado — la mayoría de las organizaciones ejecutan entornos híbridos donde el AD local sigue siendo la fuente de identidad autorizada. LDAP también está integrado en miles de aplicaciones que se autentican contra directorios empresariales y no será reemplazado por SAML u OAuth sin una reingeniería significativa.

¿Cómo encaja LDAP en una arquitectura de confianza cero?

LDAP puede soportar la confianza cero si se endurece correctamente. La confianza cero requiere verificación continua de cada solicitud de acceso, y LDAP a menudo es el sistema que responde a esas solicitudes. Los requisitos: aplicar LDAPS (puerto 636), habilitar firma y vinculación de canal, restringir el acceso al directorio por IP de origen, monitorizar intentos de bind y rotar credenciales de cuentas de servicio regularmente. La configuración predeterminada de LDAP no es compatible con la confianza cero — pero el protocolo en sí no es el obstáculo.

¿Cuáles son los principales riesgos de seguridad con LDAP?

Los riesgos principales son la exposición de credenciales a través de conexiones sin cifrar (puerto 389), robo de credenciales de cuentas de servicio, ataques de retransmisión NTLM (CVE-2025-54918) y RCE no autenticado a través de vulnerabilidades de corrupción de memoria (CVE-2025-26663). El X-Force Threat Intelligence Index 2025 de IBM encontró que los ataques basados en identidad — muchos dirigidos a credenciales de directorio — representaron el 30% de todas las intrusiones en 2024. El parcheo, la aplicación de LDAPS y la higiene de cuentas de servicio abordan la mayoría de estos riesgos.

¿Puede LDAP ser reemplazado por SAML u OAuth?

No completamente. SAML y OAuth manejan la autenticación federada basada en navegador y la autorización de API respectivamente. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan los tres protocolos para diferentes capas de su stack de aplicaciones. La pregunta no es cuál elegir — es qué aplicaciones requieren LDAP y si esas conexiones están debidamente aseguradas.