Back to API Practice

Security/Auth trainer

Account Lockout API Practice

Practice failed-attempt thresholds, cooldowns, CAPTCHA or step-up checks, safe errors, unlock recovery, counters, logs, and abuse protection.

How to use this trainer

Choose, send, inspect, write, improve

Safe client-side simulator. No real backend is called and no real data is sent.

  1. 1Choose a preset case
  2. 2Send a simulated request
  3. 3Read the response and QA note
  4. 4Write what you would test
  5. 5Check your coverage

Interactive sandbox

Try the API request

Pick a preset, send a simulated POST /api/auth/login request, inspect the fake response, and turn it into test ideas.

No passwords or user identifiers are sent. This is a client-side simulator.

Request

Build the request

POST/api/auth/login

Request JSON

application/json
{
  "identifier": "alex@example.com",
  "password": "WrongPassword123!"
}

Test case presets

Choose a case, inspect the fake response, then write what you would test.

Credential failures

Lockout policy

Enumeration

Recovery

Abuse prevention

Reliability

Response

Fake API result

Send a simulated request to see status, response JSON, QA note, and what to notice. No real backend is called.

List wrong password attempts, unknown user, threshold, locked account valid password, cooldown, CAPTCHA, rate limits, safe errors, counter persistence, logs, alerts, and outage behavior.

Tip: a stronger answer usually mixes happy path, negative cases, state changes, data, backend, UX, accessibility, and risk.

How to structure your answer

Happy pathNegative casesData rulesSecurity/API risksUX/performance
API ReferenceEndpoint, request fields, responses, and business rulesExpand

API reference

Account Lockout endpoint

Authenticate users while enforcing failed-attempt thresholds, lockout state, cooldowns, and abuse protection.

Endpoint

POST/api/auth/login

Purpose

Authenticate users while enforcing failed-attempt thresholds, lockout state, cooldowns, and abuse protection.

Request fields

  • identifier: email or username, required
  • password: string, required
  • clientContext: optional risk metadata

Success response

200 OK or 423 Locked

Request body

{
  "identifier": "alex@example.com",
  "password": "WrongPassword123!"
}

Example response body

{
  "error": "ACCOUNT_LOCKED",
  "message": "Too many failed attempts.",
  "retryAfterSeconds": 900
}

Errors

  • 400 validation error
  • 401 invalid credentials
  • 423 account locked
  • 429 rate limited
  • 503 auth/counter store unavailable

Security notes

  • Generic errors prevent account enumeration
  • Counters must be atomic
  • Passwords and tokens are never logged
  • Lockout cannot become an easy denial-of-service tool

Business rules

  • Wrong password increments failed attempts
  • Successful login resets counters if required
  • Locked accounts reject even valid passwords
  • Cooldown and unlock flows follow policy
  • Metrics and alerts catch attack spikes