Retour aux articles

Authorization Code + PKCE expliqué aux développeurs pressés

Authorization Code + PKCE est devenu le flow recommandé pour les applications web, SPA et mobiles. Comprendre ce schéma en détail est indispensable pour sécuriser vos projets sans complexité inutile.

Publié le 16 avril 2026

Pourquoi abandonner Implicit et Resource Owner Password

Les anciens grants Implicit et Resource Owner Password ont été largement utilisés pour leur simplicité apparente, mais ils exposent les tokens à des risques importants : vol dans l’URL, absence de secret client, mots de passe partagés avec des applications tierces.

Les recommandations récentes convergent vers leur abandon au profit d’un flow unique : Authorization Code avec PKCE, qui offre un bien meilleur niveau de sécurité tout en restant compatible avec les contraintes des clients publics.

Les étapes du flow Authorization Code + PKCE

Dans ce flow, le client génère d’abord un code_verifier et en dérive un code_challenge. Il redirige ensuite l’utilisateur vers le fournisseur d’identité avec le code_challenge, les scopes demandés et les paramètres OIDC/OAuth2 habituels.

Après authentification et consentement, le fournisseur renvoie un code d’autorisation au client. Ce dernier échange alors ce code contre des tokens (Access Token, éventuellement Refresh Token, et ID Token) en présentant le code_verifier. Si un attaquant a intercepté le code d’autorisation mais ne possède pas le code_verifier, il ne peut pas obtenir les tokens.

Rôle de PKCE pour les clients publics

PKCE a été conçu pour les clients incapables de garder un secret (SPAs, mobiles, desktop). En liant la requête initiale à la phase d’échange de code, il empêche un grand nombre d’attaques de redirection et de vol de code.

Combiné à des redirections strictes (pré-enregistrées, sans wildcards abusives) et à l’interdiction des bearer tokens dans les URLs, PKCE constitue l’un des piliers de la sécurisation des flows modernes.

Intégrer OIDC : ID Token, session et identité

En ajoutant OIDC au flow Authorization Code + PKCE, le client reçoit un ID Token contenant des informations sur l’utilisateur (subject, email, claims divers). Ce token permet d’identifier l’utilisateur côté application, tandis que l’Access Token est utilisé pour appeler les APIs.

La gestion de session applicative doit s’appuyer sur ces éléments sans les confondre : l’ID Token n’est pas un ticket d’accès universel, et la durée de la session utilisateur ne doit pas forcément être identique à la durée de vie des tokens.

Stockage et renouvellement des tokens dans les applis web et mobiles

Dans une application web moderne, le pattern recommandé consiste à ne jamais stocker les tokens dans le JavaScript du navigateur. Un backend-for-frontend peut gérer le flow OAuth2/OIDC, stocker les Refresh Tokens dans des cookies HttpOnly Secure SameSite et exposer au frontend une session applicative classique.

Dans les applications mobiles, les tokens doivent être conservés dans les stockages sécurisés natifs, avec une stratégie claire de renouvellement (rotation des Refresh Tokens, gestion des erreurs d’authentification, scénarios de logout et de révocation).

Erreurs fréquentes à éviter

Plusieurs anti-patterns reviennent régulièrement :

  • Utiliser localStorage pour stocker Access et Refresh Tokens dans une SPA.
  • Réutiliser un même Refresh Token pendant des mois sans rotation ni révocation.
  • Accorder des scopes beaucoup trop larges « pour être tranquille ».
  • Utiliser un ID Token comme preuve d’autorisation côté API.

Ces choix simplifient l’implémentation à court terme, mais créent des failles importantes à moyen terme.

Aller plus loin : flows modernes, BFF et microservices

Une fois le flow Authorization Code + PKCE bien compris, il devient plus simple d’aborder des sujets comme le BFF, la segmentation des audiences par API, ou encore l’utilisation de mécanismes avancés (DPoP, mTLS) pour les contextes les plus sensibles.

Pour gagner du temps et éviter les impasses de conception, de nombreuses équipes choisissent de suivre une formation courte et intensive sur OAuth2/OIDC, avec des schémas de séquence, des exemples de code et des checklists de migration vers OAuth 2.1, directement réutilisables dans leurs projets.

Sources

  1. OAuth 2.1 Authorization Framework (Internet-Draft, 2026) — datatracker.ietf.org — 2026-03-??
  2. OAuth 2.1: Modern Authorization Best Practices in 2026 — latestfromtechguy.com — 2026-02-??
  3. OAuth 2.0 Security Best Practices for Developers — maida.kim — 2025-03-??
  4. Recommended authorization flows with OpenID Connect (OIDC) and OAuth 2.x — zitadel.com
  5. OpenID Connect Flows: From Implicit to Authorization Code with PKCE & BFF — dev.to — 2024-??-??
  6. What Is OpenID Connect (OIDC) & What You Need To Know In 2025 — stealthkits.net — 2025-??-??
  7. Refresh Token Security: Best Practices for OAuth Token Protection — obsidiansecurity.com — 2026-02-??
  8. Best Practices for OAuth2 in Microservices — securecodecards.com — 2026-03-??

Découvrir le Spark lié : Formation OAuth2 / OIDC pour développeurs