Partie 4 — Authentification

⏱️ TL;DR — L’authentification répond à « qui es-tu ? ». C’est l’une des zones les plus attaquées (le Top 10 OWASP en fait une catégorie à part) et l’une des plus faciles à rater. Cette partie couvre : le choix sessions vs tokens (et pourquoi la session serveur reste souvent le défaut le plus sûr), la mécanique d’une connexion robuste (stockage argon2id — rappel Partie 3 —, politique de mot de passe raisonnable, protection contre le bruteforce et le credential stuffing, messages d’erreur qui ne fuient pas), la MFA (TOTP, WebAuthn/passkeys), et OAuth2/OIDC (« se connecter avec Google ») avec la gestion de session (expiration, rotation, invalidation). Objectif : une identité difficile à usurper.

Le problème qu’on résout

L’authentification est le portail de ton appli : s’il cède, tout le reste tombe (les meilleures autorisations du monde ne servent à rien si l’attaquant est déjà connecté sous l’identité d’un autre). Or c’est un terrain miné : mots de passe mal stockés, absence de limitation des tentatives, messages qui révèlent quels comptes existent, sessions qui ne s’invalident jamais, MFA absente, flux OAuth mal implémentés. Chacune de ces erreurs a mené à des compromissions réelles et massives.

Cette partie assemble les briques de la Partie 3 (hachage, aléatoire, signatures) en un système d’authentification solide, et détaille les défenses contre les attaques spécifiques à ce portail.

Ce que tu sauras faire à la fin de cette partie

• Choisir entre session serveur et token en connaissant les compromis (et pourquoi le cookie de session HttpOnly est souvent le défaut).
• Implémenter une connexion solide : hachage argon2id, politique de mot de passe raisonnable (NIST), messages d’erreur génériques.
• Défendre contre bruteforce, credential stuffing et énumération de comptes (rate limiting, verrouillage, réponses uniformes).
• Ajouter une MFA : TOTP (codes à 6 chiffres) et passkeys/WebAuthn (le futur sans mot de passe).
• Comprendre et sécuriser un flux OAuth2/OIDC (« se connecter avec… ») et ses paramètres critiques (state, PKCE).
• Gérer les sessions : expiration, rotation à la connexion, invalidation (déconnexion, changement de mot de passe).

Les chapitres

Une fois l’identité établie de façon fiable, il reste à décider ce que cette identité a le droit de faire : c’est l’autorisation, objet de la Partie 5, où l’on rencontre le risque n°1 des applis web — le contrôle d’accès cassé.

On commence par une décision d’architecture : Sessions vs tokens.