Comprender IAM, OAuth, OpenID Connect, SAML, SSO y JWT en un solo artículo

El dominio de gestión de identidades y accesos (IAM) se ha vuelto más intrincado en los últimos años. Los términos elaborados como OAuth, OpenID Connect (OIDC), SAML, SSO y JWT se usan frecuentemente, pero ¿qué significan? ¿Cómo funcionan juntos? Vamos a explorar estos conceptos y marcos para hacerlos más comprensibles y prácticos.

¿Qué es IAM?#

La gestión de identidades y accesos (IAM) es un concepto amplio que implica gestionar identidades digitales e implementar control de acceso. Los marcos y protocolos mencionados anteriormente caen bajo IAM, cada uno abordando desafíos específicos en este espacio.

En esencia, IAM se trata de:

• Identidad: Una representación digital de un usuario, servicio o dispositivo. Una identidad típicamente incluye atributos como nombre, correo electrónico, roles, etc., para describir la entidad.
• Acceso: La capacidad de interactuar con recursos, realizar acciones o utilizar servicios. El acceso define qué acciones se pueden realizar sobre qué recursos.

En el diagrama anterior, un usuario (identidad) quiere realizar una solicitud GET en una API (recurso). Los atributos del usuario - nombre, correo electrónico y rol - describen la identidad.

Autenticación vs. autorización#

La autenticación y autorización a menudo aparecen juntas en las discusiones sobre IAM. Vamos a aclarar sus definiciones:

• Autenticación: El proceso de verificar la propiedad de una identidad. Responde a la pregunta: "¿Cuál identidad posees?"
• Autorización: El proceso de determinar qué acciones una identidad autenticada puede realizar sobre un recurso. Responde a la pregunta: “¿Qué puedes hacer?”

En el ejemplo anterior:

• Antes de que el usuario (identidad) pueda realizar cualquier acción, debe completar el proceso de autenticación.
• Después de la autenticación, el sistema necesita determinar si el usuario puede realizar una solicitud GET (acción) en el API (recurso), es decir, completar el proceso de autorización.

---

Armado con este conocimiento fundamental, vamos a desmitificar los otros acrónimos y protocolos.

OAuth#

OAuth 2.0, comúnmente referido como OAuth, es un marco de autorización que permite a una aplicación acceder a recursos protegidos en otra aplicación (generalmente en nombre de un usuario).

Por ejemplo, imagina que tienes una aplicación web llamada MyApp que quiere acceder a Google Drive de un usuario. En lugar de pedir al usuario que comparta sus credenciales de Google Drive, MyApp puede usar OAuth 2.0 para solicitar permiso (autorización) a Google para acceder al Drive del usuario.

Aquí hay un diagrama simplificado que ilustra el flujo de OAuth:

En este flujo:

• MyApp es el cliente (identidad) que solicita acceso a Google Drive (recurso).
• El usuario (propietario del recurso) concede a MyApp permiso en el paso 6, completando el proceso de autorización.

Un elemento clave en OAuth 2.0 es el token de acceso, que el cliente usa para demostrar la autorización del usuario para acceder a los recursos. Para profundizar más, consulta Token de acceso.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) es una capa de autenticación construida sobre OAuth 2.0. Añade características específicamente para la autenticación, como tokens de ID y un endpoint UserInfo, haciéndolo apto tanto para la autenticación como para la autorización.

Si revisamos el flujo de OAuth, al agregar OIDC se introduce un token de ID. Este token contiene información sobre el usuario autenticado y permite que MyApp verifique la identidad del usuario.

Ejemplo de escenario: "Iniciar sesión con Google"#

Cambiemos de ejemplo. Si MyApp desea permitir que los usuarios inicien sesión usando sus cuentas de Google, el objetivo cambia a la autenticación en lugar del acceso a los recursos. En este caso, OIDC es más adecuado. Así es como se ve el flujo de OIDC:

Diferencia clave: Además de un token de acceso, OIDC proporciona un token de ID, que permite a MyApp autenticar al usuario sin requerir solicitudes adicionales.

OIDC comparte las definiciones de concesión de OAuth 2.0, asegurando compatibilidad y consistencia entre los dos marcos.

SAML#

Security Assertion Markup Language (SAML) es un marco basado en XML para el intercambio de datos de autenticación y autorización entre partes. SAML, introducido a principios de la década de 2000, ha sido ampliamente adoptado en entornos empresariales.

¿Cómo se compara SAML con OIDC?#

SAML y OIDC son funcionalmente similares pero difieren en sus detalles de implementación:

• SAML: Usa aserciones basadas en XML y a menudo se considera más complejo.
• OIDC: Utiliza JSON y JWT, haciéndolo más ligero y amigable para los desarrolladores.

Las aplicaciones modernas a menudo prefieren OIDC por su simplicidad y flexibilidad, pero SAML sigue siendo prevalente en sistemas heredados y casos de uso empresariales.

Inicio de sesión único (SSO)#

El inicio de sesión único (SSO) es un esquema de autenticación que permite a los usuarios acceder a múltiples aplicaciones y servicios con un solo conjunto de credenciales. En lugar de iniciar sesión en cada aplicación individualmente, el usuario inicia sesión una vez y obtiene acceso a todos los sistemas conectados.

¿Cómo funciona el SSO?#

El SSO se basa en un proveedor de identidad (IdP) central para gestionar las identidades de los usuarios. El IdP autentica al usuario y proporciona servicios como la autenticación y la autorización a las aplicaciones conectadas.

El IdP puede usar protocolos como OIDC, OAuth 2.0, SAML u otros para proporcionar estos servicios. Un solo IdP puede soportar múltiples protocolos para satisfacer las diversas necesidades de diferentes aplicaciones.

Ejemplo de SSO Basado en OIDC#

Exploremos un ejemplo de SSO basado en OIDC:

En este flujo, el usuario inicia sesión en el IdP una vez y es autenticado en múltiples aplicaciones (AppA y AppB).

SSO Empresarial#

Aunque el SSO es un concepto amplio, también puedes encontrar el término SSO empresarial, que se refiere a un tipo específico de SSO diseñado para entornos empresariales (típicamente para empleados y socios).

Cuando un cliente solicita SSO para tu aplicación, es importante clarificar sus necesidades y los protocolos que están usando. En la mayoría de los casos, esto significa que para dominios de correo electrónico específicos, quieren que tu aplicación redirija a los usuarios a su IdP (que implementa SSO empresarial) para la autenticación.

Ejemplo: Agregar un proveedor de SSO empresarial#

Aquí tienes un ejemplo simplificado de integrar un proveedor de SSO empresarial (Banana) con tu aplicación (MyApp):

JWT#

JSON Web Token (JWT) es un estándar abierto definido en RFC 7519 que permite la comunicación segura entre dos partes. Es el formato estándar para los tokens de ID en OIDC y es ampliamente utilizado para los tokens de acceso en OAuth 2.0.

Aquí están las características clave de JWT:

• Compacto: Los JWT son objetos JSON codificados en un formato compacto, lo que los hace fáciles de transmitir y almacenar.
• Autónomo: Los JWT contienen toda la información necesaria sobre el usuario y el propio token.
• Verificable y encriptable: Los JWT pueden ser firmados y encriptados para asegurar la integridad y confidencialidad de los datos.

Un JWT típico se ve así:

Este JWT consta de tres partes separadas por puntos:

• Encabezado: Contiene metadatos sobre el token, como el tipo de token y el algoritmo de firma.
• Carga útil: Contiene información sobre la identidad y el propio token.
• Firma: Verifica la integridad del token.

Tanto el encabezado como la carga útil son objetos JSON codificados en base64. El JWT anterior puede decodificarse de la siguiente manera:

Usando JWT, el cliente puede decodificar el token y extraer la información del usuario sin realizar solicitudes adicionales al proveedor de identidad. Para saber más sobre JWT, visita JSON Web Token (JWT).

Resumen#

Hemos cubierto mucho terreno en este artículo. Resumamos los puntos clave con un ejemplo:

Imagina que tienes una aplicación web, AppA, que requiere una solución de gestión de identidades y accesos (IAM). Eliges Logto, un proveedor de identidad que usa OpenID Connect (OIDC) para la autenticación. Como OIDC está construido sobre OAuth 2.0, Logto también soporta la autorización para tu aplicación.

Para reducir la fricción para tus usuarios, habilitas "Iniciar sesión con Google" en Logto. Esto utiliza OAuth 2.0 para intercambiar datos de autorización e información del usuario entre Logto y Google.

Después de que el usuario inicia sesión en AppA a través de Logto, AppA recibe un token de ID, que es un JSON Web Token (JWT) que contiene la información del usuario.

A medida que tu negocio crece, lanzas una nueva aplicación, AppB, que también necesita autenticación de usuario. Dado que Logto ya está configurado, puedes reutilizar el mismo flujo de autenticación para AppB. Tus usuarios ahora pueden iniciar sesión en ambos AppA y AppB con un solo conjunto de credenciales, una característica conocida como inicio de sesión único (SSO).

Más tarde, un socio comercial te pide conectar su sistema de SSO empresarial, que usa Security Assertion Markup Language (SAML). Descubres que Logto soporta conexiones SAML, por lo que configuras una conexión entre Logto y el sistema SSO del socio. Ahora, los usuarios de la organización del socio también pueden iniciar sesión en AppA y AppB usando sus credenciales existentes.

---

Espero que este artículo haya aclarado estos conceptos para ti. Para explicaciones y ejemplos más detallados, consulta Auth Wiki. Si estás buscando una solución IAM para tu aplicación, considera usar un servicio gestionado como Logto para ahorrar tiempo y esfuerzo.