Load Testing for Login & Authentication Spikes

Login is where load hurts first. A homepage hit is a CDN lookup; a login is a bcrypt verify, a DB round-trip, a session write, often an OAuth dance. When a marketing push or a 9am shift change dumps tens of thousands of sign-ins into the same minute, that path is where p95 collapses. This template scripts it end-to-end from real cloud egress.

bcrypt cost vs throughput

A single bcrypt verify at cost 12 runs ~250ms on a modern x86 core. At 1,000 logins/sec that is 250 CPU-cores of work before you touch the database. Cost 10 halves it; cost 13 doubles it. Ramp password-grant traffic until you find the knee, then size auth replicas against the cost factor you actually ship — not the one in the config file from 2019. Target: login p95 under 500ms with the real bcrypt cost in the loop.

OAuth2 token exchange and refresh rotation

Authorization-code grants are two round-trips: /authorize then /token. Under concurrency, refresh-token rotation is where correctness breaks — two clients racing on the same refresh token, the second one getting a 401, the SDK silently logging the user out. Fire refresh requests from multiple VUs sharing a token pool to surface that race. Track /token p99 under 1s and watch for 4xx clusters that only appear above ~500 RPS.

Session store hot keys

Back sessions with Redis and the login write concentrates on a few keys: rate-limit counters by IP, lockout counters by username, the per-user session-list key. Hot-key contention pins one shard's CPU while the rest sit idle. Run against the cluster, watch redis-cli --hotkeys alongside the test — session GET/SET p95 should stay under 5ms. If it climbs, your sharding key is wrong, not your VU count.

Account lockout becomes a DoS

Lockout-after-N-failed-attempts, under load, is an amplification primitive: an attacker with a username list locks every account with one failed attempt each. Include a controlled failed-credential scenario to measure how lockout state propagates across your distributed lock backend, and confirm legitimate users still get through while bad traffic is shed. Per-IP, per-account, and per-tenant rate limits each tune separately.

Password spray and shared egress IPs

VUs spread across a handful of egress IPs look exactly like password spray to your WAF. If the test trips the rate-limiter on ramp step one, you are testing your WAF, not your auth service. Spread VUs across 26+ cloud regions so the per-IP budget is realistic. Captcha-injection thresholds belong in the script — if real users hit captcha at 5 failed attempts, your script should hit it at the same point.

JWT verify and SAML SLO

After login, every request verifies a JWT. RS256 is ~10x the CPU of HS256 and shows up at steady state, not in the spike. SAML single-logout endpoints queue under concurrent IdP-initiated logouts and are almost never benchmarked. Cover both: a post-login warm phase that exercises JWT verify, plus an SLO storm for SAML.

Run it

Import the scenario, point at staging, ramp from 100 to peak concurrent sign-ins over 10 minutes. Use JMeter mode with a recorded flow, or k6 mode to script the OAuth handshake directly. Wire into CI so every auth-service deploy runs the spike before it promotes.