SAML (SAML 1.0 y 2.0) y OpenID Connect (OIDC) son protocolos de identidad diseñados para autenticar a los usuarios y proporcionar datos de identidad para el control de acceso y como método de comunicación de la identidad de un usuario. Cualquiera de los dos protocolos puede ser la base de los proveedores de identidad (IdP) que ofrecen una serie de servicios y gestión de la identidad de los usuarios y pueden utilizarse para aplicaciones de inicio de sesión único (SSO).

Utilizado principalmente para aplicaciones empresariales y gubernamentales, SAML 2.0 es una tecnología madura que data de 2005 y soporta una amplia gama de funcionalidades de identidad. SAML utiliza XML para su formato de datos de identidad y HTTP simple o SOAP para los mecanismos de transporte de datos. El servicio que solicita y recibe datos del IdP se conoce como parte de confianza (RP). Los datos de la identidad del usuario, encapsulados en un documento XML llamado aserción SAML, están en forma de atributos, por ejemplo, dirección de correo electrónico, nombre, teléfono, etc.

SAML puede proporcionar un mecanismo para la identidad federada.

Antes de que un proveedor de servicios/parte de confianza pueda interactuar con un IdP para la autenticación de usuarios, deben intercambiarse metadatos entre la RP y el IdP. Estos metadatos, en formato XML, especifican los puntos finales, los certificados de firma y cifrado, los métodos de conexión admitidos, el formato de los atributos, etc., que cada parte del binario de SAML debe conocer de la otra. Cada parte utiliza los metadatos de la otra para configurar su parte del sistema.

Para autenticar a un usuario, la RP realiza una solicitud de autenticación (SAML AuthnRequest) al IdP, utilizando un formulario HTTP post (enlace POST) o una redirección con cadena de consulta (redirigir el enlace) para realizar la solicitud. Esta solicitud suele estar firmada por la RP.

A continuación, el IdP verifica la solicitud, autentifica al usuario y devuelve una respuesta de SAML, que contiene la aserción de SAML con los atributos acordados, a la RP en un formulario POST. Algunos IdP admiten el consentimiento del usuario para la liberación de atributos, pero esto no forma parte del protocolo SAML. Normalmente, las respuestas y aserciones de SAML están firmadas digitalmente por el IdP; las aserciones también pueden estar cifradas si la aplicación considera que la protección HTTPS es insuficiente.

SAML admite una serie de opciones de AuthnRequest que permiten un comportamiento dinámico, por ejemplo, los métodos de autenticación de usuario aceptables, la desactivación del SSO (forzando el inicio de sesión en el IdP), la restricción de IdP de proxy, etc. También se admiten otras opciones personalizadas.

Un protocolo relativamente nuevo, en continua evolución OIDC fue diseñado pensando en aplicaciones web y móviles. Diseñado para ser [fácil de adoptar y utilizar, OIDC] (https://auth0.com/docs/protocols/oidc) es una extensión de OAuth2, con estructuras de datos en formato JSON (JWT), y flujos HTTPS simples para el transporte. Los datos de identidad del usuario (“reclamaciones”) se emiten en un token web JSON (Token de ID). Las reclamaciones incluirán un identificador persistente y los datos del usuario definidos por los ámbitos solicitados. Convencionalmente, este token está firmado digitalmente, y también puede estar cifrado cuando sea necesario.

Los ámbitos de OIDC se utilizan para especificar qué posibles reclamaciones o grupos de reclamaciones puede devolver el IdP. Los valores del ámbito aceptables, y exactamente a qué reclamaciones se refieren, dependen del IdP. En OIDC, se definen una serie de ámbitos y reclamaciones comunes, como perfil, dirección, correo electrónico, etc.

A modo de ejemplo, el ámbito perfil contendrá generalmente el nombre del usuario y puede incluir su foto, fecha de nacimiento y otros datos personales, según los datos que tenga el IdP y lo que determine que debe incluirse.

Al igual que SAML, antes de poder utilizar OIDC, tanto la RP como el IdP deben intercambiar algunos datos. Sin embargo, estos datos pueden ser mucho más sencillos en OIDC. Como mínimo, la RP obtiene un ID de cliente y un client secret del IdP, acuerda los posibles ámbitos e informa al IdP de un punto final de la URL al que devolver códigos o tokens.

Al estar basado en OAuth 2.0, OIDC tiene una serie de casos de uso, conocidos como flujos, que determinan exactamente cómo interactúan la RP y el IdP. El flujo más sencillo es el flujo implícito, en el que la RP redirige al IdP con el ID del cliente y los valores del ámbito deseados. Después de que el usuario se haya autenticado y haya dado su consentimiento para compartir estos datos, el IdP devuelve las reclamaciones en el token de ID redirigiendo al punto final preestablecido de la RP. Los flujos más seguros no implican el envío directo del token de ID, y en su lugar, implican la devolución de un código de un solo uso, que la RP intercambia por el token a través de un POST de backend. Además del token de ID, también se puede emitir un token de acceso, que puede ser utilizado por la RP para autorizar las solicitudes de recursos de los usuarios, cubiertos por el ámbito.

SAML tiene un largo historial de proporcionar un medio seguro de intercambio de datos de identidad, por lo que cuenta con la confianza de muchas organizaciones. También es muy rico en funciones, ya que cubre una amplia gama de requisitos de identidad.

El OIDC, al ser más nuevo y estar en evolución (especialmente en el sector bancario europeo, con Open Banking), sigue estando por detrás de SAML en términos de características. Por ejemplo, la especificación dinámica de los IdP de proxy todavía no es totalmente compatible. Sin embargo, para muchas aplicaciones en las que se requiere un simple requisito de datos de identidad básicos, especialmente en el espacio del consumidor, OIDC es muy atractivo, ya que es mucho más fácil de usar que SAML, y no requiere el pesado manejo de XML que sí requiere SAML.

En la actualidad, SAML se utiliza ampliamente para la identificación de los ciudadanos del gobierno y la autenticación empresarial. Sin embargo, esto está empezando a cambiar, con sistemas más modernos que incluyen el requisito de OIDC en lugar de SAML. Esto se debe a los requisitos de procesamiento de datos percibidos como más ligeros en OIDC, utilizando tokens de JSON (token de ID) en lugar de XML. OIDC es ideal para su uso con aplicaciones móviles y aplicaciones web de una sola página, donde el uso de SAML sería un problema.

Siga leyendo en nuestra página de Introducción a IAM para explorar más temas en torno a la gestión de identidades y accesos.