Código de autorización con PKCE

En el flujo de código, el servidor de autorización no entrega el token en el navegador: entrega un código de un solo uso que el cliente canjea después, por un canal directo, en el punto /token. El riesgo es que ese código se filtre en el camino (un esquema propio que otra app del teléfono también registra, un registro, una redirección) y lo canjee alguien distinto de quien lo pidió.

PKCE (RFC 7636) cierra ese hueco con un secreto de un solo uso que nunca viaja por el navegador. Antes de redirigir, el cliente genera un verificador aleatorio y envía solo su huella SHA-256 codificada, el reto. Al canjear el código, presenta el verificador; el servidor calcula la huella y la compara con el reto que guardó. Quien solo tiene el código no tiene el verificador. RFC 9700 lo exige a los clientes públicos, lo recomienda también a los confidenciales y pide que el servidor lo soporte.

RFC 7636 define dos formas de calcular el reto. La que se debe usar es S256, la huella SHA-256 del verificador. La otra existe solo por compatibilidad con clientes que técnicamente no puedan calcular un hash: en ella el reto es el verificador tal cual, así que cualquiera que vea la solicitud de autorización (un registro, un proxy, el historial) ya tiene lo que se presentará en el canje. El RFC dice que no debe usarse en implementaciones nuevas.

Abre solicitudes-autorizacion.txt y compara el método de las dos versiones de la app móvil.

Un reto que el servidor guarda y luego no comprueba es decoración. Si un código se pidió con reto, su canje debe traer el verificador que corresponde, y si no lo trae, el servidor debe rechazarlo con invalid_grant. Un modo «opcional» que acepta el canje cuando el verificador falta deja la protección en manos de quien canjea, que es justo la persona de la que PKCE protege.

Cruza politica-pkce.yml con las dos muestras: qué código llevaba reto en la solicitud y llegó al canje sin verificador.

El verificador es un secreto: si se puede predecir, PKCE no protege nada. El RFC pide que tenga entre 43 y 128 caracteres de un alfabeto concreto y sugiere generarlo con 32 bytes de un generador criptográfico codificados en base64url, que dan 43 caracteres. En el navegador, el generador apropiado es el de la interfaz criptográfica (crypto.getRandomValues); los generadores pensados para animaciones o juegos no sirven para secretos.

Abre pkce-anfitriones.js y sigue la función que arma el verificador.

El equipo del panel defiende su versión: usa S256, guarda el verificador solo en la pestaña y su alfabeto es el que pide el RFC. Vuelve a crearVerificador y compara cada propiedad con lo que acabas de leer en la tarea anterior.