Concept questionMedium~7 minAPI Security & Auth Essentials / 2 of 20

Interview question

How would you design a secure username and password login flow for an API?

Design a secure password login flow

Explains password verification, hashing, throttling, generic errors, lockout, and safe login telemetry.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would never store plain passwords. The API stores a salted password hash using a password-hashing algorithm designed for credentials. On login, it finds the account, verifies the submitted password against the hash, checks account status, and returns a generic failure message if anything is wrong. If it succeeds, it issues the normal session or token response.

Full answer below

Practice focus

Password hashing, generic failures, rate limiting, lockout, audit signals, token issuance, and safe error responses.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Password login looks simple, but it combines credential storage, abuse control, token issuance, and user-facing error behavior.
I would never store plain passwords. The API stores a salted password hash using a password-hashing algorithm designed for credentials. On login, it finds the account, verifies the submitted password against the hash, checks account status, and returns a generic failure message if anything is wrong. If it succeeds, it issues the normal session or token response.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would protect the endpoint from guessing and enumeration. Failed login responses should not reveal whether the email exists. The API should rate limit by account, IP, device signal, or a combination, and use lockout or step-up checks after repeated failures. Successful login should reset failed counters where appropriate and record enough audit context for support and security investigation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make login resilient without making it noisy. Password verification is intentionally expensive, so the endpoint needs concurrency and abuse limits. Logs should capture login success, failure count, lockout, device or IP context, and correlation id without storing raw passwords or tokens. I would also plan password hash upgrades, breached-password checks where product-appropriate, and alerting for credential-stuffing patterns across many accounts.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Storing passwords with fast hashes or reversible encryption.
Returning user-not-found versus wrong-password details.
No throttling on login attempts.
Logging submitted passwords or issued tokens.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot name password hashing as a separate concern.
No account enumeration protection.
No abuse throttling or lockout behavior.
No audit trail for repeated failures.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid user enumeration?
What should be logged for failed login?
How would you migrate old password hashes?

Continue the section

Next in API Security & Auth Essentials: JWT Validation

Step 3 of 20

Validate JWTs and trust claims carefully

Opening drill

Concept questionMedium~7 minAPI Security & Auth Essentials / 2 of 20

Interview question

How would you design a secure username and password login flow for an API?

Design a secure password login flow

Explains password verification, hashing, throttling, generic errors, lockout, and safe login telemetry.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Password hashing, generic failures, rate limiting, lockout, audit signals, token issuance, and safe error responses.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Password login looks simple, but it combines credential storage, abuse control, token issuance, and user-facing error behavior.
I would never store plain passwords. The API stores a salted password hash using a password-hashing algorithm designed for credentials. On login, it finds the account, verifies the submitted password against the hash, checks account status, and returns a generic failure message if anything is wrong. If it succeeds, it issues the normal session or token response.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would protect the endpoint from guessing and enumeration. Failed login responses should not reveal whether the email exists. The API should rate limit by account, IP, device signal, or a combination, and use lockout or step-up checks after repeated failures. Successful login should reset failed counters where appropriate and record enough audit context for support and security investigation.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make login resilient without making it noisy. Password verification is intentionally expensive, so the endpoint needs concurrency and abuse limits. Logs should capture login success, failure count, lockout, device or IP context, and correlation id without storing raw passwords or tokens. I would also plan password hash upgrades, breached-password checks where product-appropriate, and alerting for credential-stuffing patterns across many accounts.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Storing passwords with fast hashes or reversible encryption.
Returning user-not-found versus wrong-password details.
No throttling on login attempts.
Logging submitted passwords or issued tokens.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot name password hashing as a separate concern.
No account enumeration protection.
No abuse throttling or lockout behavior.
No audit trail for repeated failures.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you avoid user enumeration?
What should be logged for failed login?
How would you migrate old password hashes?

Continue the section

Next in API Security & Auth Essentials: JWT Validation

Step 3 of 20

Validate JWTs and trust claims carefully

How would you design a secure username and password login flow for an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How would you design a secure username and password login flow for an API?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section