auth

Overview

Because APIs are consumed by programs rather than people clicking through login pages, they authenticate requests differently from traditional web sessions. Most API requests carry a credential — a token or key — that proves who is calling. This lesson covers how API authentication works, the difference between authentication and authorization, and the classes of flaws that make broken authentication one of the most serious API risks.

Learning objectives

• Distinguish authentication (who you are) from authorization (what you may do).
• Describe common API authentication mechanisms: API keys, bearer tokens, and JWTs.
• Explain where authentication tokens are transmitted and why transport security matters.
• Recognize common broken-authentication patterns and their defenses.

Core concept

Authentication answers "who is making this request?" Authorization answers "is this identity allowed to do this?" They are distinct steps: a request can be correctly authenticated (we know who you are) yet still need an authorization check before it proceeds (the next lessons on object IDs cover authorization failures specifically).

APIs are typically stateless: instead of a server-side session tied to a cookie, each request independently carries a credential. Common mechanisms:

• API key — a long, secret string identifying a client or application, usually sent in a header.
• Bearer token — a token sent in the Authorization: Bearer <token> header; whoever holds ("bears") it is treated as authenticated, so it must be protected.
• JWT (JSON Web Token) — a signed, self-contained token carrying claims (such as the user id and roles). The server verifies the signature to trust the claims without a database lookup.

How it works

A typical flow: the client authenticates once (for example, by exchanging username and password at a login endpoint) and receives a token. It then attaches that token to each subsequent request:

GET /api/v1/notes
Authorization: Bearer eyJhbGciOi...   (a signed token)

The server validates the token on every request — checking its signature, expiry, and issuer for a JWT — and, if valid, treats the request as coming from that identity. Because the token is the proof of identity:

• It must travel over HTTPS so it cannot be intercepted.
• It should expire and be revocable, limiting the damage if leaked.
• Its signature must be verified correctly — a server that fails to verify signatures, or accepts a token claiming "no signature," can be tricked into trusting forged identities.

Practical example

In an isolated lab, you log into a practice API and receive a bearer token, which you use to read your own notes — normal authenticated access. Testing responsibly, you examine how the server validates the token. You find that it decodes the JWT to read the user id from its claims but does not verify the signature. Conceptually, that means the server trusts whatever the token says without confirming the token is genuine — so a modified token could impersonate another identity. You do not attack any real account; you document the weakness and its fix: always verify the token's signature (and expiry) server-side before trusting any claim inside it. This illustrates why "we read the user id from the token" is not the same as "we authenticated the user."

Cybersecurity relevance

Broken authentication is consistently ranked among the top API risks because a flaw here undermines everything else — if identity can be forged or stolen, per-object authorization checks operate on the wrong identity. Real defenses include: transmitting tokens only over TLS, verifying signatures and expiry on every request, using short-lived tokens with refresh and revocation, rate-limiting and monitoring authentication endpoints to slow credential-stuffing and brute-force attempts, storing password hashes with a strong algorithm, and never placing secrets or tokens in URLs (where they leak into logs and history). Authorized testing focuses on whether tokens are validated correctly, whether they expire, and whether authentication endpoints resist automated guessing.

Common mistakes

• Confusing authentication with authorization — verifying identity but skipping the "are you allowed?" check.
• Trusting token claims without verifying the signature/expiry, enabling forged or replayed tokens.
• Sending tokens or API keys in URLs, where they end up in server logs, proxies, and browser history.
• Long-lived, non-revocable tokens that remain valid indefinitely if leaked.
• No rate limiting on login/token endpoints, allowing credential stuffing and brute force.

Key takeaways

• Authentication proves identity; authorization decides what that identity may do — both are required.
• APIs are usually stateless and authenticate each request with a credential: API key, bearer token, or signed JWT.
• The token is the proof of identity, so it must travel over HTTPS, expire, be revocable, and have its signature verified server-side on every request.
• Broken authentication is a top API risk; defenses combine TLS, correct token validation, short lifetimes, rate limiting, and keeping credentials out of URLs.

Check your understanding

• Why is verifying a JWT's signature essential, and what can go wrong if the server only reads the claims without verifying it?
• What is the difference between authentication and authorization, and why does a flaw in authentication affect every later authorization check?