Identidad moderna: SAML, OIDC y enfoques híbridos

Security Assertion Markup Language 2.0 (SAML) es un estándar abierto basado en XML para el inicio de sesión único (SSO) en entornos empresariales. Estandarizado en 2005, SAML permite que un proveedor de identidad (IdP) emita aserciones XML firmadas digitalmente a los proveedores de servicios (SP), de modo que los usuarios se autentiquen una sola vez y accedan a varios servicios sin volver a introducir sus credenciales.

En SAML, el proveedor de identidad (IdP) es la autoridad que autentica a los usuarios y emite aserciones. Algunos ejemplos son Okta, Microsoft Entra ID y PingFederate. El proveedor de servicios (SP) es la aplicación que confía en la aserción del IdP. Algunos ejemplos son Salesforce, Workday y ServiceNow. El SP confía en la firma del IdP para conceder el acceso.

El IdP debe firmar digitalmente las aserciones SAML mediante un par de claves RSA o EC, lo que permite al SP verificar su autenticidad. Las aserciones también pueden cifrarse para garantizar la confidencialidad durante el tránsito. El SP debe validar la firma, comprobar las marcas de tiempo NotBefore y NotOnOrAfter de la aserción y verificar la restricción de audiencia para impedir los ataques de repetición.

OpenID Connect (OIDC) es una capa de identidad moderna basada en OAuth 2.0 que cumple el mismo propósito de SSO que SAML, pero utiliza JSON y JWT en lugar de XML. Publicado en 2014, OIDC se adapta mejor a las aplicaciones móviles, las aplicaciones de una sola página y las API REST, mientras que SAML sigue predominando en las aplicaciones web empresariales tradicionales.

OIDC amplía OAuth 2.0 al añadir un token de ID (un JWT que contiene notificaciones de identidad) al flujo de autorización de OAuth 2.0. OAuth 2.0 gestiona la autorización (acceso delegado a las API), mientras que OIDC añade la autenticación (verificación de la identidad del usuario). OIDC requiere el ámbito openid y devuelve un token de ID junto con el token de acceso de OAuth.

Microsoft Entra ID (antes Azure Active Directory) es un proveedor de identidad nativo de la nube que admite SAML y OIDC/OAuth 2.0 para el SSO federado. Puede sincronizarse con Active Directory local mediante Entra Connect, lo que proporciona una administración de identidades híbrida en la que los recursos de la nube y locales comparten un único directorio de identidades.

Active Directory Federation Services (AD FS) es el servidor de federación local de Microsoft que publica puntos de conexión SAML y WS-Federation para Active Directory local. AD FS conecta las aplicaciones heredadas basadas en SAML con las credenciales de Active Directory y, en implementaciones híbridas, establece una federación con Entra ID para ampliar el SSO a las aplicaciones en la nube.

System for Cross-domain Identity Management (SCIM) es un estándar de API REST para automatizar el aprovisionamiento y desaprovisionamiento de usuarios entre sistemas de identidad y aplicaciones. Cuando se añade un empleado a Entra ID u Okta, SCIM crea automáticamente las cuentas correspondientes en las aplicaciones SaaS conectadas y las elimina cuando el empleado deja la organización.

Los proveedores de identidad modernos implementan políticas de acceso condicional que evalúan señales de riesgo (cumplimiento del dispositivo, ubicación y comportamiento del usuario) antes de conceder el acceso. Estas políticas pueden requerir una autenticación multifactor reforzada para los recursos sensibles. Combinado con el SSO de OIDC o SAML, el acceso condicional proporciona una seguridad adaptativa sin las molestias de volver a autenticarse.

La arquitectura Zero Trust considera irrelevante la ubicación de la red para las decisiones de acceso: no se concede confianza implícita por el hecho de encontrarse dentro de una red corporativa. En lugar de la autenticación perimetral de Kerberos, Zero Trust utiliza la verificación continua de la identidad, comprobaciones del estado del dispositivo y políticas de acceso con privilegios mínimos, aplicadas en cada solicitud de acceso a un recurso mediante OIDC o SAML.

Use SAML para las aplicaciones empresariales heredadas creadas antes de 2014 que ya admitan SAML. Use OIDC para aplicaciones nuevas, aplicaciones móviles, SPA y API. Los principales IdP admiten ambos estándares, por lo que la elección suele depender de la compatibilidad existente de la aplicación y no de diferencias de seguridad. OIDC es la opción preferida para cualquier desarrollo nuevo.

¿Qué afirmación describe correctamente una diferencia clave entre SAML y OIDC?

SAML 2.0 proporciona SSO basado en XML para las aplicaciones empresariales tradicionales. OIDC añade identidad a OAuth 2.0 mediante tokens JWT y es la opción preferida para las aplicaciones modernas. Entra ID admite ambos como IdP de nube híbrida. AD FS conecta AD local con aplicaciones basadas en SAML. SCIM automatiza el aprovisionamiento. Zero Trust sustituye el uso perimetral de Kerberos por una verificación de identidad continua y regida por políticas.