Débogueur OAuth

Proof Key for Code Exchange (PKCE, RFC 7636) a été conçu à l'origine pour les applications mobiles et natives qui ne peuvent pas stocker un client secret de manière sécurisée. Il fonctionne en faisant générer par le client un code_verifier aléatoire, en en dérivant un code_challenge (SHA-256 + base64url), et en envoyant le challenge avec la requête d'autorisation. Lors de l'échange du code d'autorisation contre des jetons, le client envoie le code_verifier d'origine. Le serveur d'autorisation vérifie qu'il correspond au challenge précédent — prouvant que la requête de jeton provient du même client qui a démarré le flux.

Même pour les clients confidentiels (applications côté serveur avec un client secret), PKCE est désormais recommandé par OAuth 2.1 comme défense contre les attaques d'interception de code d'autorisation.

Le flux implicite (response_type=token) a été conçu comme raccourci pour les applications monopages, retournant le jeton d'accès directement dans le fragment d'URL. Cela crée de sérieux problèmes : les jetons dans les URL apparaissent dans l'historique du navigateur, les logs serveur et les en-têtes referrer, et le flux est vulnérable aux attaques par injection de jeton. OAuth 2.0 Security Best Current Practice (RFC 9700) et OAuth 2.1 suppriment explicitement le flux implicite au profit de Authorization Code + PKCE, que les SPA peuvent utiliser en toute sécurité sans client secret.

• PKCE requis pour tous les flux Authorization Code, y compris les clients confidentiels.
• Flux implicite supprimé — utilisez Authorization Code + PKCE à la place.
• Resource Owner Password Credentials (ROPC) supprimé — le grant type password est déprécié.
• Rotation des refresh tokens requise pour les clients publics — un nouveau refresh token doit être émis à chaque utilisation.
• Correspondance exacte de l'URI de redirection requise — pas de correspondance par motif ni de wildcards.

1. Générer la paire PKCE : Créez un code_verifier aléatoire et calculez code_challenge = BASE64URL(SHA256(code_verifier)).
2. Rediriger vers l'endpoint d'autorisation : Incluez response_type=code, client_id, redirect_uri, scope, state, code_challenge, et code_challenge_method=S256.
3. L'utilisateur s'authentifie auprès du serveur d'autorisation et accorde son consentement.
4. Recevez le code d'autorisation à votre redirect_uri accompagné du state renvoyé — vérifiez que state correspond à celui envoyé.
5. Échangez le code contre des jetons : POST vers l'endpoint de jeton avec grant_type=authorization_code, code, redirect_uri, client_id, et code_verifier.
6. Recevez le jeton d'accès (et optionnellement id_token et refresh_token) et utilisez-les pour appeler des API.