Test de charge pour les pics de connexion et d'authentification

Le login est l'endroit où la charge fait mal en premier. Un hit sur la homepage est un lookup CDN ; un login est un verify bcrypt, un aller-retour DB, une écriture de session, souvent une danse OAuth. Quand une campagne marketing ou un changement d'équipe à 9h dépose des dizaines de milliers de sign-ins dans la même minute, c'est ce chemin où le p95 s'effondre. Ce template le scripte end-to-end depuis un vrai egress cloud.

Coût bcrypt vs throughput

Un seul verify bcrypt au coût 12 tourne en ~250ms sur un cœur x86 moderne. À 1 000 logins/sec ça fait 250 cœurs-CPU de travail avant même de toucher la base. Coût 10 divise par deux ; coût 13 double. Rampez le trafic password-grant jusqu'à trouver le coude, puis dimensionnez les répliques d'auth contre le facteur de coût que vous livrez réellement — pas celui du fichier de config de 2019. Cible : login p95 sous 500ms avec le vrai coût bcrypt dans la boucle.

Échange de token OAuth2 et rotation de refresh

Les grants authorization-code sont deux aller-retours : /authorize puis /token. Sous concurrence, la rotation de refresh-token est l'endroit où la correctness casse — deux clients qui courent sur le même refresh token, le second qui prend un 401, le SDK qui déconnecte silencieusement l'utilisateur. Tirez des requêtes refresh depuis plusieurs VUs partageant un pool de tokens pour faire surgir cette race. Suivez /token p99 sous 1s et guettez les clusters de 4xx qui n'apparaissent qu'au-dessus de ~500 RPS.

Hot keys du session store

Backez les sessions avec Redis et l'écriture de login se concentre sur quelques clés : compteurs de rate-limit par IP, compteurs de lockout par username, la clé per-user session-list. La contention hot-key épingle le CPU d'un shard pendant que les autres dorment. Tournez contre le cluster, regardez redis-cli --hotkeys à côté du test — session GET/SET p95 doit rester sous 5ms. Si ça grimpe, c'est votre clé de sharding qui est mauvaise, pas votre count de VUs.

Le lockout de compte devient un DoS

Lockout-after-N-failed-attempts, sous charge, est une primitive d'amplification : un attaquant avec une liste d'usernames verrouille chaque compte avec un seul échec chacun. Incluez un scénario contrôlé de credentials échoués pour mesurer comment l'état de lockout se propage à travers votre backend de lock distribué, et confirmez que les utilisateurs légitimes passent toujours pendant que le mauvais trafic est délesté. Rate limits per-IP, per-account et per-tenant se règlent chacun séparément.

Password spray et IPs d'egress partagées

Des VUs étalés sur une poignée d'IPs d'egress ressemblent exactement à du password spray pour votre WAF. Si le test trip le rate-limiter dès le palier 1 de la rampe, vous testez votre WAF, pas votre service d'auth. Étalez les VUs sur 26+ régions cloud pour que le budget per-IP soit réaliste. Les seuils d'injection de captcha appartiennent au script — si les vrais utilisateurs voient le captcha à 5 tentatives échouées, votre script doit le toucher au même point.

Verify JWT et SLO SAML

Après le login, chaque requête vérifie un JWT. RS256 coûte ~10x le CPU de HS256 et apparaît en régime permanent, pas dans le spike. Les endpoints SAML single-logout font queue sous des logouts concurrents initiés par l'IdP et ne sont presque jamais benchmarkés. Couvrez les deux : une phase de warm post-login qui exerce le verify JWT, plus une tempête SLO pour SAML.

Exécution

Importez le scénario, pointez sur staging, rampez de 100 au pic de sign-ins concurrents sur 10 minutes. Utilisez le mode JMeter avec un flow enregistré, ou le mode k6 pour scripter le handshake OAuth directement. Branchez dans la CI pour que chaque deploy du service d'auth tourne le spike avant promotion.