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

Interview question

In a token-based API, what should logout and device revocation actually do?

Handle logout, device revocation, and active sessions

Explains logout semantics for token-based APIs, revoking refresh tokens, device/session records, and short-lived access-token limits.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Logout should revoke the server-side session or refresh token, not only remove a token from the browser. If access tokens are short-lived, they may remain valid briefly, but the user cannot refresh them after logout. Device revocation works similarly: mark that device/session as revoked so future refresh attempts fail.

Full answer below

Practice focus

Logout semantics, refresh-token revocation, active sessions, device metadata, access-token lifetime, and audit context.

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
Removing a token from the UI does not end a server-recognized session. Logout and device revocation must invalidate the refresh credential or session record that could otherwise mint new access tokens.
Logout should revoke the server-side session or refresh token, not only remove a token from the browser. If access tokens are short-lived, they may remain valid briefly, but the user cannot refresh them after logout. Device revocation works similarly: mark that device/session as revoked so future refresh attempts fail.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would store sessions or refresh-token families with user id, device id or label, created time, last used time, expiration, revoked time, and safe request context. A user-facing active session list can let people sign out of a lost device. Password change, account disable, or admin action may revoke all sessions or selected sessions depending on risk. The API should be clear about whether logout is current device only or all devices.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor refresh attempts against revoked sessions, repeated device churn, suspicious locations, and support-driven revocations. I would not store raw refresh tokens; I would store a hash or identifier. Access-token lifetime becomes the maximum window where a logged-out token might still work, unless the system adds token introspection or a deny list for high-risk actions. The design should balance immediate revocation needs with performance and operational complexity.

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

Deleting only frontend state and calling it logout.
No server-side refresh-token revocation.
No distinction between current-device and all-device logout.
Storing raw refresh tokens in the database.

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

Details

Cannot explain why access tokens may remain valid briefly.
No active session model.
No behavior for lost device or password change.
No audit signal for suspicious refresh attempts.

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.

What should happen after password change?
How would you support sign out all devices?
When would you need immediate access-token revocation?

Continue the section

Next in API Security & Auth Essentials: Password Reset

Step 6 of 20

Design a safe password reset flow

Opening drill

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

Interview question

In a token-based API, what should logout and device revocation actually do?

Handle logout, device revocation, and active sessions

Explains logout semantics for token-based APIs, revoking refresh tokens, device/session records, and short-lived access-token limits.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Logout semantics, refresh-token revocation, active sessions, device metadata, access-token lifetime, and audit context.

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
Removing a token from the UI does not end a server-recognized session. Logout and device revocation must invalidate the refresh credential or session record that could otherwise mint new access tokens.
Logout should revoke the server-side session or refresh token, not only remove a token from the browser. If access tokens are short-lived, they may remain valid briefly, but the user cannot refresh them after logout. Device revocation works similarly: mark that device/session as revoked so future refresh attempts fail.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would store sessions or refresh-token families with user id, device id or label, created time, last used time, expiration, revoked time, and safe request context. A user-facing active session list can let people sign out of a lost device. Password change, account disable, or admin action may revoke all sessions or selected sessions depending on risk. The API should be clear about whether logout is current device only or all devices.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would monitor refresh attempts against revoked sessions, repeated device churn, suspicious locations, and support-driven revocations. I would not store raw refresh tokens; I would store a hash or identifier. Access-token lifetime becomes the maximum window where a logged-out token might still work, unless the system adds token introspection or a deny list for high-risk actions. The design should balance immediate revocation needs with performance and operational complexity.

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

Deleting only frontend state and calling it logout.
No server-side refresh-token revocation.
No distinction between current-device and all-device logout.
Storing raw refresh tokens in the database.

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

Details

Cannot explain why access tokens may remain valid briefly.
No active session model.
No behavior for lost device or password change.
No audit signal for suspicious refresh attempts.

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.

What should happen after password change?
How would you support sign out all devices?
When would you need immediate access-token revocation?

Continue the section

Next in API Security & Auth Essentials: Password Reset

Step 6 of 20

Design a safe password reset flow

In a token-based API, what should logout and device revocation actually do?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

In a token-based API, what should logout and device revocation actually do?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section