State, nonce y protección del retorno

Tres valores atan la respuesta al inicio, y cada uno responde una pregunta distinta. El state es un valor aleatorio que el cliente guarda en la sesión del navegador y recibe de vuelta en el retorno: responde «¿esta respuesta es de un inicio que yo empecé aquí?». El nonce es otro valor aleatorio que el cliente envía y que el proveedor copia dentro del token de identidad: responde «¿este token es de ese inicio y no uno viejo reutilizado?». El verificador de PKCE responde «¿quien canjea el código es quien lo pidió?».

RFC 9700 admite que PKCE haga también de protección contra peticiones cruzadas en el retorno, pero solo si el servidor de autorización lo exige siempre; si no, el cliente debe usar state o nonce. Los tres tienen en común algo que suele olvidarse: valen solo si son únicos por inicio y si su ausencia se trata como fallo.

Un nonce sirve porque solo el navegador que empezó el inicio lo conoce. Si es una constante, cualquier token de identidad que ese proveedor emita para esa aplicación lo trae, y la comprobación del retorno pasa con el token de cualquier persona. La razón que dejó escrita el equipo en el comentario es un malentendido frecuente: el proveedor exige que el valor vaya, no que sea siempre igual.

Abre retorno.py y busca qué valor se envía como nonce y con qué se compara después.

El state se comprueba en el retorno: se saca de la sesión y se compara con el recibido. La pregunta importante es qué pasa cuando en la sesión no hay ninguno, que es justo lo que ocurre cuando alguien abre un enlace de retorno preparado en otro navegador: la persona queda dentro de una cuenta que no es suya y todo lo que guarde después se va a esa cuenta. La regla segura es fallar cerrado: sin state guardado, el retorno se rechaza.

Lee la condición del retorno en retorno.py, cruza registro-retornos.txt y compara con queja-QJ-882.txt.

Cuando un cliente trabaja con varios servidores de autorización y recibe todas las respuestas en la misma ruta, necesita saber de cuál viene cada una antes de canjear el código; si no, puede mandar un código al punto de token equivocado o confiar en una respuesta que no es del proveedor al que envió a la persona. Es la confusión entre proveedores que describe RFC 9700. La defensa que recomienda es que el servidor se identifique dentro de la respuesta de autorización, como define RFC 9207, y que el cliente compare ese valor con el emisor al que envió a la persona; la alternativa más débil es una ruta de retorno distinta por proveedor.

Cruza metadatos.txt y registro-retornos.txt con lo que lee retorno.py de la respuesta.

El retorno que encontraste en la tarea 3 no tenía state ni verificador en la sesión, y aun así el canje y la validación del token de identidad pasaron. Lee la nota de Quiba en metadatos.txt, la línea de ese retorno en el registro y la comparación del nonce en retorno.py.