BIBLIOTECA ASTRACode Cyber

CAPÍTULO 46 · PARTE IV

OpenID Connect, SAML y federación

Federación de identidad con OpenID Connect y SAML: autoridades, assertions, trust, validación, mapping, sesiones y límites frente a autenticación, autorización y provisioning.

Nivel N2–N3 · Estado published

Una autenticación externa todavía exige decisiones locales

La federación permite que un servicio acepte un resultado de autenticación producido por otra autoridad. No elimina la confianza: la vuelve explícita y distribuida. En Northstar, identity.northstar.example autentica a Elena, mientras expense-ui decide si acepta ese resultado y crea una sesión propia. Un identity provider (IdP) u OpenID Provider (OP) autentica al sujeto y emite un artefacto federado; un service provider (SP) o relying party (RP) lo valida, lo relaciona con una cuenta propia y decide si crea una sesión local. Cada verbo pertenece a una autoridad distinta.

Esta separación evita cuatro errores frecuentes. Una assertion válida no es todavía una sesión; una sesión autenticada no concede por sí sola una acción de negocio; un atributo no identifica globalmente a una persona; y una orden de logout no demuestra que todos los participantes hayan eliminado su estado. La pregunta conductora será:

¿Qué debe comprobar un RP para convertir una afirmación externa en una sesión local justificable, sin atribuir al protocolo garantías que pertenecen a la configuración, al acuerdo de confianza o a la política local?

El capítulo 45 estableció que OAuth 2.0 delega autorización y que un access token no es una prueba universal de identidad. Aquí estudiaremos dos familias de federación ampliamente desplegadas: OpenID Connect (OIDC), una capa de identidad construida sobre OAuth 2.0, y Security Assertion Markup Language (SAML) 2.0, un conjunto de assertions, protocolos, bindings y profiles. Usaremos assertion en sentido genérico sólo para una afirmación federada; ID Token será el artefacto OIDC y SAML Assertion, con mayúscula, el elemento XML que puede viajar dentro de una SAML Response. No son formatos intercambiables ni dos nombres para “SSO”.

Una federación une autoridades, no fusiona cuentas

En un sistema directo, el servicio que crea la sesión verifica también el autenticador. En federación, el RP delega esa verificación al IdP y recibe una afirmación verificable sobre el evento. El RP conserva al menos cuatro responsabilidades: confiar en el emisor correcto, validar el artefacto en su contexto, resolver la identidad externa a una cuenta local y aplicar autorización local.

El single sign-on (SSO) es un efecto posible: una sesión ya activa en el IdP permite emitir nuevas assertions para varios RPs sin repetir el mismo gesto de autenticación. Eso no convierte las sesiones de IdP y RP en una sola sesión. Cada participante mantiene estado, duración, cookies, reautenticación y cierre propios.

El National Institute of Standards and Technology (NIST) modela además un trust agreement: la relación que fija emisores y destinatarios, identificadores, claves, atributos permitidos, niveles de assurance, lifecycle y responsabilidades. En su modelo, Identity Assurance Level (IAL), Authentication Assurance Level (AAL) y Federation Assurance Level (FAL) expresan dimensiones distintas: prueba de identidad, autenticación y protección de la transacción federada. El protocolo transporta mensajes dentro de esa relación; no crea por sí solo la legitimidad organizativa de confiar en cualquier emisor que responda.

Conviene distinguir cinco objetos:

Pasar de un objeto al siguiente exige una decisión comprobable. Saltarse una de ellas produce account takeover, confusión de issuer o sesiones que sobreviven más allá de lo previsto.

OIDC: autenticación sobre una transacción OAuth

OpenID Connect añade una capa de identidad a OAuth 2.0. Una Authentication Request OIDC incluye el scope openid; sin él, la solicitud puede seguir siendo OAuth, pero no es una solicitud OIDC. En Northstar, expense-ui es el RP y identity.northstar.example el OP esperado. El RP inicia Authorization Code, mantiene estado de transacción y usa Proof Key for Code Exchange (PKCE) según el perfil de cliente estudiado en el capítulo anterior. El OP devuelve un authorization code al redirect URI y el RP lo canjea en el token endpoint.

La respuesta puede contener tres artefactos con funciones distintas:

El ID Token no debe presentarse como access token genérico a una API. El access token tampoco debe interpretarse como ID Token porque “parece un JWT”. El receptor, audiencia, validación y propósito forman parte del contrato de cada artefacto.

Figura 46-01 · ¿Qué añade OIDC al Authorization Code Flow y quién consume cada artefacto?

Desliza horizontalmente para leer el diagrama a tamaño completo.

El RP inicia Authorization Code con openid, state, nonce y PKCE. Tras el code, recibe por back-channel un ID Token y quizá un access token. Sólo después de validar issuer, destinatario, firma, tiempo y nonce crea su sesión local; el access token va al resource server. Un fallo de contexto impide crear la sesión.

Estado, nonce y PKCE responden a preguntas distintas

state permite correlacionar la respuesta con el estado mantenido por el cliente y contribuye a defender la transacción frente a Cross-Site Request Forgery (CSRF). nonce asocia la sesión del cliente con el ID Token y mitiga replay: cuando se envía, el claim recibido debe existir y coincidir. PKCE vincula el authorization code con el code_verifier conocido por el cliente que inició la operación.

Ninguno sustituye a los otros. Un state correcto no demuestra que el ID Token pertenezca a la transacción; un nonce correcto no impide por sí solo que otro cliente canjee un code; y PKCE no identifica al usuario. Diseñar el flujo como una única “cadena aleatoria” oculta qué fallo detectaría cada comprobación.

Validar un ID Token significa validar su contexto

Un ID Token se representa como JSON Web Token (JWT). En el perfil pedagógico de Northstar se exige firma y se permite cifrado opcional; otros deployments sólo pueden usar una excepción como alg=none bajo las condiciones estrechas y el registro explícito que admite OIDC, nunca por negociación improvisada desde el token. Parsearlo sólo demuestra que tiene una representación reconocible. La validación del Authorization Code Flow exige comprobar, como mínimo, que:

  1. el iss coincide exactamente con el issuer esperado;
  2. aud contiene el client_id de expense-ui; si contiene varios valores, el RP aplica las reglas exactas del flow y de las extensiones negociadas;
  3. si una extensión o perfil produce azp, el claim identifica mediante un OAuth 2.0 Client ID a la parte autorizada y el RP lo valida conforme a ese contrato; azp es opcional en Core y no constituye un MUST universal para toda audiencia múltiple;
  4. la firma se verifica con una clave aplicable del issuer y un algoritmo permitido por la configuración;
  5. el tiempo actual precede a exp, con una tolerancia de reloj acotada;
  6. nonce coincide cuando fue enviado;
  7. los requisitos adicionales del flow y de la política local se cumplen.

Una firma válida es necesaria en los casos que la especificación determina, pero nunca transforma una audiencia equivocada o un issuer inesperado en una respuesta aceptable. La clave tampoco se vuelve confiable porque el header incluya un kid: ese valor ayuda a seleccionar candidatos dentro de un conjunto ya confiable; no es un ancla de confianza.

El sub es un identificador localmente único y no reasignado dentro de un issuer. La clave federada estable que OIDC garantiza es la pareja (iss, sub). Un sub aislado no es global. Un email puede cambiar, ser reciclado, normalizarse de forma distinta o pertenecer a otro ámbito; incluso email_verified no prueba control de una cuenta local en un sistema diferente.

UserInfo complementa, no reemplaza, el ID Token

El endpoint UserInfo es un recurso OAuth protegido. El RP presenta un access token y recibe claims autorizados. Debe comprobar que el sub de UserInfo coincide exactamente con el sub del ID Token; si no coincide, la respuesta no puede asociarse al End-User de esa autenticación.

UserInfo no establece por sí solo una sesión ni extiende la validez del evento original. También debe tratarse la minimización: pedir y conservar sólo los claims que el servicio necesita. Que un OP pueda publicar un atributo no obliga al RP a usarlo para autorización, linking o perfil local.

SAML separa assertion, protocolo, binding y profile

SAML 2.0 no es “un token XML”. Core define assertions y mensajes de protocolo; los bindings indican cómo transportar esos mensajes; los profiles combinan piezas para un caso interoperable; y metadata describe entidades, roles, endpoints, bindings y claves. Una implementación debe declarar qué profile y bindings acepta.

En el segundo carril de Northstar, partner-portal actúa como SP. En Web Browser SSO iniciado por el SP, el usuario solicita un recurso. El SP crea una AuthnRequest y, habitualmente, la envía al endpoint SSO del IdP mediante HTTP-Redirect a través del navegador. El IdP autentica o reutiliza su sesión conforme a su política. Después entrega una SAML Response, normalmente por HTTP-POST, al Assertion Consumer Service (ACS) del SP. El navegador transporta el mensaje: no lo emite ni lo valida.

La Response contiene un status y puede contener assertions. Una assertion puede incluir:

Figura 46-02 · ¿Qué cruza el navegador en SAML Web Browser SSO y qué valida el SP antes de crear sesión?

Desliza horizontalmente para leer el diagrama a tamaño completo.

El SP redirige una AuthnRequest al IdP mediante el navegador. El IdP devuelve una SAML Response por POST al ACS; la Response contiene status y Assertion. El SP valida procedencia, correlación, destino, tiempo, audience y confirmación del sujeto antes de crear su sesión. Un fallo rechaza la respuesta.

El SP valida el mensaje antes de crear una sesión: issuer y firma aplicable; status; InResponseTo cuando corresponde; Destination y Recipient; condiciones temporales; audience; SubjectConfirmationData; y reglas del profile. No basta con encontrar “alguna assertion firmada” dentro del XML. El consumidor debe procesar exactamente el elemento cuya firma validó y cuya posición y relación con la Response espera.

El binding cambia el transporte, no el significado

HTTP-Redirect codifica parámetros en la URL y posee reglas de firma propias. HTTP-POST usa un formulario que el navegador presenta al endpoint. HTTP-Artifact puede transportar una referencia que el SP resuelve por otro canal. Dibujar todos como una flecha IdP→SP borra diferencias relevantes: límites de tamaño, exposición al user agent, correlación y requisitos de resolución.

RelayState preserva estado de aplicación según el binding y el profile, pero no identifica al sujeto ni reemplaza InResponseTo, audience o destination. Una respuesta no solicitada —IdP-initiated— también cambia las garantías de correlación disponibles y debe aceptarse sólo si el despliegue la ha decidido y compensado explícitamente.

Firma, cifrado y destinatario son propiedades independientes

Una firma XML protege integridad y permite autenticar al firmante bajo una clave aceptada. El cifrado protege confidencialidad para quien posee la clave de descifrado. Firmar no oculta atributos; cifrar no demuestra por sí solo quién creó el contenido. El profile y el acuerdo determinan si se firma la Response, la Assertion o ambas, y qué elementos se cifran.

La frase “SAML siempre está firmado” es demasiado imprecisa. Core permite estructuras opcionales, mientras perfiles y políticas imponen requisitos concretos. El verificador debe conocer qué elemento exige firmado, qué clave corresponde al issuer y qué transformaciones XML acepta. También debe rechazar ambigüedades estructurales: verificar una assertion y consumir otra rompe el vínculo entre criptografía y semántica.

Las condiciones tampoco son adornos. NotBefore y NotOnOrAfter delimitan procesamiento bajo reglas exactas; AudienceRestriction limita destinatarios. Dentro de una restricción, varias audiencias expresan alternativas; varias restricciones se satisfacen conjuntamente. La sesión local que nazca después tiene un lifecycle propio: el fin de la ventana de la assertion no destruye automáticamente una sesión ya establecida.

Figura 46-03 · ¿Qué contexto debe coincidir antes de aceptar una identidad OIDC o SAML?

Desliza horizontalmente para leer el diagrama a tamaño completo.

OIDC y SAML pasan por cinco puertas: clave y firma, destinatario, tiempo, correlación o presentación, e identidad y policy local. Los campos difieren, pero en ambos una firma correcta con audience, destinatario, tiempo o transacción incorrectos se rechaza.

Discovery y metadata distribuyen datos; no fabrican confianza

OIDC Discovery publica un documento de configuración que describe issuer, endpoints, capacidades y jwks_uri. El RP parte de un issuer esperado, obtiene su configuración y comprueba que el issuer devuelto coincide exactamente. Después puede recuperar un JSON Web Key Set (JWKS), un conjunto de JSON Web Keys (JWK) candidatas para verificar firmas. Seguir endpoints o claves de un issuer distinto permitiría que datos descubiertos redefinieran la autoridad que debían autenticar.

SAML metadata usa EntityDescriptor y descriptores de rol para publicar entityID, endpoints, bindings y KeyDescriptor. El XML debe llegar mediante una procedencia confiable, por ejemplo una distribución autenticada o metadata firmada validada bajo una clave configurada. HTTPS protege un canal hacia un origen, pero no convierte cualquier documento descargado en miembro autorizado de la federación.

En ambos ecosistemas existe una distinción decisiva:

Un certificado X.509 publicado en SAML metadata suele transportar material de clave. No implica necesariamente que el SP deba validar una cadena WebPKI como si fuera el certificado TLS de un sitio. Esa decisión pertenece al modelo de confianza del deployment.

Rollover exige solapamiento y tiempo

Una rotación segura publica la nueva clave antes de usarla, mantiene la anterior mientras puedan existir mensajes o tokens válidos que la requieran y la retira después de una ventana compatible con lifetimes, cachés y acuerdos. El kid o KeyDescriptor reduce candidatos; no autoriza una clave desconocida.

Ante una firma con clave no disponible, un RP puede refrescar metadata de forma controlada conforme a su política. No debe aceptar una URL de clave aportada libremente por el artefacto ni reintentar sin límites. Disponibilidad y seguridad compiten: una caché demasiado larga conserva claves retiradas; una retirada abrupta rompe mensajes legítimos en vuelo.

Figura 46-04 · ¿Cómo llega una clave descubierta a ser aceptable y qué ocurre durante rollover?

Desliza horizontalmente para leer el diagrama a tamaño completo.

En OIDC, un issuer confiable conduce a Discovery y JWKS; en SAML, un entityID confiable conduce a metadata con endpoints y claves. En ambos se valida procedencia antes de usar datos. K2 se publica mientras K1 sigue disponible y K1 sólo se retira tras la ventana necesaria; una clave desconocida causa refetch controlado o rechazo.

Identidad federada no significa cuenta local ya resuelta

Después de validar la assertion, el RP posee una identidad externa aceptable para esa transacción. Todavía necesita resolverla a un registro local. En OIDC, la clave natural es (iss, sub). En SAML, la clave incluye la autoridad emisora y un NameID interpretado según su formato, qualifiers y contrato. Los identificadores transitorios no deben tratarse como persistentes.

La tabla de vínculos debe ser explícita y auditable. Hay tres resultados posibles:

  1. existe un único vínculo previo y vigente;
  2. no existe vínculo y la política permite enrollment o creación de cuenta;
  3. existe conflicto, múltiples candidatos o evidencia insuficiente y se bloquea o revisa.

Vincular automáticamente por email es peligroso. Un atacante puede controlar en un nuevo issuer el mismo texto que identifica a otra cuenta local; un dominio puede reciclar direcciones; o dos fuentes pueden tener garantías distintas. Para vincular una identidad nueva a una cuenta existente, el RP debe exigir una prueba controlada de la cuenta objetivo —por ejemplo, reautenticación—, consentimiento cuando aplique y un evento auditable.

Los pairwise subject identifiers permiten que el OP entregue valores sub diferentes a distintos RPs para reducir correlación. Esa diferencia no es inconsistencia. Intentar “reconstruir a la persona global” uniendo atributos auxiliares puede derrotar deliberadamente la propiedad de privacidad.

Figura 46-05 · ¿Cuándo una identidad federada puede vincularse a una cuenta local?

Desliza horizontalmente para leer el diagrama a tamaño completo.

Tras validar OIDC o SAML, el RP/SP deriva una clave de identidad externa y busca un vínculo. Un vínculo único conduce a la cuenta local; la ausencia exige enrollment o autenticación de la cuenta objetivo. Email coincidente, identificador inadecuado o matches múltiples llevan a bloqueo o revisión. Crear el vínculo es una mutación local auditable, distinta de provisioning.

Account linking tampoco es provisioning. Linking relaciona una identidad externa con una cuenta; just-in-time (JIT) provisioning crea o actualiza una cuenta durante una autenticación; System for Cross-domain Identity Management (SCIM) sincroniza recursos de identidad por otro canal; y autorización decide acciones sobre objetos. Pueden cooperar, pero cada mutación necesita owner, precondición, evidencia y reversión propias.

En Northstar, que el IdP marque a Elena como suspendida cambia primero el estado de la fuente. La baja sólo alcanza expense-ui si existe una señal o flujo de provisioning contratado, el RP la recibe y la aplica al vínculo o cuenta local. Rechazar una nueva autenticación demuestra ese camino de entrada; no prueba que una sesión ya creada haya terminado. Para afirmar deprovisioning efectivo hay que observar por separado el estado upstream, el evento y su freshness, la cuenta/vínculo local, el rechazo de una federación nueva y el comportamiento de las sesiones existentes. JIT no proporciona por sí solo el camino inverso de baja.

Logout es coordinación entre estados independientes

Al terminar una sesión RP, todavía pueden seguir activas la sesión del OP, otras sesiones RP, access tokens y refresh tokens. OIDC RP-Initiated Logout permite que un RP solicite logout en el end_session_endpoint. Un id_token_hint ayuda al OP a identificar la sesión; un redirect posterior debe cumplir el registro y las comprobaciones definidas, y state puede correlacionar la respuesta.

Otros mecanismos OIDC notifican RPs por front-channel —dependiente del user agent— o back-channel —mediante un logout token dirigido al RP—. SAML Single Logout coordina LogoutRequest y LogoutResponse entre participantes y puede usar SessionIndex. Ningún nombre “single” convierte la operación en una transacción atómica distribuida.

Un participante puede no soportar el mecanismo, estar inaccesible, rechazar la notificación o haber creado sesiones adicionales. El estado correcto no es “todo cerrado”, sino un vector por autoridad: cerrada observada, activa, fallo o desconocida. Los tokens permanecen en otro carril y sólo cambian por expiración, revocación o policy explícita.

Figura 46-06 · ¿Qué estados cambian, y cuáles pueden quedar desconocidos, durante logout federado?

Desliza horizontalmente para leer el diagrama a tamaño completo.

RP-A inicia logout y cierra su sesión. El proveedor termina o modifica su sesión y notifica a RP-A y RP-B; A confirma, pero B no responde, por lo que su estado permanece desconocido o activo. Access y refresh tokens aparecen aparte y no cambian salvo revocación, expiración o policy explícita.

El monitoreo debe registrar inicio, participantes previstos, confirmaciones, errores y límites temporales sin almacenar assertions o tokens reutilizables. Un redirect final exitoso prueba navegación, no cierre remoto. La recuperación ante cuentas comprometidas debe combinar invalidación local, señales federadas, revocación de artefactos y lifecycle de identidad; ningún endpoint de logout sustituye ese plan.

Caso trabajado: Northstar cambia de proveedor de identidad

Northstar migra expense-ui de un IdP SAML al OP OIDC ya configurado y conserva partner-portal como SP SAML. El equipo intenta mantener cuentas locales vinculando el nuevo login por email. Durante el piloto aparecen tres síntomas: una cuenta termina vinculada a otra persona, algunos ID Tokens se rechazan tras un rollover y el botón “cerrar todas las sesiones” deja una sesión activa en un segundo RP.

La primera hipótesis debe separar fallos:

El diagnóstico reutiliza los gates ya construidos. Para linking se reconstruyen (entityID, NameID), (iss, sub) y el evento que mutó la tabla; el mismo email desde un issuer no autorizado debe terminar en rechazo o revisión, no en auto-link.

Para rollover se conservan issuer, kid, algoritmo permitido, instante de obtención del JWKS, cache headers, claves candidatas y resultado de firma. La prueba positiva cubre K1 y K2 durante el solapamiento; ante kid desconocido o una referencia de clave no autorizada, el RP sólo refresca su fuente configurada o rechaza.

Para logout, se registra el estado independiente de OP, RP-A y RP-B. El resultado esperado permite RP-A=cerrada, OP=cerrada y RP-B=desconocida si no existe confirmación. El control no afirma éxito global: expone participantes pendientes y ejecuta mecanismos de revocación separados cuando la política lo exige.

Diagnóstico: del síntoma a la autoridad que decide

Una integración federada se depura sin volcar secretos completos. Para una transacción fallida conviene registrar hashes o identificadores no reutilizables, tiempos, issuer, audiencia, endpoint, clave seleccionada, resultado de cada gate y decisión final. La secuencia es:

  1. identificar protocolo, profile, flow y binding efectivos;
  2. fijar la configuración local esperada antes de leer el mensaje;
  3. verificar procedencia y elemento criptográficamente cubierto;
  4. evaluar destinatario, tiempo y correlación;
  5. derivar la identidad federada con su ámbito;
  6. resolver el vínculo local y registrar cualquier mutación;
  7. crear sesión sólo tras cerrar los gates anteriores;
  8. comprobar una variante negativa cambiando una sola propiedad.

Una respuesta con firma válida y audiencia incorrecta debe fallar. También deben fallar un nonce distinto, un SAML Recipient ajeno, metadata de procedencia no confiable y un email coincidente sin vínculo probado. Esas pruebas negativas demuestran que cada gate decide realmente, no que la ruta feliz simplemente funciona.

Cómo elegir y operar la federación

OIDC suele integrarse naturalmente con aplicaciones modernas y APIs relacionadas con OAuth; SAML conserva una amplia base de SPs empresariales y profiles XML maduros. Esta observación no justifica una tabla universal de “mejor/peor”. La decisión depende de interoperabilidad requerida, perfiles soportados, assurance, lifecycle de claves, atributos, logout, privacidad, operación y capacidad de prueba.

Antes de habilitar un partner, el diseño debe responder:

La respuesta debe expresarse como configuración y pruebas, no como confianza genérica en una marca o biblioteca.

Síntesis: aceptar una assertion es una cadena de decisiones

OIDC y SAML permiten que un RP se apoye en un evento de autenticación externo, pero no le entregan una identidad global ni una autorización terminada. El modelo profesional conserva la cadena completa:

autoridad esperada → configuración confiable → mensaje y firma → destinatario → tiempo → correlación → identidad federada → vínculo local → sesión RP → autorización local.

Cada transición puede fallar de forma independiente. El ID Token se valida para su RP y transacción; la SAML Response y su Assertion se consumen conforme al profile; discovery y metadata distribuyen datos dentro de una confianza configurada; las claves rotan con solapamiento; el linking exige prueba y policy; y logout produce estados parciales que deben observarse.

El resultado no es “login mágico”. Es un argumento verificable de por qué este RP aceptó esta afirmación de este emisor, para este sujeto y este contexto, y qué autoridad conserva la siguiente decisión.

Fuentes primarias para continuar