PKCE: protección de clientes públicos

Sin PKCE, las aplicaciones móviles son vulnerables a ataques de intercepción del código de autorización. Cuando el servidor de autorización redirige el código de autorización al esquema de URI personalizado registrado por la aplicación (por ejemplo, myapp://callback), cualquier aplicación maliciosa del mismo dispositivo que registre el mismo esquema de URI puede interceptar la redirección y robar el código.

El ataque funciona de la siguiente manera: una aplicación maliciosa registra el mismo esquema de URI personalizado que la aplicación legítima. Cuando el servidor de autorización redirige el código a myapp://callback, el sistema operativo puede mostrar ambas aplicaciones como controladores. Si el usuario selecciona la aplicación maliciosa o el sistema operativo la establece como predeterminada, el atacante recibe el código de autorización y puede intercambiarlo por tokens sin conocer el secreto del cliente.

PKCE (RFC 7636) añade un secreto generado dinámicamente al flujo de código de autorización. Antes de iniciar el flujo, el cliente genera una cadena criptográficamente aleatoria de entre 43 y 128 caracteres denominada verificador de código. Esta cadena es única para cada solicitud de autorización y no se transmite hasta el paso de intercambio del token.

El cliente calcula un desafío de código a partir del verificador: code_challenge = BASE64URL(SHA256(code_verifier)). El uso de SHA256 es el método requerido por RFC 7636 (no se recomienda el método "plain", que envía el verificador directamente). El desafío de código es una transformación unidireccional del verificador, por lo que conocer el desafío no revela el verificador.

La solicitud de autorización incluye dos parámetros adicionales: "code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256". El servidor de autorización almacena el desafío de código asociado al código de autorización emitido. En esta etapa no se transmite al servidor ningún secreto que pudiera ser interceptado.

Durante el intercambio del token (POST al endpoint de tokens), el cliente incluye "code_verifier=ORIGINAL_RANDOM_STRING" junto con el código de autorización. El servidor de autorización calcula BASE64URL(SHA256(code_verifier)) y verifica que coincida con el code_challenge almacenado. Solo el cliente legítimo que generó el verificador puede superar esta comprobación.

Si un atacante intercepta el código de autorización, solo recibe el código y el desafío de código, que es público. Para intercambiar el código por tokens, debe proporcionar el verificador de código. Puesto que el cliente legítimo generó el verificador y este nunca se transmitió hasta el intercambio del token, que se realiza de forma segura, el atacante no puede calcularlo ni obtenerlo.

PKCE también evita los ataques de inyección del código de autorización, en los que un atacante sustituye un código válido por un código robado en la redirección. El desafío asociado al código robado no coincide con el verificador que presentará el cliente de la víctima, por lo que el intercambio de tokens falla. PKCE proporciona una defensa en profundidad contra varios vectores de ataque de forma simultánea.

Aunque RFC 7636 se describió inicialmente como una solución para clientes públicos (aquellos que no tienen secretos de cliente), el OAuth Security BCP y OAuth 2.1 exigen PKCE para todos los clientes, incluidos los clientes confidenciales que tienen secretos de cliente. PKCE proporciona protección independiente de la autenticación del cliente, por lo que resulta beneficioso en todos los casos.

OAuth 2.1 (draft-ietf-oauth-v2-1) consolida las prácticas recomendadas de seguridad del OAuth 2.0 Security BCP en un único documento. Exige PKCE para todos los flujos de código de autorización, desaconseja el flujo implícito y requiere la rotación de los tokens de actualización. PKCE es, en la práctica, el requisito de seguridad básico para cualquier implementación nueva de OAuth 2.0.

Implementar PKCE correctamente requiere: utilizar un generador de números aleatorios criptográficamente seguro para el verificador (al menos 32 bytes aleatorios, codificados después en base64url), almacenar el verificador de forma segura en el cliente (no en la URL ni en los registros), utilizar el método S256 (no plain) y asegurarse de descartar el verificador después del intercambio de tokens. La mayoría de las bibliotecas OAuth modernas gestionan PKCE automáticamente.

En PKCE, ¿qué relación existe entre el verificador de código y el desafío de código?

PKCE (RFC 7636) evita la interceptación del código de autorización vinculando cada código a un verificador de código generado dinámicamente que solo conoce el cliente legítimo. El verificador se somete a un hash para producir el desafío de código (que se envía públicamente). El intercambio de tokens requiere el verificador original. PKCE evita tanto los ataques de interceptación como los de inyección. OAuth 2.1 exige PKCE para todos los flujos de código de autorización.