Comparison questionEasy~5 minAPI Security & Auth Essentials / 1 of 20

Interview question

In an API, what is the difference between authentication and authorization?

Separate authentication and authorization in an API

Explains identity versus permission checks in API request handling and why both boundaries need server-side enforcement.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Authentication proves who is calling the API, such as a user identified by a validated token. Authorization decides whether that authenticated caller can perform a specific action on a specific resource. A valid token is not enough by itself. The API still needs permission and ownership checks before returning or changing data.

Full answer below

Practice focus

Identity, claims, roles, permissions, resource checks, 401 versus 403 behavior, and server-side enforcement.

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
Authentication establishes who the caller is; authorization decides whether that caller may perform a particular action on a particular resource. Keeping those boundaries separate prevents a valid identity from becoming blanket access.
Authentication proves who is calling the API, such as a user identified by a validated token. Authorization decides whether that authenticated caller can perform a specific action on a specific resource. A valid token is not enough by itself. The API still needs permission and ownership checks before returning or changing data.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would map this to HTTP behavior. If the caller is not authenticated or the token is missing or invalid, the API usually returns 401. If the caller is authenticated but lacks the permission or resource access, the API usually returns 403. The authorization check should happen on the server even if the UI hides buttons, because clients can call endpoints directly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep the distinction visible in code, logs, tests, and support tooling. Authentication middleware validates tokens and builds the principal, while policies or handlers enforce capabilities, tenant membership, and resource ownership. I would log denied decisions with safe context and correlation ids, but not leak whether private resources exist to unauthorized callers. That makes security behavior diagnosable without turning errors into information leaks.

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

Treating a logged-in user as allowed to access every resource.
Relying on the frontend to enforce authorization.
Returning inconsistent 401 and 403 responses.
Putting business authorization rules only in controller comments or UI code.

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

Details

Cannot explain identity versus permission.
No resource ownership check.
No server-side policy boundary.
Leaks private resource existence through error messages.

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.

When would you return 401 versus 403?
Where should resource ownership be checked?
Why is hiding a button not enough authorization?

Continue the section

Next in API Security & Auth Essentials: Password Login

Step 2 of 20

Design a secure password login flow

Opening drill

Comparison questionEasy~5 minAPI Security & Auth Essentials / 1 of 20

Interview question

In an API, what is the difference between authentication and authorization?

Separate authentication and authorization in an API

Explains identity versus permission checks in API request handling and why both boundaries need server-side enforcement.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

Identity, claims, roles, permissions, resource checks, 401 versus 403 behavior, and server-side enforcement.

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
Authentication establishes who the caller is; authorization decides whether that caller may perform a particular action on a particular resource. Keeping those boundaries separate prevents a valid identity from becoming blanket access.
Authentication proves who is calling the API, such as a user identified by a validated token. Authorization decides whether that authenticated caller can perform a specific action on a specific resource. A valid token is not enough by itself. The API still needs permission and ownership checks before returning or changing data.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would map this to HTTP behavior. If the caller is not authenticated or the token is missing or invalid, the API usually returns 401. If the caller is authenticated but lacks the permission or resource access, the API usually returns 403. The authorization check should happen on the server even if the UI hides buttons, because clients can call endpoints directly.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would keep the distinction visible in code, logs, tests, and support tooling. Authentication middleware validates tokens and builds the principal, while policies or handlers enforce capabilities, tenant membership, and resource ownership. I would log denied decisions with safe context and correlation ids, but not leak whether private resources exist to unauthorized callers. That makes security behavior diagnosable without turning errors into information leaks.

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

Treating a logged-in user as allowed to access every resource.
Relying on the frontend to enforce authorization.
Returning inconsistent 401 and 403 responses.
Putting business authorization rules only in controller comments or UI code.

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

Details

Cannot explain identity versus permission.
No resource ownership check.
No server-side policy boundary.
Leaks private resource existence through error messages.

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.

In an API, what is the difference between authentication and authorization?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

In an API, what is the difference between authentication and authorization?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section