Aller au contenu principal

Authentification et sessions

Progression

#Authentification et sessions

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.

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/OIDC

1/5
1/5
  • Sessions sensibles: cookies HttpOnly/Secure/SameSite + rotation d’ID à la connexion.
  • JWT: aud/iss stricts, exp courts, scopes minimaux, révocation via rotation de RT.
  • Lockout: 5 tentatives/15min, backoff, captcha si nécessaire, alerte sur anomalies.

#Diagrammes: deux modèles d’auth

Client
BFF/API
Store session
1. POST /login (email, pwd)
2. Créer session (id→userId)
3. Set‑Cookie sid; HttpOnly; SameSite
4. GET /me (cookie sid)
SPA
AuthZ Server
API
1. Code + PKCE (authorize)
2. Échange code↔token (code_verifier)
3. GET /me (Bearer AT)
4. 200

#Bonnes pratiques clés

  • Hashage robuste (Argon2/bcrypt) avec paramètres de coût révisés dans le temps (migration progressive).
  • Renouvellement de l’identifiant de session après authentification pour éviter la fixation de session.
  • Cookies de session HttpOnly, Secure, SameSite=Lax/Strict; durée raisonnable; rotation en cas de suspicion.
  • JWT : exp court; validation d’audience (aud) et d’émetteur (iss); scope minimal; révocation via rotation de refresh + liste.
  • Limiter les tentatives (5/15 min), backoff, captchas si nécessaire; journaux structurés et alerte en cas d’activité anormale.

#Rotation de refresh tokens (stateless)

Client
AuthZ
API
1. POST /token (code_verifier)
2. 200 { AT, RT }
3. GET /me (Bearer AT)
4. 200
5. POST /token (refresh_token)
6. 200 { new AT, new RT } (rotate & revoke)
7. GET /protected (Bearer new AT)
8. 200

#Exemples de code pratiques

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

tsts
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)

tsts
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
Stockage côté navigateur

Ne stockez pas des tokens sensibles (AT/RT) dans localStorage ou sessionStorage (XSS). Préférez un cookie HttpOnly + Secure + SameSite pour les RT, et un AT court en mémoire (BFF conseillé).

#CSRF: double-submit cookie + en-tête personnalisée

tsts
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

#Quiz éclair

Où stocker un refresh token côté navigateur pour une appli sensible ?
Où stocker un refresh token côté navigateur pour une appli sensible ?
Quelles validations minimales pour accepter un JWT côté API ?
Quelles validations minimales pour accepter un JWT côté API ?

#Checklist déploiement auth

  • Hashage Argon2/bcrypt avec paramètres de coût revus régulièrement; migration progressive.
  • Rotation d’ID de session à la connexion; cookie HttpOnly/Secure/SameSite configuré.
  • Lockout: 5 tentatives/15 min, backoff; alertes sur anomalies.
  • JWT: iss/aud stricts, exp courts, scope minimal, liste de révocation par jti.
  • Flux OAuth2: PKCE (S256), rotation des refresh tokens, liste de révocation, durées de vie courtes.
  • Anti‑CSRF: SameSite + jeton applicatif sur requêtes mutatrices.
  • Journaux structurés: traceId corrélé, événements de sécurité (login, reset pwd, changement MFA).

#Erreurs fréquentes à éviter

  • Conserver des tokens dans localStorage (XSS) ou les mettre dans des URLs (logs, referer).
  • Accepter n’importe quel alg dans les JWT ou ne pas valider iss/aud.
  • Ne pas régénérer la session après login (fixation de session).
  • Ne pas prévoir de révocation/rotation des refresh tokens.

#Mot de passe oublié (flow minimal)

1/5