Planteamiento y contexto
Un cliente SaaS se integra con un IdP empresarial, un IdP público y el servidor de autorización de un socio. Un atacante intenta hacer que el cliente trate una solicitud iniciada en el servidor A como una respuesta del servidor B, enviando potencialmente un código al endpoint de tokens incorrecto o aplicando una configuración de cliente errónea. Diseña defensas contra Mix-Up que cubran la vinculación del emisor (issuer binding), las respuestas de autorización, el intercambio de tokens, el descubrimiento de metadatos, los errores y la migración.
El RFC 9207 define el parámetro de respuesta iss para que un servidor de autorización se identifique a sí mismo en una respuesta de autorización OAuth. El RFC 9700 enumera la identificación del emisor como una defensa contra el Mix-Up. El objetivo es vincular "el usuario devuelto" con "qué servidor de autorización completó este flujo", en lugar de depender únicamente de state.
Qué está evaluando el entrevistador
- Reconocimiento de la confusión de código, endpoint de tokens y configuración del cliente en flujos con múltiples emisores.
- Vinculación del emisor con state, URI de redireccionamiento, PKCE y el registro de la solicitud de autorización.
- Comprobaciones de consistencia entre los metadatos de descubrimiento, las URL de los emisores, TLS, JWKS y los endpoints de tokens.
- Manejo seguro de valores
issfaltantes, desconocidos, en conflicto o falsificados. - Un plan de migración que admita IdPs más antiguos sin mantener una alternativa de contingencia (fallback) insegura para siempre.
Preguntas para clarificar
- ¿La lista de emisores es estática, se registra dinámicamente o se descubre por tenant?
- ¿El cliente utiliza una única URI de redireccionamiento compartida o un callback independiente para cada emisor?
- ¿Se admite OIDC, lo que requiere la validación de
iss,audy nonce del ID Token? - ¿Los servidores de autorización legados devuelven
issy puede cada uno utilizar una configuración de cliente aislada? - ¿Es PKCE obligatorio y debe el endpoint de tokens utilizar la configuración del emisor original?
Respuesta en 30 segundos
Almacena un emisor inmutable, documento de descubrimiento, endpoint de autorización, endpoint de tokens, JWKS, ID de cliente y política de URI de redireccionamiento para cada servidor de autorización. Al inicio de la autorización, genera state, nonce y PKCE, y persiste el emisor esperado en un registro efímero del lado del servidor. El callback debe exigir un iss permitido que coincida con ese valor esperado, y luego canjear el código utilizando únicamente la configuración del emisor registrada. Los valores faltantes, desconocidos o en conflicto detienen el flujo; el cliente nunca adivina ni cambia silenciosamente.
Respuesta en profundidad
1. Establecer una configuración de confianza por emisor
Utiliza una URL canónica del emisor como clave de configuración, incluyendo esquema, host, puerto y ruta, y compárala de acuerdo con las reglas exactas del emisor. Almacena los endpoints de autorización y de tokens, JWKS, credenciales de cliente, alcances (scopes) permitidos y URIs de redireccionamiento.
Cuando se permita el descubrimiento, exige que el issuer del documento coincida exactamente con el valor configurado y descárgalo a través de HTTPS. Un emisor proporcionado por el usuario no debe provocar la recuperación arbitraria de metadatos o JWKS.
2. Vincular el emisor al iniciar la autorización
Genera un state impredecible y persiste state, emisor esperado, versión de la configuración del cliente, URI de redireccionamiento, desafío PKCE y hora de creación en una sesión del lado del servidor o almacén efímero. El navegador lleva solo una referencia, no la configuración mutable del tenant.
La URL de autorización debe utilizar la URI de redireccionamiento exacta registrada para ese emisor y cliente. Si un tenant o IdP se selecciona dinámicamente, selecciónalo y regístralo en el servidor; el callback no debe elegir retroactivamente la configuración inicial.
3. Validar el iss de la respuesta de autorización
El parámetro de respuesta iss de RFC 9207 debe encontrarse en el conjunto de emisores aprobados y coincidir con el emisor esperado en el registro de state. Un servidor sin iss solo puede utilizar una ruta de compatibilidad con un callback aislado, un cliente aislado o un límite de confianza; un callback compartido no debe adivinar entre todos los emisores.
Valida state, emisor, respuestas de error y el contexto de redireccionamiento antes de procesar el código. Rechaza variantes desconocidas, duplicadas o con diferencias de codificación y mayúsculas/minúsculas. Las páginas de error muestran un fallo genérico y nunca reflejan una URL no verificada.
4. Mantener el intercambio de tokens en el emisor original
Lee el endpoint de tokens, la autenticación del cliente y el verificador de PKCE desde el registro de state, nunca concatenando una URL a partir de la entrada del callback. Si la respuesta de tokens contiene un emisor, ID Token o reclamos (claims) de identidad, compáralos con el emisor original y el ID de cliente.
PKCE vincula al canjeador del código, state vincula la sesión del navegador y el emisor vincula al servidor de autorización. OIDC también requiere la validación del emisor, audiencia, firma, tiempo y nonce del ID Token; el iss del callback por sí solo no es suficiente.
5. Asegurar el descubrimiento, JWKS y la rotación
El descubrimiento, los endpoints de tokens y las JWKS deben permanecer dentro del límite de confianza de un emisor aprobado. Utiliza almacenamiento en caché controlado de JWKS y versiones de claves; un kid faltante puede desencadenar una actualización limitada, nunca un acceso a URLs arbitrarias. Controla las versiones de la configuración del emisor para que el state en curso continúe utilizando la versión registrada en el momento de la creación.
El fallo de descubrimiento, la discrepancia de emisor, el fallo de TLS o las firmas no verificables fallan de forma cerrada (fail closed) para flujos de alto riesgo. No cambies los endpoints de tokens a otro emisor por motivos de disponibilidad.
6. Prevenir el abuso de state y el agotamiento de recursos
Asigna a los registros de state un TTL corto, consumo de un solo uso y límites de concurrencia. Los callbacks duplicados, el state desconocido o expirado y el emisor incorrecto invalidan el flujo. Limita los parámetros del callback y evita registrar en logs JWTs anómalos, URLs o descripciones de error largas.
Rastrea emisores faltantes y en conflicto, emisores desconocidos, repetición de state, fallos de descubrimiento, actualizaciones de JWKS, fallos de PKCE y finalizaciones por emisor. Agrupa las alertas por tenant y emisor para separar los errores de configuración de los ataques.
7. Migrar servidores de autorización legados
Realiza un inventario de emisores y capacidades de callback, luego exige RFC 9207 para los servidores compatibles. Los servidores legados pueden utilizar URIs de redireccionamiento aisladas, clientes aislados o un proxy del lado del servidor con vinculación explícita, una fecha límite de finalización y auditoría. No mantengas indefinidamente un callback compartido que adivine el emisor a partir de un código.
Durante el despliegue gradual, compara tasas de finalización, errores, latencia del callback y conflictos de emisor. Pausa el despliegue de nuevos tenants cuando las señales empeoren. Mantén los registros de state y un interruptor de reversión (rollback switch), pero nunca deshabilites PKCE ni vuelvas a abrir un endpoint de tokens no vinculado.
Respuesta modelo
Para cada servidor de autorización mantendría una política fija de emisor, documento de descubrimiento, endpoint de autorización, endpoint de tokens, JWKS, cliente y URI de redireccionamiento. El inicio de la autorización genera state, nonce y PKCE, y almacena el emisor esperado y la versión de configuración del lado del servidor. El callback valida state y el iss de RFC 9207, exigiendo un valor aprobado que coincida con el emisor esperado; a continuación, el intercambio de tokens utiliza únicamente el endpoint y las credenciales de cliente registrados.
El emisor del descubrimiento, el emisor del ID Token de OIDC, la audiencia, la firma y el nonce se verifican nuevamente. Un emisor faltante o en conflicto, un state expirado o repetido y los fallos de JWKS detienen el flujo en lugar de cambiar silenciosamente. Los IdPs legados utilizan callbacks aislados o un proxy con fecha límite. Monitorea los conflictos de emisor, la repetición de state, los fallos de PKCE y la tasa de finalización por emisor.
Errores comunes
- Verificar únicamente state y asumir que identifica al servidor de autorización.
- Construir URLs de tokens o de JWKS directamente a partir de la entrada del emisor en el callback.
- Permitir que continúen valores
issfaltantes o desconocidos probando cada IdP. - Omitir comprobaciones cruzadas entre el emisor de descubrimiento, el emisor del ID Token y el endpoint de tokens.
- Mantener un callback compartido y la adivinación de emisores basada en código indefinidamente durante la migración.
- Describir PKCE, state, nonce y la vinculación del emisor como un único control.
- Escribir emisores no validados, JWTs o URLs de error en logs o páginas.
Preguntas de seguimiento y respuestas
¿Por qué state por sí solo no puede prevenir el Mix-Up?
State vincula una sesión de navegador y un callback, pero el cliente aún puede enviar un código con state válido al endpoint de tokens incorrecto si no conoce el emisor de la respuesta. La vinculación del emisor proporciona esa identidad del servidor.
¿Puede continuar el flujo cuando un callback no tiene iss?
Solo bajo una política de compatibilidad explícitamente aislada, como un callback o proxy separado por servidor legado. Un callback compartido no debe iterar sobre los emisores y adivinar.
¿Puede un usuario ingresar una URL de emisor?
La selección solo puede mapearse a un emisor aprobado. El servidor no debe recuperar descubrimiento o JWKS para entradas arbitrarias, lo que crearía riesgos de SSRF, phishing y de raíz de confianza.
¿Cómo se evitan las confusiones en la configuración del tenant?
El registro de state contiene el tenant, el emisor, la versión de configuración y la URI de redireccionamiento. El callback y el intercambio de tokens leen únicamente ese registro. Las actualizaciones de configuración no sobrescriben el state en curso durante su TTL.
¿Qué más se requiere para OIDC?
Valida la firma del ID Token, el emisor, la audiencia, la expiración, la hora de emisión, el nonce y el contexto de autenticación requerido, además del iss del callback. Los parámetros del callback no pueden reemplazar la validación del ID Token.
¿Cómo demuestras que la migración no debilitó la seguridad?
Registra la política aplicada, la hora de activación y el tipo de callback por emisor. Prueba emisores faltantes y falsificados, state entre diferentes tenants, reemplazo de endpoints y callbacks repetidos, y monitorea los accesos a rutas alternativas (fallback hits) para que permanezcan en cero o dentro de una excepción aprobada.