#Authentification et sessionsCopier le lien

Stockez des mots de passe hashés (Argon2 ou bcrypt, salés), choisissez des paramètres de coût adaptés et migrez‑les avec le temps. Limitez les tentatives et journalisez les accès. Côté session, servez des cookies HttpOnly/Secure/SameSite et renouvelez l’identifiant après authentification pour éviter la fixation de session.

Avant de continuer, vous devez savoir manipuler des cookies et des en-têtes HTTP (chapitre HTTP et serveurs). À la fin de ce chapitre, vous saurez choisir entre sessions serveur et tokens, et fermer les trois attaques classiques d’une authentification web : XSS, CSRF et fixation de session.

#La frontière de menace : qui peut toucher quoiCopier le lien

Toute décision d’authentification découle d’une question simple : où s’arrête le territoire que vous contrôlez ? Trois frontières structurent le reste du chapitre.

Frontière 1 : le navigateur. Tout ce qui s’exécute dans la page (votre JavaScript, une dépendance compromise, une extension) peut lire le DOM et le stockage accessible. localStorage et sessionStorage sont dans ce territoire : un token qui y dort est volable par la moindre injection XSS. Un cookie HttpOnly ne l’est pas : le navigateur le stocke et le transmet sans jamais l’exposer au script.

Frontière 2 : le réseau. Entre le navigateur et votre serveur, le trafic traverse des machines que vous ne contrôlez pas. HTTPS protège la confidentialité et l’intégrité en transit ; l’en-tête Secure garantit que le cookie ne part jamais en clair. Un token dans l’URL (?token=…) traverse la frontière par défaut : il finit dans les logs serveur, l’historique, le Referer.

Frontière 3 : l’origine. Le navigateur applique la même politique d’origine (same-origin policy) : un script de evil.example ne peut pas lire les réponses de api.example.com. Mais il peut déclencher des requêtes avec vos cookies joints. C’est exactement l’espace que le CSRF exploite, et que SameSite + un jeton applicatif ferment.

De ces frontières découlent les choix de stockage :

Les JWT permettent un mode stateless pratique mais exigent de penser la révocation. Une rotation de refresh tokens avec liste de révocation évite de confondre simplicité et sécurité. Les cookies en front doivent être protégés contre XSS/CSRF ; les tokens en stockage Web ne le sont pas. Préférez des sessions côté serveur pour les applications sensibles et gardez les durées de vie raisonnables.

Mini‑exercice : écrivez un flux « login » qui bloque après 5 tentatives ratées pendant 15 minutes, renouvelle l’identifiant de session à la connexion, et invalide les sessions actives lors d’un changement de mot de passe.

#Flows : login sécurisé et OAuth2/OIDCCopier le lien

#Diagrammes : deux modèles d’authCopier le lien

#Bonnes pratiques clésCopier le lien

#Rotation de refresh tokens (stateless)Copier le lien

#Exemples de code pratiquesCopier le lien

#Renouvellement d’ID de session (Express/Node)Copier le lien

1import session from 'express-session'2import type { Request, Response } from 'express'3import argon2 from 'argon2'4import RedisStore from 'connect-redis'5import { redis } from './redis'6 7export async function login(req: Request, res: Response) {8  const { email, password } = req.body9  const user = await usersRepo.findByEmail(email)10  if (!user) return res.status(401).end()11  const ok = await argon2.verify(user.passwordHash, password)12  if (!ok) return res.status(401).end()13 14  // Anti-fixation: régénérer l'ID de session après auth

#Validation JWT robuste côté API (JOSE)Copier le lien

1import { jwtVerify, createRemoteJWKSet } from 'jose'2 3const issuer = 'https://auth.example.com'4const audience = 'my-api'5const JWKS = createRemoteJWKSet(new URL(`${issuer}/.well-known/jwks.json`))6 7export async function authenticateBearer(token: string) {8  const { payload, protectedHeader } = await jwtVerify(token, JWKS, {9    algorithms: ['RS256'],10    issuer,11    audience,12    maxTokenAge: '10m', // limite l'âge effectif du token13  })14 

#CSRF : double-submit cookie + en-tête personnaliséeCopier le lien

1import crypto from 'node:crypto'2import cookieParser from 'cookie-parser'3app.use(cookieParser())4 5// Émettre un cookie CSRF non HttpOnly + renvoyer la valeur (optionnel)6app.get('/csrf', (req, res) => {7  const token = crypto.randomUUID()8  res.cookie('csrf', token, {9    httpOnly: false, sameSite: 'lax', secure: process.env.NODE_ENV === 'production', path: '/'10  })11  res.json({ token })12})13 14// Vérification sur endpoints mutateurs

Le double-submit fonctionne parce que l’attaquant cross-site peut forcer l’envoi du cookie (le navigateur le joint), mais ne peut pas lire sa valeur pour la recopier dans l’en-tête x-csrf-token. La politique d’origine ferme la lecture ; le jeton ferme l’écriture.

#Quiz éclairCopier le lien

#Checklist déploiement authCopier le lien

#Erreurs fréquentes à éviterCopier le lien

#Mot de passe oublié (flow minimal)Copier le lien