Resumen

  • RFC 9207 da al cliente OAuth un comprobante acotado: el emisor indicado en la respuesta debe ser idéntico al emisor que el cliente guardó para esa solicitud. Si no coincide, el flujo termina antes de enviar el código a un endpoint erróneo.
  • El parámetro iss identifica el contexto del servidor de autorización. No autentica al usuario, no valida el código, no demuestra que se emitió un token y no prueba la decisión del servidor de recursos.
  • La operación segura conserva registros separados de la solicitud, el emisor esperado, los metadatos, el emisor recibido, la comparación, el canje del código, la validación del token, la decisión sobre el recurso y la recuperación.

El callback peligroso parece normal.

El navegador regresa a una URI de redirección registrada. state coincide con el valor creado por el cliente. La respuesta incluye un código emitido por un servidor de autorización honesto. No se robó una contraseña ni se falsificó el código. Pero un cliente que trabaja con más de un servidor todavía puede cometer el error decisivo: enviar ese código auténtico a un token endpoint controlado por el atacante.

Se han mezclado dos registros plausibles. Uno dice qué servidor creía haber elegido el cliente al comenzar. El otro es una respuesta que volvió por el navegador del usuario. La respuesta original de OAuth 2.0 no identificaba expresamente al servidor que la había creado. Si una ruta genérica o unos metadatos hostiles borran esa separación, una credencial válida puede cruzar hacia otro operador.

RFC 9207 repara ese hueco con una pieza deliberadamente pequeña. OAuth 2.0 Authorization Server Issuer Identification, publicada en marzo de 2022 como documento de estándares del IETF, es obra conjunta de Karsten Meyer zu Selhausen y Daniel Fett. Define iss en la respuesta de autorización. El servidor compatible incluye su identificador de emisor tanto en respuestas exitosas como en errores. El cliente compara el valor recibido con el emisor del servidor al que envió la solicitud.

Si las cadenas no coinciden, el cliente rechaza la respuesta y no continúa con la concesión.

Ese es todo el poder del campo, y por eso resulta valioso.

El callback no decía quién respondía

OAuth separa funciones de forma intencional. El propietario del recurso usa un agente de usuario. Un cliente solicita una concesión al servidor de autorización. Más tarde lleva esa concesión al token endpoint. Finalmente presenta un token de acceso al servidor de recursos. La composición permite que sistemas independientes cooperen, pero también abre decisiones de encaminamiento que no se resuelven porque el navegador haya llegado al callback esperado.

RFC 6749 colocó en la respuesta un código y, si la solicitud lo llevaba, el mismo state. Ese estado es esencial: enlaza la respuesta con la sesión del agente de usuario y combate la falsificación de solicitudes entre sitios. Sin embargo, no responde a otra pregunta: ¿qué servidor de autorización emitió la respuesta?

Con un solo servidor, la diferencia puede quedar oculta porque no existe un paquete alternativo de endpoints. Al añadir un segundo, ya no basta con recordar que hay “un flujo OAuth pendiente”. El cliente tiene que recordar a qué emisor pertenece. RFC 9700, la práctica de seguridad vigente para OAuth, exige a los clientes con varios servidores impedir ataques de mix-up y vincular el emisor previsto a cada solicitud.

El trabajo público de Daniel Fett ayuda a situar este problema sin convertir un estándar colectivo en una biografía de inventor. Su sitio lo presenta como consultor especializado en identidad y protocolos web, activo en OAuth y OpenID Connect. Su registro del IETF mostraba cuatro RFC, incluida RFC 9207, en septiembre de 2026. Ese contexto explica una línea de investigación; no le atribuye la autoría exclusiva ni el control de una implementación.

Un emisor representa un paquete de endpoints

El identificador de emisor no es un nombre para mostrar. Según RFC 8414, es una URL HTTPS sin consulta ni fragmento. Sirve de ancla para un documento de metadatos que identifica el endpoint de autorización, el token endpoint, las ubicaciones de claves y otras capacidades. Un mismo host puede alojar distintos emisores separados por ruta.

Ese paquete es lo que debe conservarse. El usuario puede ver una página de autorización honesta mientras la configuración del cliente empareja esa página con el token endpoint del atacante. RFC 9700 advierte que no basta con guardar la URL de autorización: un actor malicioso puede declarar la URL honesta como propia y aportar un endpoint de tokens bajo su control. El emisor es el identificador estable de todo el conjunto previsto.

RFC 9207 une la respuesta que trae el navegador con ese conjunto. Si se usan metadatos, el iss de la respuesta debe ser idéntico al issuer de los metadatos, que anuncian compatibilidad mediante authorization_response_iss_parameter_supported. El cliente extrae el valor, lo decodifica como formulario y realiza una comparación simple de cadenas con el emisor esperado.

No existe coincidencia aproximada. Una ruta distinta, una barra adicional o dos emisores en el mismo host no son equivalentes por parecerse. No es una decisión semántica para personas; es encaminamiento determinista.

La autoridad sigue siendo local. El servidor declara su emisor. Los metadatos describen el paquete de endpoints. El cliente registra su elección, conserva el estado de compatibilidad y decide si acepta o aborta. Ningún coordinador mundial ejecuta la comparación. Cada cliente responde por su configuración.

Coincidir permite seguir; no demuestra el resultado

El error analítico más fácil es atribuir demasiado al campo.

Un iss coincidente no autentica al propietario del recurso. El servidor todavía puede pedir inicio de sesión o devolver un error. Tampoco demuestra que la persona entendiera el alcance solicitado; eso pertenece a la interacción de autorización y a la política del producto.

La coincidencia no valida el código. El token endpoint correcto aún debe comprobarlo, autenticar al cliente cuando proceda y revisar la URI de redirección y demás condiciones. El código puede haber caducado, ser un replay o pertenecer a otro cliente.

Tampoco prueba la emisión de un token. iss no establece su tipo, audiencia, scope, duración, restricción al emisor de la solicitud ni estado de revocación. El servidor de recursos conserva su decisión. Incluso un token válido no demuestra que la acción de negocio terminara o que el usuario viera el resultado.

La secuencia de pruebas es otra: el cliente creó una solicitud y guardó el emisor con estado ligado al navegador; llegó una respuesta; la respuesta nombró un emisor; el cliente comparó y aceptó o abortó; escogió endpoints de metadatos validados; el token endpoint aceptó o rechazó el código; el servidor de recursos validó el token; la aplicación observó un resultado y conservó una vía de recuperación.

RFC 9207 gobierna el cuarto paso. Llamarlo “éxito de OAuth” borra todos los demás.

El campo no es una firma

El iss de una respuesta ordinaria no está protegido criptográficamente. RFC 9207 lo reconoce. Solo parece una contradicción si se presenta el parámetro como certificado universal.

La amenaza que resuelve es más estrecha. En un mix-up, el cliente recibe una respuesta de un servidor no comprometido, pero se confunde respecto del paquete de endpoints al que debe enviar el código. Si el atacante puede modificar la respuesta honesta antes de que llegue al cliente, ya puede leer el código y no necesita la ruta de mix-up. El parámetro evita la confusión de encaminamiento dentro de ese modelo; no promete integridad frente a cualquier adversario.

Cuando el sistema necesita una respuesta protegida, puede usar mecanismos que incluyan el emisor dentro de una envoltura con integridad. JARM utiliza un JWT firmado. Ciertos flujos de OpenID Connect devuelven un ID Token desde el endpoint de autorización y también pueden transportar el emisor si se valida correctamente. Si aparecen varios identificadores y no son iguales, la respuesta debe rechazarse.

Es una aplicación práctica de la especificación inicial mínima: introducir el menor dato común que expone la ambigüedad sin imponer a todos el mismo futuro. Las envolturas fuertes, la compatibilidad heredada y la migración siguen siendo decisiones locales. RFC 9700 también admite URI de redirección diferentes por emisor, siempre que el cliente las verifique.

La compatibilidad heredada necesita dueño

Los servidores no se actualizan simultáneamente. Por eso RFC 9207 conserva un estado de compatibilidad por servidor.

Si el cliente sabe que un servidor admite iss, debe rechazar una respuesta donde falte. Si sabe que no lo admite, puede aceptar la respuesta o negarse a trabajar con ese servidor. La política local decide. Recibir el parámetro desde un servidor que no anunció soporte también exige una decisión explícita, pues puede revelar una configuración incoherente.

Esa flexibilidad ubica la responsabilidad. Un cliente multiemisor necesita un inventario de emisores, metadatos, indicador de soporte, fecha y fuente de esa creencia, excepción heredada y dueño de su retirada. Sin fecha de salida, la “compatibilidad” se convierte en una ruta permanente alrededor de la defensa.

Añadir otro proveedor modifica la condición. Un cliente de un solo emisor quizá no necesite la defensa hoy. Al incorporar el segundo, la vieja suposición deja de ser cierta. La expansión comercial crea una migración de seguridad que debe ocurrir antes del lanzamiento.

El comprobante que se puede probar

Leer una vez los metadatos no establece conformidad. Una prueba operativa comienza cuando se crea la solicitud.

Registra la solicitud, la unión con el agente de usuario, el emisor elegido, la versión de metadatos, los endpoints, el indicador de soporte y la URI de redirección. Al volver, registra si había iss, su valor decodificado, el valor esperado, la comparación y si se suprimió efectivamente el canje del código. Debe incluir respuestas exitosas y errores, valores ausentes o duplicados, emisores desconocidos y dos emisores del mismo host con rutas distintas.

La prueba negativa es la decisiva. Tras una discrepancia, ninguna petición con el código, una credencial del cliente o un token debe alcanzar el endpoint inesperado. Los logs del cliente y de endpoints de prueba tienen que coincidir. Mostrar un error mientras sale una solicitud de red no es una defensa.

En incidentes, una discrepancia demuestra una comparación fallida, no necesariamente un compromiso. El rechazo del token endpoint prueba que rechazó una concesión, no que la respuesta fuera hostil. Una denegación de recurso tampoco demuestra retroactivamente que el enlace de emisor funcionó.

El parámetro cumple su función cuando hace visible una sola ambigüedad antes de mover un secreto. No sustituye las decisiones que pertenecen al cliente, al servidor de autorización, al token endpoint y al servidor de recursos.

Fuentes