El flujo de código con PKCE y los flujos que se desaconsejan

En el flujo de código de autorización el cliente manda a la persona al servidor de autorización. Allí se identifica y consiente. El servidor la devuelve al cliente con un código de un solo uso en la dirección de retorno, y el cliente lo canjea por tokens en una llamada directa al servidor, por un canal que no pasa por el navegador.

El riesgo es que alguien que vea el código lo use antes que el cliente legítimo. PKCE (RFC 7636) lo evita: el cliente inventa un secreto al azar, el code_verifier (de 43 a 128 caracteres), y manda en la primera petición solo su huella, el code_challenge, con el método S256 (huella SHA-256 codificada en base64url). Al canjear el código manda el secreto original y el servidor comprueba que coincide con la huella. Un código copiado no sirve sin el secreto. El método plain envía el secreto sin transformar y la propia RFC lo reserva para clientes que no pueden hacer la huella.

En el flujo implícito (response_type=token) el servidor no entrega un código sino el token de acceso mismo, en el fragmento de la dirección del navegador. Nació cuando las páginas web no podían hacer llamadas a otros dominios. Hoy ya no hace falta, y es peor: el token queda expuesto en el historial, en registros intermedios y en cualquier script de la página, y no hay forma de ligarlo a quien lo pidió. La guía de seguridad vigente de OAuth 2.0 (RFC 9700) pide no usarlo y emplear en su lugar el flujo de código con PKCE.

Abre el laboratorio, mira la tabla solicitudes_de_autorizacion y busca el cliente que pide el token directamente.

La RFC 9700 exige PKCE a los clientes públicos y lo recomienda también a los confidenciales. Una solicitud puede estar mal de dos maneras: no traer desafío (el guion de la columna code_challenge_method) o traerlo con un método débil. En el registro hay un cliente que manda su desafío con plain: el secreto viaja a la vista en la misma petición que el servidor ve y que el navegador deja en sus registros, así que el desafío no cumple su función.

Mira de nuevo las dos filas de resultado del flujo implícito: el token queda «entregado en el fragmento de la URL». Ese resultado resume el problema entero. Cuando el token viaja por el navegador, cualquier cosa que lea la dirección puede guardarlo, y no hay una llamada posterior en la que el servidor compruebe que quien lo recibe es quien lo pidió.

Para saber cuánto del tráfico ya sigue el flujo recomendado, cuenta las solicitudes que piden un código (response_type=code) y mandan además el desafío S256. Las demás, sea por falta de desafío, por método plain o por flujo implícito, son las que hay que corregir.