Authentication and authorization

Almost every real API is protected. Authentication is how a client proves who it is; authorization is how the server decides what that client may do. Interviewers ask about both because the most serious API bugs live here: one customer reading another customer's data is worse than any wrong status code. This article covers the common schemes and the tests that find those bugs.

Authentication versus authorization

Authentication answers "who are you?": a password, a key or a token proves identity. Authorization answers "what may you do?": roles and ownership rules decide access. They fail differently. Missing or invalid credentials give 401 Unauthorized; a known caller without permission gets 403 Forbidden, or 404 if the API hides the resource.

Basic authentication

The client joins the user name and password with a colon and sends them base64-encoded:

Authorization: Basic YWRtaW46c2VjcmV0      (base64 of "admin:secret")

Base64 is a way to write data using only plain letters and digits. It is an encoding, not encryption: anyone can decode it. Basic auth is only acceptable over HTTPS, and logs must never print this header. Some clients send the header only after the server answers 401 with a WWW-Authenticate header, which is the server's request for credentials (a "challenge"). Others send it with the first request ("preemptive"). An API that never sends the challenge needs the preemptive style, because the client would otherwise never learn that it must log in.

API keys

An API key is a long random string that identifies the calling application (the program, not a person), usually sent in a header such as X-API-Key. Keys in the query string (?api_key=...) end up in server logs, proxy logs and browser history, so headers are better. Test a missing key, a wrong key, a revoked key, and a key of a lower plan calling a paid endpoint.

Bearer tokens and JWT

After logging in, the client receives a token and sends it on each request:

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiZXhwIjoxNzk0Mzk1MDAwfQ.signature

"Bearer" means whoever holds the token can use it, so tokens are usually short-lived. A common format is the JWT (JSON Web Token, said "jot"): three parts written in base64url (base64 that is safe to use in URLs), separated by dots. The header names the algorithm used for the signature, the payload holds claims (facts about the user) such as the user id, role and expiry time (exp), and the signature is a code that lets the server detect any change to the token. Anyone can decode and read the payload, so it must not hold secrets. The key tests: an expired token, an edited payload (for example the role changed to admin), the signature removed, and a token from another environment. All should give 401.

OAuth 2.0 at the level testers need

OAuth 2.0 is a set of rules for getting access tokens without giving every application the user's password. An authorization server issues the tokens, and the API (the resource server) checks them. The grants, meaning ways to get a token, that you should know:

• Authorization code with PKCE (an extra check that stops a stolen code from being used): the user logs in on the authorization server in a browser, and the app swaps the short code it gets back for tokens. The standard choice for apps used by people.
• Client credentials: a service logs in as itself with a client id (like a user name for the application) and a client secret (its password). The right choice when one program calls another with no person involved, such as a CI job (an automatic test run) calling an API.
• Refresh tokens: a second, longer-lived token used to get a new access token when the old one expires, without logging in again.
• The older implicit and password grants are discouraged: the OAuth 2.0 security best practice (RFC 9700, 2025) says clients should not use the implicit grant and must not use the password grant.

Test scopes, the permissions written into a token, too: a token issued with read-only scope must not be able to write.

Cookies and sessions

Web applications often keep a session on the server. Login answers with a Set-Cookie header, and the client sends the value back in a Cookie header, so an API test must keep and resend the cookie. Check that the cookie has Secure (sent only over HTTPS) and HttpOnly (hidden from JavaScript on the page), that logout really ends the session, and that the session id changes after login.

The authorization tests that matter most

The most common serious API bug is broken object level authorization: user A changes an id in the URL (for example from /orders/101 to /orders/102) and reads or edits user B's data. For every endpoint that takes an id, call it with another user's id and expect 403 or 404 with no data in the body. Then check that a normal user calling admin endpoints gets 403, reading the data back to prove nothing changed. Finally, adding "role": "admin" to a profile update must be ignored or rejected.

How to answer in an interview

Separate the two words first, then describe the scheme your API uses as a flow: "We call the token endpoint once per run with credentials stored as CI secrets (hidden settings of the CI tool), send the token as a Bearer header, and keep separate tests for missing, expired and tampered tokens." End with one authorization test, such as reading another customer's order by id.

Common mistakes

• Calling base64 or a signed JWT "encrypted".
• Testing only the happy path with one admin token.
• Putting keys or tokens in URLs, or printing them in shared reports.
• Checking the 403 but not that the data stayed unchanged.

Recap

Authentication proves identity (401 when it fails); authorization limits actions (403 or 404). Basic auth, API keys and bearer tokens differ in what is sent and who issues it; OAuth 2.0 issues tokens, and client credentials suit CI jobs. The tests that matter most try another user's ids, lower roles and tampered tokens.