Flujo de código de autorización de OAuth 2.0 con PKCE para clientes públicos

Qué es

En el authorization code grant, el navegador se redirige al servidor de autorización, el usuario da su consentimiento y el servidor redirige de vuelta con un code de corta duración, que el cliente canjea por tokens en el endpoint de tokens. Un cliente confidencial autentica ese canje con su secreto de cliente; un cliente público no tiene ninguno, por lo que cualquiera podría canjear un código robado. RFC 7636 (citado) cierra esa brecha: el cliente genera un code_verifier, una cadena aleatoria de entre 43 y 128 caracteres no reservados, envía code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) con code_challenge_method=S256 en la solicitud de autorización, y envía el code_verifier en claro junto con el código al endpoint de tokens. El servidor recalcula el hash y rechaza la solicitud si no coincide. El RFC establece que un cliente capaz de usar S256 debe usarlo; el método plain existe solo para clientes con limitaciones.

Por qué importa

RFC 8252 (citado) exige que los clientes públicos de aplicaciones nativas implementen PKCE y que los servidores de autorización lo admitan, y pide que las aplicaciones nativas usen el navegador del sistema en lugar de una web view embebida. RFC 9700 (citado), la mejor práctica actual de seguridad de OAuth (BCP), amplía el requisito: los clientes públicos deben usar PKCE, se recomienda que los clientes confidenciales también lo usen, los clientes no deben usar el implicit grant (los tokens en el fragmento de la URL se filtran por el historial y los referrers), los refresh tokens de los clientes públicos deben estar vinculados al remitente (sender-constrained) o rotarse, y los redirect URI deben compararse por coincidencia exacta de cadenas (salvo el puerto en localhost para aplicaciones nativas). PKCE también protege frente a la inyección de código de autorización, en la que un atacante introduce en la sesión de la víctima un código obtenido en otro lugar.

Cómo aplicarlo

• Genera el verifier con una fuente aleatoria criptográficamente segura para cada solicitud de autorización; guárdalo junto con el valor de state en un lugar vinculado al agente de usuario (session storage en una aplicación de navegador, memoria del proceso en una herramienta de línea de comandos).
• Registra redirect URI exactos. Para una aplicación nativa, de línea de comandos o de escritorio, RFC 8252 describe tres formas de recibir la respuesta: un esquema de URI de uso privado, un URI https reclamado (claimed) o la redirección a loopback (http://127.0.0.1:<port>/).
• Verifica state al regresar, canjea el código una sola vez y descarta el verifier.
• Solicita un scope mínimo, mantén los access tokens de corta duración y usa rotación de refresh tokens para que se detecte la reutilización de un refresh token filtrado.
• Usa una biblioteca cliente mantenida; el flujo tiene más casos límite (mix-up, degradación de code_challenge_method) de los que caben en código escrito a mano.

Trampas

Enviar code_challenge pero dejar que el servidor acepte solicitudes de token sin verifier (una degradación que describe el BCP). Reutilizar un mismo verifier en varias solicitudes. Guardar refresh tokens en el localStorage de una página que también ejecuta scripts de terceros. Tratar un access token como prueba de identidad; para eso están los ID tokens de OpenID Connect.

Aplicaciones de página única: es preferible un backend for frontend

Una aplicación de navegador que dispone de un servidor propio no tiene por qué ser un cliente público. RFC 10017 (BCP 212, 'OAuth 2.0 for Browser-Based Applications') describe la arquitectura backend for frontend, en la que un backend pequeño ejecuta el flujo de código de autorización como cliente confidencial (aún con PKCE), guarda los access y refresh tokens en el servidor y entrega al navegador solo una cookie de sesión del mismo sitio (same-site). El BCP lo recomienda con firmeza para aplicaciones empresariales, aplicaciones sensibles y aplicaciones que manejan datos personales, porque, de lo contrario, un script inyectado en la página puede usar o exfiltrar cualquier token que tenga el navegador. Usa el flujo en el navegador descrito arriba solo cuando no haya un backend que guarde los tokens y, en ese caso, mantenlos en memoria en lugar de en el almacenamiento web.