API design
API authentication and authorization: interview questions and practical design
API authentication establishes who or what is calling, while authorization decides whether that identity may perform this operation on this resource in this context.
Written and reviewed by Sahil Srivastav
What it actually is
API authentication establishes who or what is calling, while authorization decides whether that identity may perform this operation on this resource in this context.
Confusing identity with permission creates insecure APIs that trust a valid token with access it was never granted.
The useful interview answer is precise about the boundary: Validate issuer, audience, signature, expiry, and required scope for tokens; treat API keys as bearer secrets that need storage, rotation, and least privilege.
Why it matters in production
Confusing identity with permission creates insecure APIs that trust a valid token with access it was never granted.
The decision must be enforced server-side at the resource boundary, with tenant, ownership, scope, and operation all considered.
How it works
Credential validation
Validate issuer, audience, signature, expiry, and required scope for tokens; treat API keys as bearer secrets that need storage, rotation, and least privilege.
Policy decision
After authentication, load the resource context and evaluate action, subject, tenant, ownership, and state. A role string alone is rarely enough for object-level access.
Delegation and revocation
Short-lived tokens reduce exposure but do not replace revocation, rotation, audit, and server-side checks for sensitive operations.
Implementing it
Write a policy matrix for read, update, delete, and administrative actions across two tenants.
Test a valid identity with the wrong scope and a correct role on another tenant’s resource.
Redact credentials from logs and rotate a key without downtime.
Interview questions and how to answer them
Authentication versus authorization?
Authentication verifies identity or credential validity. Authorization evaluates whether that identity may perform a specific action on a specific resource under current policy.
Where should authorization run?
At the server boundary closest to the protected resource, with central policy logic reused across transports. UI checks are useful for experience but not security.
JWT or opaque session token?
Choose from trust boundaries, revocation needs, token audience, and operational complexity. JWTs reduce lookup but require careful validation and rotation; opaque tokens centralise revocation.
Answers that lose the round
- Checking authentication but never resource ownership.
- Trusting a user or tenant id from the request body.
- Putting bearer tokens in query strings or logs.
- Assuming a signed JWT is valid without checking issuer and audience.
FAQ
Are API keys authentication?
They identify a caller through a bearer secret, but they usually provide coarse application-level identity. They still need authorization, rotation, and scope controls.
Should roles be embedded in JWTs?
They can be, but long-lived claims become stale. Sensitive or rapidly changing permissions often need a current server-side policy check.
How do I test authorization?
Use a matrix of identities, tenants, resources, actions, and states. Assert both denial and absence of leaked details.