Securing a REST API means answering three questions on every request: who are you (authentication), what are you allowed to do (authorization), and is the channel private (transport). Because REST is stateless, credentials must travel with each request rather than living in a server session.
Everything below assumes . Without it, tokens and API keys travel in plaintext and can be sniffed. This is non-negotiable — a bearer token over HTTP is a leaked token.
API keys — a static secret in a header. Simple; good for server-to-server and identifying an application, not a user. Weak on their own (no expiry, no scope) unless paired with more.
GET /data HTTP/1.1
Authorization: Bearer sk_live_a1b2c3...
OAuth 2.0 — the standard for delegated access ("let App X read my data without my password"). The app obtains an access token via a flow (e.g. Authorization Code) and sends it as a bearer token. This is how "Sign in with Google" and third-party integrations work.
JWT (JSON Web Token) — a common format for tokens: a signed, self-contained token carrying claims (user id, roles, expiry). The server verifies the signature — no database lookup needed, which fits stateless REST.
header.payload.signature (base64url)
payload: { "sub": "42", "scope": "orders:read", "exp": 1737800000 }
Authentication proves identity; authorization decides access. Tokens carry scopes (orders:read, orders:write) or roles; the server checks them per endpoint and returns 403 Forbidden when they're insufficient (vs 401 for missing/invalid auth).
No/invalid token → 401 Unauthorized
Valid token, no scope → 403 Forbidden
✓ Short-lived access tokens + refresh tokens (limit blast radius if leaked)
✓ Rate limiting (429) to blunt brute-force and abuse
✓ Validate/sanitize all input; never trust the client
✓ Principle of least privilege on scopes
Security is where a small mistake becomes a breach, so interviewers use this to see whether you reason about it structurally rather than reciting buzzwords. The signal they look for is that you separate the three layers — transport (HTTPS, always), authentication (proving identity, statelessly, via bearer tokens/JWT/OAuth), and authorization (scopes and least privilege) — and that you don't conflate them, e.g. correctly using 401 for "not authenticated" versus 403 for "authenticated but not permitted." Strong answers show awareness of the practical trade-offs: JWTs are convenient and stateless but hard to revoke before they expire (hence short lifetimes plus refresh tokens), API keys identify apps not users, and OAuth exists specifically so users don't hand their password to third parties. Tying it to REST's statelessness — credentials on every request, no server session — shows you understand why API security looks the way it does.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate