Concept questionMedium~7 min

Interview question

What does an API need to validate before trusting a JWT?

Validate JWTs and trust claims carefully

Explains JWT validation, trusted issuers, audiences, expiration, signing keys, claims, and server-side authorization boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The API should validate the JWT signature, issuer, audience, expiration, and signing key. It should also use the expected token type and algorithm. Only after validation should the API read claims like user id, roles, tenant, or scopes. A token string from the client is just input until those checks pass.

Full answer below

Practice focus

Issuer, audience, signature, expiry, signing keys, token type, claims trust, clock skew, and authorization use.

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
A JWT is untrusted input until its signature and intended use have been validated. Issuer, audience, lifetime, algorithm, key, and token type define whether its claims can participate in an authorization decision.
The API should validate the JWT signature, issuer, audience, expiration, and signing key. It should also use the expected token type and algorithm. Only after validation should the API read claims like user id, roles, tenant, or scopes. A token string from the client is just input until those checks pass.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would be careful about what claims mean. A role or tenant claim may come from the identity provider, but resource ownership can still depend on application data. The API should not accept caller-supplied claims outside the signed token, and it should not trust a token intended for another audience. I would keep token lifetime short enough to reduce risk but long enough for normal user experience.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would handle key rotation, clock skew, token replay risk, and diagnostics. The validation middleware should fail closed when metadata or signing keys cannot be trusted, while still being resilient to normal key rollover. I would log token validation failures by reason category without writing the token itself. Authorization policies should use claims as inputs, not as a replacement for database-backed membership or resource checks when those rules can change.

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

Decoding a JWT without verifying its signature.
Ignoring issuer or audience.
Trusting tenant or role values sent outside the token.
Using long-lived access tokens for convenience.

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

Details

Cannot name the validation checks.
Treats JWT claims as fresh database state.
No signing-key rotation story.
Logs raw bearer tokens.

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.

Why does audience validation matter?
What claims would still need database checks?
How would signing key rotation affect the API?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Try a variant

Answer a similar question in a different context.

Security Boundaries

Opening drill

Concept questionMedium~7 min

Interview question

What does an API need to validate before trusting a JWT?

Validate JWTs and trust claims carefully

Explains JWT validation, trusted issuers, audiences, expiration, signing keys, claims, and server-side authorization boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Issuer, audience, signature, expiry, signing keys, token type, claims trust, clock skew, and authorization use.

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
A JWT is untrusted input until its signature and intended use have been validated. Issuer, audience, lifetime, algorithm, key, and token type define whether its claims can participate in an authorization decision.
The API should validate the JWT signature, issuer, audience, expiration, and signing key. It should also use the expected token type and algorithm. Only after validation should the API read claims like user id, roles, tenant, or scopes. A token string from the client is just input until those checks pass.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would be careful about what claims mean. A role or tenant claim may come from the identity provider, but resource ownership can still depend on application data. The API should not accept caller-supplied claims outside the signed token, and it should not trust a token intended for another audience. I would keep token lifetime short enough to reduce risk but long enough for normal user experience.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would handle key rotation, clock skew, token replay risk, and diagnostics. The validation middleware should fail closed when metadata or signing keys cannot be trusted, while still being resilient to normal key rollover. I would log token validation failures by reason category without writing the token itself. Authorization policies should use claims as inputs, not as a replacement for database-backed membership or resource checks when those rules can change.

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

Decoding a JWT without verifying its signature.
Ignoring issuer or audience.
Trusting tenant or role values sent outside the token.
Using long-lived access tokens for convenience.

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

Details

Cannot name the validation checks.
Treats JWT claims as fresh database state.
No signing-key rotation story.
Logs raw bearer tokens.

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.

Why does audience validation matter?
What claims would still need database checks?
How would signing key rotation affect the API?

Continue practice

Move to the linked follow-up, next path step, prerequisite, or deeper variant.

1 linked

Try a variant

Answer a similar question in a different context.

Security Boundaries

What does an API need to validate before trusting a JWT?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant

What does an API need to validate before trusting a JWT?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Try a variant