Authentication & Authorization
The problem
A server needs to know who is making a request (authentication) and whether that specific identity is allowed to do the specific thing being requested (authorization) — without both, every API is either wide open or requires trusting the client to self-report, which no adversarial client can be trusted to do.
Why now
REST API design established the shape of requests, but not who's allowed to make which ones. Sets and logic already gave the vocabulary for 'is this true' (is this token valid, does this user have this permission); this topic is where that logic gets applied to every single incoming request, using TLS's encrypted channel as the precondition for safely transmitting credentials at all.
Mental model
Authentication answers 'who are you' — proving identity once, typically producing a token that stands in for repeating that proof on every request. Authorization answers a completely separate question — 'are you allowed to do this' — checked fresh on every request even for an already-authenticated user, which is why a valid login token can still get a 403 on an action a role doesn't permit.
Requires
- REST API DesignBackend Engineering
Authentication and authorization are checks layered onto the resource/method structure REST already defines; you need a well-defined API surface before deciding which requests require which identity or permission.
- Error HandlingProgramming Fundamentals
Rejecting an unauthenticated or unauthorized request cleanly (with the right status code and message) is a direct, disciplined application of the error-handling patterns already covered, applied to a security-sensitive case.
Helps
- TLS & Encryption BasicsNetworking
Transmitting credentials or tokens over plain, unencrypted HTTP would defeat authentication entirely; TLS is the precondition that makes sending them safely possible in the first place.
Used in
- Login flows, session cookies, and JWT-based token authentication
- Role-based access control (RBAC) restricting which users can perform which actions
- OAuth, letting a user grant a third party limited access without sharing a password
- API keys for service-to-service authentication
Projects
- Implement a basic login flow issuing a signed token, then protect a route so it rejects requests without a valid token
- Add a role check on top of authentication, so an authenticated but insufficiently privileged user gets a 403, not a 401
Examples
- A 401 Unauthorized means 'I don't know who you are'; a 403 Forbidden means 'I know who you are, and you're not allowed to do this'
- A JWT token lets a server verify a request's claimed identity without a database lookup on every single request, at the cost of harder revocation
Resources
Mastery checklist
- I can explain the difference between authentication and authorization with a concrete example
- I can explain the difference between a 401 and a 403 response
- I can implement a token-based authentication flow and protect a route with it
- I can explain why credentials must never be sent over unencrypted HTTP