API Security: Authentication, Authorization, Rate Limiting

Authentication vs authorization, 401 vs 403, API keys vs JWTs, role-based access with ownership checks, and rate limits that return 429 Too Many Requests.

API security: common questions

When should I use an API key instead of a JWT?

Use API keys for programs, such as a partner company’s server: long-lived secrets looked up in your database. Use JWTs for logged-in users: short-lived signed tokens carrying the user ID and role.

Is checking the user role enough for authorization?

No. Also check ownership: a customer may cancel bookings, but only their own. Without that check, changing the ID in the URL lets one user act on another’s data.

Related chapters

Keep learning

Overview

Not logged in no token customer, owns booking 9 venue_manager of event 123 See event 123 GET /events/123 Cancel booking 9 DELETE /bookings/9 Change prices for event 123 PATCH /events/123/tickets Ban a user POST /users/77/ban Event pages are public on purpose, so no login is needed. No token, so the server doesn’t know who you are. “Log in first.” The admin role is allowed to do this for any user or event. Priya is logged in and booking 9 belongs to her. Asha has the venue_manager role and event 123 is at her venue. Customers can’t change prices. Only the venue’s manager or an admin can. Only admins can ban users. Lab: who is asking, and are they allowed? Who sends the request What they try to do Send booking request Send 5 quickly (a bot) A minute passes 429 Too Many Requests Header Retry-After: 42 tells the client how many seconds to wait. The booking service never even sees these requests. ) : last === 201 ? ( 201 Created Under the limit, so the request goes through.

API security: who is calling, what may they do, how often

An API on the internet gets called by real users, other companies, buggy apps and bots. Three questions keep it safe: who is this, are they allowed, and are they sending too much?

Two different questions: who are you, and may you?

Security people split the first check into two words that sound alike but mean different things: Authentication (authN) who are you? Proving identity, like showing your ID at the door. Fails with 401 Unauthorized: “I don’t know who you are.” Authorization (authZ) may you do this? Checking permission, like whether your ticket lets you into the VIP area. Fails with 403 Forbidden: “I know you, but no.” The classic bug is checking only the first. John logs in, then changes the URL from /bookings/8 (his) to /bookings/9 (Priya’s). If the server only checks that John is logged in, he can cancel Priya’s booking. Try the combinations:

How callers prove who they are: API keys and JWTs

The proof travels in the Authorization header ( REST chapter ) on every request, because the API is stateless ( principle 4 ). The two common kinds of proof suit different callers: API key: for programs JWT: for logged-in users A token the server signs when you log in. It carries your ID and role inside it, so the server checks the signature instead of a database. Expires in minutes or hours. Here is what is inside a JWT. It is not secret (anyone can read it), but nobody can change it without breaking the signature:

Roles: giving permissions to groups, not people

Writing “John may do X, Priya may do Y” for millions of users is impossible. Instead each user gets a role, and permissions are given to roles. This is called RBAC (role-based access control). The JWT above already carries the role. may do search events, book seats, see and cancel their own bookings everything a customer can, plus edit events and prices at their venue everything, including banning users

Rate limiting: how often

A logged-in user with the right role can still hurt you by sending too much: a ticket-scalping bot grabbing seats, or a buggy app stuck in a loop. Rate limiting caps how many requests each caller may send in a time window. Different endpoints get different limits: who / what 1,000 per hour plenty for a human, too few for a scraper each IP address, not logged in 100 per hour stops anonymous bots booking endpoint, per user 10 per minute booking is expensive and scalpers target it The limit is usually checked at the API gateway, the front door before your services, often with a counter in Redis. The rate limiter design shows how that counter works.

The checklist and the interview line

HTTPS only. Every endpoint needs a token unless you chose to make it public. Take the user from the token, never from the request body. Check role and ownership. Rate-limit at the gateway, tighter on expensive endpoints. That completes the API step. In the interview it is five minutes: pick the style, list the endpoints, and mention paging, idempotency and auth in a line each. Then move on to the design. The next chapters go past the five-minute answer: delegated access with OAuth scopes, how real APIs get breached, and running APIs in production. Spotify’s /me endpoints, allow-lists and a playlist “public” flag that is not access control. Access control on Spotify Its 429 with Retry-After and QUOTA_EXCEEDED. Spotify rate limits

More courses

Jobs, linked to lessons — Browse jobs where every requirement links to the chapter that teaches it. See how ready you are, how long the gap takes to close, and which listings look stale.
Match a job post to courses — Paste a job post. Each skill is matched to a track here and put in learning order, foundations first.
React from open source with patterns — Patterns extracted from Material UI, Radix, React Aria, React Hook Form, Redux Toolkit, TanStack, and Next.js — not slides about hooks.
Database in depth — How a query becomes work. Indexes, isolation, locks, and the plans that explain why a page is slow — not an ORM tour.
Build a real API with NestJS — One ticket-booking API, built in order: a plain Node server first, then NestJS modules, validation, a real database, and the features real clients lean on.
Microservices — Microservice patterns one diagram at a time: how to split a monolith, how services talk, and how data stays consistent without distributed transactions.
Kafka — A beginner-to-senior path through event logs, reliable delivery, production operations, and disaster recovery.
AI engineering for software engineers — Eight free reads, in order, for software engineers moving into AI: when to build an agent, how to build one, how to test it, and how the model works underneath.
Frontend system design — How a UI is sliced when it is a product, not a page: ownership of state, cache, routes, and what happens when the network lies.
TypeScript in depth — The type system as a design tool. Inference, narrowing, generics, and the errors that mean the model is wrong — not a catalog of utility types.
CSS in depth — See the box, then the page. Visual chapters from the box model through Flexbox surprises, Grid, selectors, and units, then backgrounds, shapes, and visual effects, each with a playground.
Accessibility — Foundations first (WCAG in plain words, semantic HTML, lists, alt text), then hands-on HTML labs, a full pass of WAI-ARIA 1.3, and a final fix-the-page challenge.
Docker — What an image is, why layers cache, and how containers find each other on a network.
Redis — Fifteen Redis patterns, one picture each: cache, session, lock, counter, rate limiter, queue, and when Redis is the wrong tool.
Kubernetes — Kubernetes from zero to operators: why it exists, Pods, Deployments and Services, then configuration, networking, storage, scheduling, scaling and security.