Security API trainer

MFA Challenge API Practice

Practice testing second-factor verification, recovery codes, trusted devices, delivery failures, lockout, rate limits, and safe token issuance after MFA succeeds.

Start writing test ideas Try API sandbox

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.

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

Interactive sandbox

Try the API request

Choose MFA method, code state, session state, and device trust, then send a simulated POST /api/auth/mfa/verify request.

Request

Build the MFA request

POST/api/auth/mfa/verify

Request JSON

application/json

{
  "challengeId": "mfa_challenge_123",
  "code": "123456",
  "method": "totp",
  "rememberDevice": false
}

MFA methodCode stateSession stateDevice trustContent-Type

Test case presets

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

Happy path

Validation / code

Session / delivery

Abuse prevention

Response

Fake API result

Send a simulated MFA request to see status, response JSON, QA note, and second-factor risks. No real code is sent.

What would you test?

List valid MFA, invalid/expired/reused codes, too many attempts, backup codes, trusted devices, missing sessions, delivery failures, rate limits, safe errors, token issuance, logs, and accessibility.

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

MFA Challenge endpoint

Verify a second-factor challenge after primary login and issue full authentication only after the MFA step succeeds.

Endpoint

POST/api/auth/mfa/verify

Purpose

Complete MFA verification for a pending login attempt.

Request fields

challengeId: string, required

code: string, required

method: totp, sms, email, backup-code, or push

rememberDevice: boolean

Success response

200 OK

Request body

{
  "challengeId": "mfa_challenge_123",
  "code": "123456",
  "method": "totp",
  "rememberDevice": false
}

Success response body

{
  "accessToken": "new-access-token",
  "tokenType": "Bearer",
  "mfaVerified": true,
  "trustedDeviceToken": null
}

Errors

400 validation error
401 invalid, expired, or missing challenge/session
409 reused code
423 too many failed attempts
429 rate limited
503 delivery provider unavailable

Security notes

codes should be short-lived and single-use
challenge ID must be bound to the correct user and login attempt
trusted-device tokens need secure storage, expiry, and revocation
failed attempts should be observable without logging secrets
no access token should be issued before MFA is verified

Business rules

MFA verification requires a valid pre-MFA challenge session
valid code completes authentication and returns tokens
invalid, expired, reused, and mismatched codes are rejected
too many failed attempts lock or throttle the challenge
backup codes are single-use
trusted device bypass follows policy and expiry rules
SMS/email delivery failures fail safely
rate limiting protects verification and resend flows
no full session is created before MFA success
codes and tokens are never logged or sent to analytics

API interview guide

What this MFA Challenge API practice covers

This scenario trains MFA flow testing for challenge creation, code verification, backup methods, lockouts, resend behavior, and secure token completion.

Key risks covered

- MFA-required login creates a challenge and does not issue full tokens too early.
- Valid code, wrong code, expired code, reused code, missing code, and malformed challenge id.
- Resend cooldown, attempt limits, account lockout, backup codes, and trusted-device behavior.
- Safe generic errors, no code logging, rate limiting, and phishing-resistant recovery rules.
- Push, TOTP, SMS/email delivery failure, auth provider outage, accessibility, and audit logs.

Example interview prompt

How would you test an MFA challenge API that verifies one-time codes and completes login only after successful verification?

Common mistakes

- Only testing a valid MFA code.
- Missing expired, reused, wrong, resend, and lockout behavior.
- Not checking token timing, code leakage, fallback methods, or provider failures.