Qué es la identidad federada: del login propio a «Iniciar sesión con…»

HTTP/1.1 302 Found
Location: https://login.cafetal.example/realms/cafetal/protocol/openid-connect/auth?client_id=portal-planillas&response_type=code&scope=openid%20profile&redirect_uri=https%3A%2F%2Fplanillas.cafetal.example%2Fcallback&state=2bea8b58a6ea4536&code_challenge=Q4zhnQM_5_CIfNiBhOCGtk0vb591WSz75K57VFptB4A&code_challenge_method=S256

Esa es la respuesta que devuelve el portal de planillas de Cafetal Digital cuando alguien entra sin sesión. El portal no pregunta la contraseña: manda al navegador a otro servidor, el de identidad, con una lista de parámetros. Al terminar este curso usted va a poder leer cada uno de ellos y decir qué pasa si falta.

Qué es

La identidad federada consiste en que una aplicación deja de autenticar a sus usuarios y confía esa tarea a un proveedor de identidad (IdP), que le entrega una prueba firmada de quién es la persona. La aplicación nunca ve la contraseña ni el segundo factor: recibe un token o una aserción, comprueba la firma y decide.

Hay dos preguntas distintas que conviene separar desde el principio:

• Autenticación (authentication, AuthN): ¿quién es usted? La responde el IdP.
• Autorización (authorization, AuthZ): ¿qué puede hacer esta aplicación, o esta persona, con estos datos? La deciden el servidor de autorización y la API que guarda los datos.

OAuth 2 resuelve la segunda. OpenID Connect añade la primera encima de OAuth. SAML resuelve las dos a su manera, con XML. Las passkeys cambian cómo se autentica la persona ante el IdP. Ese es el mapa del curso.

Breve historia

OAuth 2.1 merece una aclaración, porque se cita mucho como si ya existiera: a octubre de 2026 es el borrador draft-ietf-oauth-v2-1-16, no un RFC. No inventa nada: consolida lo que RFC 9700 ya pide (PKCE obligatorio, fuera el flujo implícito y el de contraseña) en un solo documento.

Por qué importa en ciberseguridad

Los atacantes se adaptaron al MFA. Hoy, en vez de robar la contraseña, consiguen que la víctima autorice una aplicación maliciosa, que teclee un código de dispositivo o que entregue un token ya emitido. Ninguno de esos ataques se ve en un registro de «contraseña incorrecta». Quien trabaja en un SOC necesita reconocer en un registro de inicios de sesión el protocolo usado, el cliente y los permisos concedidos; quien hace pentesting o revisión de código tiene que encontrar el redirect_uri con comodín o la API que acepta tokens de otra audiencia; quien administra Entra ID, Okta o Keycloak decide qué flujos permite.

Lo que más se ve en auditorías de bancos y SaaS de la región no son fallas exóticas de criptografía. Son decisiones de configuración: un cliente público sin PKCE, una URI de redirección con *, una API que solo comprueba que el token «se puede decodificar».

Dónde se usa

• Inicio de sesión en Microsoft 365 y Google Workspace, y el SSO de las aplicaciones conectadas a ellos.
• Banca en línea y aplicaciones móviles que llaman a sus propias API con access tokens.
• Integraciones entre empresas: el portal de un proveedor que acepta empleados de otra organización por SAML.
• Plataformas de gobierno y universidades que federan identidades entre instituciones.
• Televisores, consolas y herramientas de línea de comandos que piden «ingrese este código en…».

Conceptos clave