production
Authentication & Authorization
Authenticate the caller (who they are) and authorize them (what they can do) before serving any non-public endpoint.
Authentication and authorization are two distinct gates every non-public endpoint must pass a request through. Authentication answers "who is this caller?" by verifying an identity; authorization answers "is this caller allowed to do this?" by checking permissions. Conflating them is a classic mistake — a perfectly authenticated user can still be forbidden from an action — and a secure API enforces both, in that order, before any business logic runs.
Badge at the front desk (authn) plus colored stripes on the badge that say which floors you can access (authz).
Key Concepts
1
For authentication, REST APIs are usually stateless, so the caller proves identity on every request rather than relying on a server session. The dominant mechanism is a bearer token in the Authorization header, most commonly a signed JWT issued by an identity provider, which the API validates by checking the signature, expiry, and issuer without a database lookup; API keys serve simpler service-to-service cases, and OAuth2 provides the framework for delegated access where users grant third-party apps scoped permissions without sharing credentials. For authorization, once identity is established the API checks whether that principal may perform the requested action, via role-based access control (roles grant sets of permissions), attribute- or policy-based rules, or ownership checks (a user may edit only their own resources). These checks should be enforced server-side on every request — never trust the client to hide a button — and layered, with coarse endpoint-level rules plus fine-grained, data-dependent checks.
Authorization
2
The security fundamentals interviewers expect are: always use HTTPS so bearer tokens cannot be sniffed; keep access tokens short-lived and pair them with refresh tokens, since stateless tokens cannot be revoked before expiry; never put secrets in a JWT payload, which is signed but readable; and return 401 for failed authentication versus 403 for failed authorization so clients can tell "log in" from "you can't do that." The overarching rule is to authenticate first, then authorize, and to enforce both at the server on every protected call.
401403