Identidad federada: SAML, OAuth y OpenID Connect

En las empresas modernas, los empleados necesitan acceder a decenas de aplicaciones —aplicaciones en la nube, herramientas SaaS, portales de socios y sistemas internos—, cada una de ellas potencialmente administrada por organizaciones diferentes. Crear y administrar cuentas independientes para cada una es inseguro (proliferación de credenciales) e ineficiente. La identidad federada resuelve este problema al permitir que un proveedor de identidad (IdP) —una fuente de identidad confiable y autorizada— autentique a los usuarios y comparta esa identidad autenticada con proveedores de servicios (SP) de distintas organizaciones. Los usuarios se autentican una sola vez y obtienen acceso a varios sistemas sin volver a introducir sus credenciales.

El inicio de sesión único (SSO) permite a los usuarios autenticarse una vez y acceder a varias aplicaciones durante una sesión sin volver a autenticarse. El usuario inicia sesión en el proveedor de identidad (Active Directory corporativo, Okta, Azure AD), recibe un token de sesión o una aserción y presenta este token a cada proveedor de servicios que visita. El SSO mejora la seguridad al reducir la cantidad de contraseñas que los usuarios deben administrar (lo que reduce su reutilización), permitir la aplicación centralizada de las políticas de autenticación y revocar de inmediato el acceso en todas las aplicaciones integradas cuando una cuenta se deshabilita en el nivel del IdP.

SAML (Security Assertion Markup Language) 2.0 es el estándar abierto basado en XML para intercambiar datos de autenticación y autorización entre proveedores de identidad y proveedores de servicios. El flujo de SAML es el siguiente: (1) el usuario accede a un proveedor de servicios (por ejemplo, Salesforce); (2) el SP redirige al proveedor de identidad (por ejemplo, Okta); (3) el usuario se autentica en el IdP; (4) el IdP emite una aserción SAML XML firmada que contiene la identidad y los atributos del usuario; (5) la aserción se devuelve al SP; (6) el SP valida la firma de la aserción mediante la clave pública del IdP y concede el acceso. SAML se utiliza ampliamente para el SSO empresarial en aplicaciones web.

En una federación SAML participan tres partes. El principal es el usuario (o sistema) que solicita acceso y quien inicia el proceso de autenticación. El proveedor de identidad (IdP) es la fuente autorizada de identidad que autentica al principal y emite aserciones; algunos ejemplos son Microsoft Azure AD, Okta, Ping Identity y ADFS. El proveedor de servicios (SP) consume la aserción y concede el acceso basándose en ella; algunos ejemplos son Salesforce, Google Workspace, AWS y cualquier aplicación compatible con SAML. El SP y el IdP establecen la confianza de antemano mediante el intercambio de metadatos que contienen las URL de los endpoints y los certificados de firma de cada uno.

OAuth 2.0 es un marco de autorización (no un protocolo de autenticación) que permite a una aplicación de terceros acceder a recursos en nombre de un usuario sin exponer sus credenciales. El caso de uso clásico es: «Permitir que esta aplicación de edición de fotos acceda a sus Google Photos». OAuth 2.0 define cuatro roles: el propietario del recurso (usuario), el cliente (aplicación de terceros), el servidor de autorización (emite tokens) y el servidor de recursos (alberga el recurso protegido). El usuario autoriza al cliente, que recibe un token de acceso y lo presenta al servidor de recursos, sin necesitar nunca la contraseña real del usuario.

El flujo de código de autorización es el flujo de OAuth 2.0 más seguro para aplicaciones web. El flujo es el siguiente: (1) el cliente redirige al usuario al servidor de autorización con los ámbitos solicitados; (2) el usuario se autentica y otorga su consentimiento en el servidor de autorización; (3) el servidor de autorización redirige de vuelta con un código de autorización de corta duración; (4) el cliente intercambia el código por un token de acceso (y, opcionalmente, un token de actualización) mediante una llamada de servidor a servidor con las credenciales del cliente; (5) el cliente utiliza el token de acceso para llamar al servidor de recursos. El intercambio del código se realiza en el servidor, lo que evita que el token de acceso quede expuesto en el historial o los registros del navegador.

OpenID Connect (OIDC) es una capa de autenticación creada sobre OAuth 2.0. OAuth solo proporciona autorización (tokens de acceso que demuestran qué puede hacer el cliente); OIDC añade autenticación (un token de ID que demuestra quién es el usuario). OIDC añade el ámbito openid al flujo de OAuth y devuelve un token de ID JWT (JSON Web Token) firmado junto con el token de acceso. El token de ID contiene claims (nombre, correo electrónico, sub [identificador del sujeto]) que identifican al usuario. OIDC es actualmente el protocolo predominante para el SSO orientado al consumidor; los botones «Iniciar sesión con Google/Apple/Microsoft» utilizan OIDC.

Los JSON Web Tokens (JWT) son un formato compacto y seguro para URL que permite representar claims entre distintas partes. Un JWT tiene tres partes codificadas en base64url y separadas por puntos: encabezado (algoritmo y tipo de token), carga útil (claims: iss, sub, aud, exp, iat y claims personalizados) y firma (firma criptográfica que verifica la integridad del token). Los JWT son autocontenidos: el servidor de recursos puede verificarlos sin comunicarse de nuevo con el servidor de autorización, lo que mejora el rendimiento y permite arquitecturas sin estado. El requisito de seguridad fundamental es verificar siempre la firma del JWT y comprobar los claims exp (expiración) y aud (audiencia).

Comprender cuándo se aplica cada estándar es fundamental para el examen Security+. SAML 2.0: SSO empresarial para aplicaciones web, flujos basados en navegador y aserciones XML. Es antiguo, pero está ampliamente implementado en empresas. OAuth 2.0: autorización de API, es decir, conceder a aplicaciones de terceros acceso limitado a recursos. No autentica directamente a los usuarios. OIDC: autenticación de consumidores y empresas modernas (SSO), basada en OAuth 2.0. Devuelve tokens de ID JWT que identifican al usuario. En la práctica, los entornos empresariales suelen utilizar SAML para el SSO de aplicaciones y OIDC para la autenticación de API y dispositivos móviles. Los entornos modernos nativos de la nube prefieren OIDC frente a SAML por su formato JSON/JWT y su mejor compatibilidad con dispositivos móviles.

Los sistemas de identidad federada introducen vectores de ataque específicos. Ataques de repetición de aserciones: un atacante intercepta una aserción SAML y la reutiliza para obtener acceso. Se mitigan mediante aserciones con una duración breve e identificadores de aserción de un solo uso. XML signature wrapping (XSW): en SAML, en ocasiones los atacantes pueden manipular XML firmado para modificar los claims mientras mantienen válida la firma del contenido original. Confusión de algoritmos de JWT: si un servidor acepta los algoritmos RS256 (asimétrico) y HS256 (simétrico), un atacante puede falsificar JWT utilizando la clave pública del servidor como secreto HMAC para HS256. Valide siempre que el algoritmo del encabezado coincida con el algoritmo esperado. Redireccionadores abiertos: las URI de redirección de OAuth deben coincidir exactamente para impedir el robo de tokens mediante redirecciones a sitios controlados por atacantes.

La federación de identidades empresariales suele requerir la sincronización de datos de identidad de los usuarios entre sistemas. SCIM (System for Cross-domain Identity Management) es un estándar de API REST para automatizar el aprovisionamiento y desaprovisionamiento de usuarios entre un proveedor de identidad y los proveedores de servicios conectados. Cuando se añade un nuevo empleado a Azure AD (IdP), SCIM crea automáticamente su cuenta en Salesforce, Slack, GitHub y otras aplicaciones compatibles con SCIM. Cuando se rescinde la relación laboral del empleado, SCIM desactiva todas sus cuentas simultáneamente, lo que cierra el periodo durante el cual podrían aprovecharse cuentas huérfanas. SCIM complementa los protocolos de SSO (SAML/OIDC) al gestionar el ciclo de vida de las identidades, algo que los protocolos de SSO no contemplan.

En esta lección ha aprendido que: SAML 2.0 utiliza aserciones XML para el SSO empresarial basado en navegador; OAuth 2.0 es un marco de autorización para delegar el acceso a API; OpenID Connect añade autenticación (tokens de ID JWT) sobre OAuth; y SCIM automatiza la gestión del ciclo de vida de las identidades en sistemas federados. Con esto finaliza el curso de autenticación y autorización. A continuación, exploraremos los fundamentos de seguridad de redes.