Explica paso a paso el flujo de authorization code de OAuth2 con PKCE

#Por qué existe PKCE

El flujo de authorization code de OAuth2 se diseñó originalmente asumiendo un cliente confidencial — una aplicación del lado del servidor que puede guardar un client_secret de forma segura, lejos de los usuarios finales. Las aplicaciones de una sola página (SPA), las apps móviles y las aplicaciones nativas de escritorio no pueden asumir eso: cualquier cosa que se envíe al cliente puede extraerse de él, así que un secreto embebido no ofrece ninguna protección real. Peor aún, en plataformas nativas la redirección de vuelta a la app tras el login suele pasar por un esquema de URI personalizado (myapp://callback) o un universal link, y más de una app en el mismo dispositivo a veces puede registrar el mismo esquema — abriendo una ventana para que una app maliciosa intercepte el código de autorización destinado a la legítima.

PKCE — Proof Key for Code Exchange, RFC 7636, que se pronuncia "pixy" — cierra esa brecha sin necesitar ningún secreto compartido. Ata la petición que inicia el flujo con la petición que lo termina, de modo que incluso si un atacante intercepta el código de autorización en tránsito, no puede canjearlo por un token.

#Las piezas en juego

• code_verifier — una cadena aleatoria de alta entropía que el propio cliente genera, se mantiene solo en memoria o en el almacenamiento de sesión, y nunca se transmite hasta el último paso.
• code_challenge — BASE64URL(SHA256(code_verifier)), enviado por adelantado en la petición de autorización. Como SHA-256 es de un solo sentido, tener el challenge no permite a nadie recuperar el verifier.
• code_challenge_method — S256 en toda implementación moderna; el método plain (enviar el propio verifier como challenge) existe solo por compatibilidad histórica y no ofrece ninguna protección real.

#Paso a paso

1. El cliente genera un code_verifier y deriva code_challenge = BASE64URL(SHA256(code_verifier)).
2. El cliente redirige el navegador del usuario al endpoint /authorize del servidor de autorización, incluyendo client_id, redirect_uri, response_type=code, scope, un valor state aleatorio, code_challenge, y code_challenge_method=S256.
3. El servidor de autorización autentica al propietario del recurso — una pantalla de login, posiblemente MFA — y pide consentimiento para los scopes solicitados.
4. Al aprobar, el servidor de autorización redirige de vuelta a redirect_uri con un code de vida corta y el mismo state original repetido.
5. El cliente verifica que el state devuelto coincida con el que envió en el paso 2 (esta es la defensa CSRF — una preocupación separada de PKCE), y luego hace un POST directo, por canal trasero, al endpoint /token con grant_type=authorization_code, code, redirect_uri, client_id, y — de forma crítica — el code_verifier en crudo.
6. El servidor de autorización recalcula SHA256(code_verifier) y lo compara contra el code_challenge que guardó cuando emitió el código. Si no coinciden, significa que quien canjea el código no es quien inició el flujo, y se rechaza la petición.
7. Si coinciden, el servidor de autorización emite un access_token (y típicamente un refresh_token, más un id_token si se trata de OpenID Connect).
8. El cliente llama al servidor de recursos con Authorization: Bearer <access_token>.
9. El servidor de recursos valida el token — verificando la firma y los claims si es un JWT?, o llamando a un endpoint de introspección si es opaco — y sirve el recurso protegido.

#Por qué la interceptación sigue fallando

🧠 Check your understanding
0/3 · 0/3 answered
1. ¿Qué problema resuelve PKCE que el flujo clásico de authorization code de OAuth2 no resuelve, para clientes públicos como SPAs y apps móviles?
Reemplaza la necesidad de HTTPS entre el cliente y el servidor de autorizaciónPermite que el cliente se salte por completo el paso de login del usuarioCifra el access token mientras viaja por la redEvita que quien intercepta el código de autorización pueda canjearlo por un token, sin exigirle al cliente guardar un secreto
2. En el flujo PKCE, ¿cuándo se envía el code_verifier en sí al servidor de autorización?
Nunca se envía — solo se transmite su hashSolo en la petición final de canje en /token, nunca antesEn cada petición, como un encabezado HTTPEn la redirección inicial a /authorize, junto con el code_challenge
3. ¿Contra qué protege el parámetro state que PKCE no protege?
Interceptación del código de autorización por una app maliciosa en el mismo dispositivoFalsificación de petición entre sitios (CSRF) contra el callback de redirecciónLa expiración del access tokenAtaques de intermediario (man-in-the-middle) contra la propia conexión TLS