Redirecciones abiertas y el parámetro de estado

Cuando el proveedor devuelve el navegador a la aplicación, la aplicación recibe una respuesta y tiene que decidir si es la suya. El parámetro de estado es un valor que el cliente genera al empezar, guarda asociado a la sesión del navegador y vuelve a recibir al final: si lo que vuelve no es lo que guardó, la respuesta no corresponde a esa petición y se descarta.

Eso es lo que impide que una respuesta de inicio de sesión preparada en otro sitio se cuele en la sesión de alguien y le deje la cuenta de otro vinculada sin que lo note. No sustituye a PKCE, que resuelve otra cosa —atar el código a quien lo pidió—, y por eso se usan los dos.

El proveedor solo debe devolver el navegador a un destino registrado, y la comparación debe ser de la cadena completa. Cuando se compara solo el principio, cualquier dirección que empiece igual pasa el filtro: basta con que exista en la aplicación un camino que lleve a otra parte para que la vuelta acabe donde no debía. La práctica vigente de seguridad de OAuth 2.0 pide comparación exacta y deja como única excepción el número de puerto de las aplicaciones que escuchan en la propia máquina del usuario.

Abre el laboratorio y mira cómo compara el proveedor en cada cliente registrado.

De las cinco peticiones que el equipo del cliente anotó, cuatro fueron aceptadas y una rechazada. Entre las aceptadas hay una a la que le faltaba el parámetro de estado, y el proveedor la dejó pasar igual. Eso convierte el parámetro en opcional de hecho, y lo opcional en seguridad acaba desapareciendo.

Vuelve al laboratorio y cruza las dos últimas columnas del registro de peticiones.

Los dos defectos son de configuración del proveedor, no de las aplicaciones, y se corrigen en el mismo sitio. La corrección se escribe en el informe como una instrucción concreta que el administrador pueda ejecutar, no como un principio general.