Depurador OAuth

Proof Key for Code Exchange (PKCE, RFC 7636) se diseñó originalmente para apps móviles y nativas que no pueden almacenar de forma segura un secreto de cliente. Funciona haciendo que el cliente genere un code_verifier aleatorio, derive de él un code_challenge (SHA-256 + base64url) y envíe el challenge junto con la solicitud de autorización. Al intercambiar el código de autorización por tokens, el cliente envía el code_verifier original. El servidor de autorización verifica que coincide con el challenge anterior, demostrando que la solicitud de token proviene del mismo cliente que inició el flujo.

Incluso para clientes confidenciales (apps del lado del servidor con un secreto de cliente), OAuth 2.1 ahora recomienda PKCE como defensa contra los ataques de interceptación del código de autorización.

El flujo implícito (response_type=token) se diseñó como un atajo para aplicaciones de una sola página, devolviendo el token de acceso directamente en el fragmento de la URL. Esto crea problemas graves: los tokens en las URL aparecen en el historial del navegador, los logs del servidor y los encabezados referrer, y el flujo es vulnerable a ataques de inyección de tokens. OAuth 2.0 Security Best Current Practice (RFC 9700) y OAuth 2.1 eliminan explícitamente el flujo implícito en favor de Authorization Code + PKCE, que las SPA pueden usar de forma segura sin un secreto de cliente.

• PKCE obligatorio para todos los flujos de Authorization Code, incluidos los clientes confidenciales.
• Flujo implícito eliminado: usa Authorization Code + PKCE en su lugar.
• Resource Owner Password Credentials (ROPC) eliminado: el tipo de concesión password está obsoleto.
• Rotación de refresh token obligatoria para clientes públicos: se debe emitir un nuevo refresh token en cada uso.
• Coincidencia exacta de redirect URI obligatoria: sin coincidencia de patrones ni comodines.

1. Genera el par PKCE: crea un code_verifier aleatorio y calcula code_challenge = BASE64URL(SHA256(code_verifier)).
2. Redirige al endpoint de autorización: incluye response_type=code, client_id, redirect_uri, scope, state, code_challenge y code_challenge_method=S256.
3. El usuario se autentica en el servidor de autorización y otorga su consentimiento.
4. Recibe el código de autorización en tu redirect_uri junto con el state reflejado; verifica que state coincide con el que enviaste.
5. Intercambia el código por tokens: haz un POST al endpoint de token con grant_type=authorization_code, code, redirect_uri, client_id y code_verifier.
6. Recibe el token de acceso (y opcionalmente id_token y refresh_token) y úsalos para llamar a las API.