🛡️ Module 5 — Sécurité, pièges et OAuth vs authentification
Bonne lecture et bon apprentissage ! Junior TSAFACK – 12/09/2026 ⏱️ Temps de lecture estimé : 8 minutes
Ce dernier module rassemble les pièges — certains réellement reproduits au Module 4 — et la confusion la plus fréquente autour d’OAuth.
🚫 Piège n°1 — Confondre OAuth avec de l’authentification
Section titled “🚫 Piège n°1 — Confondre OAuth avec de l’authentification”C’est LA confusion la plus répandue, déjà annoncée au Module 1. OAuth répond à « cette application a-t-elle le droit de faire X ? » — pas à « qui est cet utilisateur ? ».
Le piège classique : une application reçoit un Access Token valide de Google, et en déduit « l’utilisateur est authentifié, je peux le connecter ». Problème : un Access Token OAuth n’est, par conception, pas forcément destiné à cette application (voir le claim aud du cours JWT) — un token valide pour lire des photos ne prouve pas qu’il a été émis pour vous authentifier sur ce site précis.
✅ La bonne brique pour l’authentification s’appelle OpenID Connect (OIDC) — une fine couche construite au-dessus d’OAuth 2.0, qui ajoute un jeton dédié : l’ID Token, un JWT signé qui contient explicitement l’identité de l’utilisateur et pour quelle application il a été émis (claim aud). Retenez la règle simple :
OAuth 2.0 seul -> "Cette app peut-elle accéder à telle ressource ?" (autorisation)OAuth 2.0 + OpenID Connect -> "+ Qui est cet utilisateur, et pour quelle app ?" (authentification)🚫 Piège n°2 — Oublier state (CSRF sur le flux OAuth)
Section titled “🚫 Piège n°2 — Oublier state (CSRF sur le flux OAuth)”Vu au Module 3 : sans un state aléatoire généré par le Client et vérifié au retour, un attaquant peut piéger une victime pour qu’elle associe le compte de l’attaquant à sa propre session. Cette valeur doit être générée avec un générateur cryptographiquement sûr (secrets.token_urlsafe() en Python, jamais random), et vérifiée strictement — pas juste « présente ».
🚫 Piège n°3 — Un redirect_uri non strictement validé
Section titled “🚫 Piège n°3 — Un redirect_uri non strictement validé”L’Authorization Server doit comparer le redirect_uri reçu à l’étape ③ à une liste blanche exacte, enregistrée à l’avance pour ce Client — jamais une simple vérification de préfixe ou de domaine. Un serveur qui accepte redirect_uri=https://mon-site.com.attaquant.com/callback parce qu’il « contient » mon-site.com permet à un attaquant de rediriger le code d’autorisation vers son propre serveur.
🚫 Piège n°4 — Utiliser Implicit ou Resource Owner Password Credentials
Section titled “🚫 Piège n°4 — Utiliser Implicit ou Resource Owner Password Credentials”Détaillé au Module 2 : le flux Implicit expose l’Access Token dans l’URL, et Resource Owner Password Credentials redonne au Client l’accès au mot de passe — exactement ce qu’OAuth existe pour éviter. Authorization Code + PKCE couvre aujourd’hui tous les cas d’usage, y compris les applications sans backend.
🚫 Piège n°5 — Ne pas limiter la durée de vie ni le scope des tokens
Section titled “🚫 Piège n°5 — Ne pas limiter la durée de vie ni le scope des tokens”Un Access Token devrait :
- Avoir une durée de vie courte (le champ
expires_indu Module 4) — quelques minutes à quelques heures, jamais « indéfiniment ». - Porter un scope minimal (
scope=photos.read, passcope=full_access) — le principe du moindre privilège s’applique aux tokens exactement comme aux permissions système.
✅ Check-list avant un déploiement réel
Section titled “✅ Check-list avant un déploiement réel”| Point de contrôle | Pourquoi |
|---|---|
| Authorization Code + PKCE utilisé, jamais Implicit ni Resource Owner Password Credentials | Ce sont les seuls flux recommandés aujourd’hui pour un utilisateur |
state généré aléatoirement et vérifié strictement au retour |
Empêche l’injection de code d’autorisation (CSRF sur OAuth) |
redirect_uri validé par correspondance exacte avec une liste blanche |
Empêche le détournement du code vers un serveur tiers |
| Le code d’autorisation est à usage unique et de courte durée de vie | Limite la fenêtre d’exploitation d’un code intercepté |
| Les Access Tokens ont une durée de vie courte et un scope minimal | Limite les dégâts d’un token volé |
| OpenID Connect est utilisé si le besoin est de s’authentifier, pas seulement d’autoriser | OAuth seul ne garantit pas l’identité de l’utilisateur pour votre application |
| Tout le flux transite en HTTPS | Un code ou un token interceptés en clair sont directement exploitables |
🎓 Conclusion du cours
Section titled “🎓 Conclusion du cours”Ce cours a suivi le même principe que le cours JWT : ne jamais affirmer une bonne pratique avant d’en avoir observé la raison d’être. Vous avez vu, avec un vrai serveur d’autorisation exécuté en Python :
- Pourquoi OAuth existe (arrêter de partager les mots de passe, Module 1),
- Qui fait quoi, et quels flux utiliser selon le contexte (Module 2),
- Comment le flux le plus courant fonctionne réellement, étape par étape (Module 3),
- Que chaque protection (usage unique du code,
client_secret, PKCE) bloque effectivement l’attaque qu’elle est censée bloquer (Module 4).
OAuth et JWT sont deux briques complémentaires, souvent utilisées ensemble (un Authorization Server délivre fréquemment des Access Tokens au format JWT) mais qui répondent chacune à leur propre question : OAuth structure le dialogue entre les acteurs, JWT est un format possible pour les jetons eux-mêmes. Comprendre les deux, c’est comprendre l’essentiel de l’authentification/autorisation moderne. 🎯