SAML y OAuth2 son protocolos estándar abiertos diseñados con objetivos diferentes pero relacionados. Principalmente, SAML 2.0 está diseñado para autenticar a un usuario, por lo que proporciona datos de identidad del usuario a un servicio. OAuth 2.0 está diseñado como un protocolo de autorización que permite a un usuario compartir el acceso a recursos específicos con un proveedor de servicios.

SAML (Security Assertion Markup Language) es un protocolo seguro y bien establecido, utilizado ampliamente por empresas y gobiernos para compartir datos de identidad. Estos datos utilizan estructuras de datos XML y simples mecanismos de transporte de datos HTTP o SOAP. Con SAML, un proveedor de identidades (Identity Provider, IdP) proporciona datos de usuario (atributos, como el nombre, el correo electrónico, etc.) cuando lo solicita un servicio o una parte de confianza (Relying Party, RP).

Antes de que se produzca cualquier transacción de autenticación, la parte de confianza (RP) y el proveedor de identidad (IdP) deben establecer una relación de confianza. Esta relación se construye mediante el intercambio de algunos artefactos tales como metadatos, puntos de conexión específicos, certificados de firma y cifrado, métodos de conexión compatibles, etc.

Una vez establecidos, la RP que necesita la identidad de un usuario envía al IdP un formulario a través de POST (o redirecciona) con una solicitud de autenticación, dentro de una sesión del navegador web. A continuación, el IdP autentifica al usuario final con un inicio de sesión interactivo y devuelve los datos de identidad correspondientes (conjunto de credenciales) en una respuesta de SAML a través de un formulario POST a la RP. Estos datos de identidad siempre incluirán un identificador que la RP podrá utilizar para identificar al usuario. Como parte de esta interacción, el IdP también puede establecer una sesión de [inicio de sesión único] (https://auth0.com/docs/sso/current) (Single Sign-On, SSO), de modo que las solicitudes de autenticación de otras RP pueden omitir el paso de inicio de sesión interactivo.

Si la RP quiere atributos adicionales, estos pueden ser solicitados dentro del contexto de la sesión de SSO mediante el envío de una consulta de atributos al IdP.

Normalmente, las respuestas SAML están firmadas digitalmente, para permitir la detección de la manipulación de datos en tránsito, y también pueden ser cifradas si el cifrado del transporte (HTTPS) es insuficiente.

Publicado por primera vez en 2012, OAuth 2.0, también conocido como OAuth2, es un protocolo de autorización diseñado para permitir a los usuarios dar acceso a sus recursos alojados en un proveedor de servicios, sin entregar las credenciales. La naturaleza de los recursos del usuario no está definida en las especificaciones del protocolo, por lo que pueden ser datos u otras entidades. OAuth2 tiene un rico conjunto de características que permiten su uso desde una amplia gama de dispositivos y aplicaciones. Además, OAuth2 es la base sobre la que se construye OpenID Connect, un popular protocolo de autenticación.

En la terminología de OAuth2, el servicio que requiere acceso a los recursos de los usuarios es el Cliente, y el servicio que puede suministrar estos recursos es el servidor de Recursos. El acceso a los recursos de los usuarios en el servidor de recursos se controla mediante el uso de tokens de acceso, artefactos que prueban la autorización de acceso. Además, OAuth2 proporciona un mecanismo, llamado ámbito, que limita los permisos sobre el recurso de un usuario.

El sistema que autentifica al usuario y en última instancia responde con tokens de acceso es el servidor de Autorización.

Al igual que SAML, antes de poder utilizar OAuth2, el cliente y el servidor de Recursos deben intercambiar algunos datos con el servidor de Autorización. Como mínimo, obtienen un ID de cliente y un secreto del servidor de Autorización y acuerdan los puntos de conexión a los que deben llamar para obtener información específica.

Auth2 es muy flexible y proporciona a un Cliente un número de [flujos, conocidos como concesiones] (https://auth0.com/docs/applications/reference/grant-types-available), para obtener un token de acceso. Qué concesión usar depende en su mayoría del tipo de Cliente (aplicación móvil, aplicación nativa, cliente web, etc.) y de los requisitos generales de seguridad. Tal vez el más común sea la concesión de código de autorización, que se aplica cuando la aplicación del cliente que necesita acceder a un recurso del usuario es una aplicación web normal. A continuación, se describen brevemente las interacciones entre el Cliente, el servidor de Recursos y el servidor de Autorización en esta concesión:

1. El Cliente redirige al usuario al servidor de Autorización solicitando autorización para acceder al recurso del usuario con ámbitos específicos.

2. El servidor de autorización realiza un inicio de sesión interactivo con el usuario, que también confirma que concede los permisos para los ámbitos especificados.

3. El servidor de Autorización redirige al usuario al punto de conexión del cliente con un código de autorización de un solo uso.

4 El cliente se autentifica con el servidor de autorización e intercambia el código de autorización por un token de acceso.

5. Con el token de acceso, el cliente solicita el recurso del usuario al servidor de Recursos.

SAML admite el inicio de sesión único a la vez que admite la autorización por la vía de Consulta de atributos. OAuth se centra en la autorización, aunque a menudo se vea forzada a desempeñar un rol de autenticación, por ejemplo, cuando se utiliza el inicio de sesión social como “iniciar sesión con una cuenta de Facebook”. En cualquier caso, OAuth2 no soporta SSO.

Desde un punto de vista técnico, SAML define un formato de token, su cifrado es complicado y el tamaño de los mensajes intercambiados es significativo. En cambio, OAuth2 no utiliza ningún tipo de cifrado de mensajes (se basa en HTTPS) y no define un formato de token.

El atractivo de OAuth2 reside en la facilidad de uso y la flexibilidad: puede utilizarse en dispositivos móviles, dispositivos inteligentes (por ejemplo, televisores inteligentes), aplicaciones web, aplicaciones de una sola página, etc. Hay muchas bibliotecas disponibles para facilitar el proceso de integración con diferentes tipos de clientes y proveedores de servicios. SAML, en cambio, no se diseñó teniendo en cuenta estas aplicaciones modernas, lo que dificulta su uso en estos sistemas. Se suele utilizar con las aplicaciones web tradicionales.

SAML se suele utilizar para el SSO en aplicaciones gubernamentales y empresariales (gestión de identidades), donde el procesamiento de XML por parte del sistema backend es habitual. Muchos sistemas gubernamentales de identificación de ciudadanos (por ejemplo, UK Verify) se basan en SAML.

Outh2 se utiliza ampliamente en aplicaciones de consumo y empresariales, tanto en roles de autorización como de autenticación. Se suele utilizar para autorizar el acceso a API de RESTful, donde su uso de tokens de acceso lo hace sencillo y atractivo.

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.