Bonnes pratiques pour sécuriser OAuth dans les applications web

OAuth 2.0 est devenu le standard pour l’authentification des API, mais sa mise en œuvre sécurisée reste un défi. Face au vol de jetons, aux flux obsolètes et aux vulnérabilités spécifiques aux navigateurs qui menacent quotidiennement les applications web, les développeurs ont besoin de directives claires sur ce qui fonctionne réellement. Cet article couvre les bonnes pratiques essentielles de sécurité OAuth 2.0 dont vous avez besoin en 2025, des exigences de la RFC 9700 aux patterns spécifiques aux SPA.

Pourquoi la sécurité OAuth est plus importante que jamais

OAuth protège les données de vos utilisateurs en éliminant le partage de mots de passe entre applications. Au lieu de donner vos identifiants à des applications tierces (comme remettre les clés de votre maison), OAuth émet des jetons temporaires et à portée limitée—un peu comme donner une clé de voiturier qui ne fait que démarrer la voiture.

Mais voici le problème : les jetons sont des cibles précieuses. Un access token volé accorde un accès immédiat à l’API. De mauvais choix d’implémentation—stocker les jetons dans localStorage, utiliser des flux obsolètes ou omettre PKCE—transforment des vulnérabilités mineures en violations majeures.

Risques de sécurité principaux et comment les éviter

Vol et stockage de jetons

Ce qu’il ne faut pas faire : Stocker les jetons dans localStorage ou sessionStorage. Toute attaque XSS peut lire ces valeurs et les exfiltrer vers des serveurs contrôlés par l’attaquant.

Ce qu’il faut faire : Pour les SPA, conservez les jetons uniquement en mémoire. Pour les applications côté serveur, stockez-les dans des sessions côté serveur chiffrées. Utilisez des access tokens de courte durée (15-30 minutes) pour limiter les dommages en cas de vol.

Flux obsolètes à éviter

L’Implicit Flow est mort. La RFC 9700 et OAuth 2.1 l’interdisent tous deux. Pourquoi ? Parce qu’il envoie les jetons directement dans les fragments d’URL, les exposant à l’historique du navigateur, aux en-têtes referrer et à tout JavaScript présent sur la page.

Le flux Resource Owner Password Credentials doit également être évité—il va à l’encontre de l’objectif même d’OAuth en exigeant que les applications gèrent directement les mots de passe des utilisateurs.

Utilisez toujours : L’Authorization Code Flow avec PKCE pour tous les clients, y compris les SPA et les applications mobiles.

Standards modernes : RFC 9700 et OAuth 2.1

PKCE est désormais obligatoire

PKCE (Proof Key for Code Exchange) empêche les attaques par interception de code d’autorisation. Voici comment cela fonctionne :

// Generate code verifier and challenge
const verifier = generateRandomString(128);
const challenge = base64url(sha256(verifier));

// Include challenge in authorization request
const authUrl = `https://auth.example.com/authorize?` +
  `client_id=app123&` +
  `code_challenge=${challenge}&` +
  `code_challenge_method=S256`;

// Send verifier when exchanging code for token
const tokenResponse = await fetch('/token', {
  method: 'POST',
  body: JSON.stringify({
    code: authorizationCode,
    code_verifier: verifier
  })
});

OAuth 2.1 rend PKCE obligatoire pour tous les flux d’authorization code, pas seulement pour les clients publics.

Liaison de jetons avec mTLS ou DPoP

La liaison de jetons garantit que les jetons volés ne peuvent pas être utilisés par des attaquants. Deux approches principales :

• mTLS (Mutual TLS) : Lie les jetons aux certificats clients
• DPoP (Demonstrating Proof of Possession) : Utilise une preuve cryptographique sans certificats

Les deux empêchent les attaques par rejeu de jetons en liant cryptographiquement les jetons au client légitime.

Rotation des refresh tokens

Ne réutilisez jamais les refresh tokens. Chaque rafraîchissement doit émettre un nouveau refresh token et invalider l’ancien. Cela limite la fenêtre d’exploitation d’un refresh token volé :

// Server-side refresh token handling
async function refreshAccessToken(oldRefreshToken) {
  // Validate and revoke old refresh token
  await revokeToken(oldRefreshToken);
  
  // Issue new token pair
  return {
    access_token: generateAccessToken(),
    refresh_token: generateRefreshToken(), // New refresh token
    expires_in: 1800
  };
}

Sécurité OAuth pour les SPA : considérations particulières

Les applications monopages (SPA) font face à des défis uniques puisque tout le code s’exécute dans le navigateur. Le navigateur est un territoire hostile—partez du principe que toute donnée qui s’y trouve peut être compromise.

Pattern Backend for Frontend (BFF)

L’approche la plus sécurisée garde les jetons complètement hors du navigateur. Un backend proxy léger gère les flux OAuth et maintient les jetons côté serveur, en utilisant des cookies sécurisés, httpOnly, sameSite pour la session SPA.

Pattern Token Handler

Pour les équipes souhaitant les avantages des SPA sans la complexité d’un backend, le pattern Token Handler offre un compromis. Il utilise un proxy spécialisé qui :

• Gère les flux OAuth
• Stocke les jetons de manière sécurisée
• Émet des cookies de session de courte durée au SPA
• Traduit les requêtes authentifiées par cookie en appels API authentifiés par jeton

Si vous devez absolument stocker les jetons dans le navigateur

Lorsque le BFF n’est pas envisageable :

• Stockez les jetons uniquement en mémoire, jamais dans localStorage
• Utilisez des service workers pour isoler l’accès aux jetons
• Implémentez une expiration agressive des jetons (5-15 minutes)
• Ne stockez jamais les refresh tokens dans le navigateur

Liste de vérification pour l’implémentation

✓ Utilisez l’Authorization Code Flow avec PKCE pour tous les clients
✓ Implémentez une correspondance exacte des URI de redirection
✓ Définissez les durées de vie des jetons au minimum viable
✓ Activez la rotation des refresh tokens pour les clients publics
✓ Utilisez le paramètre state pour la protection CSRF
✓ Implémentez la liaison de jetons (mTLS/DPoP) pour les applications à haute sécurité
✓ Pour les SPA : envisagez les patterns BFF ou Token Handler
✓ Surveillez les exigences de conformité OAuth 2.1

Conclusion

Sécuriser OAuth dans les applications web nécessite de comprendre à la fois les forces du protocole et les menaces spécifiques auxquelles votre architecture est confrontée. Commencez par les exigences de la RFC 9700 : PKCE obligatoire, pas d’implicit flow, et gestion appropriée des jetons. Pour les SPA, envisagez sérieusement de garder les jetons complètement hors du navigateur via les patterns BFF ou Token Handler. Ce ne sont pas seulement des bonnes pratiques—c’est le niveau minimum de sécurité OAuth en 2025.

FAQ

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.