API Security Vocabulary: Authentication, Authorization, and Beyond

API security discussions are filled with abbreviations and concepts that are easy to confuse — authentication vs authorisation, OAuth flows, JWT structure. If you are reviewing a security design, writing a threat model, or explaining a vulnerability to a colleague, precise vocabulary prevents costly misunderstandings. This post covers the terms you encounter most often in real API security work.

Identity: Authentication vs Authorisation

Authentication (often abbreviated AuthN) — Verifying who the caller is. Phrase: “The API authenticates callers using API keys — each key is linked to a specific client application.”

Authorisation (often abbreviated AuthZ) — Determining what an authenticated caller is allowed to do. Phrase: “Authentication passed, but authorisation failed — the user doesn’t have the admin scope required to access this endpoint.”

A common confusion: “The API returned 401 Unauthorized” — but 401 actually means unauthenticated (no valid credentials). 403 Forbidden means unauthorised (valid credentials, insufficient permissions). This distinction matters in incident reports and API design reviews.

OAuth 2.0 and PKCE

OAuth 2.0 — An authorisation framework that allows third-party applications to obtain limited access to a resource on behalf of a user. OAuth defines several flows (also called grant types) for different use cases.

OAuth 2.0 flows — The main flows:

• Authorization Code — for server-side web apps; most secure
• Authorization Code + PKCE — for public clients (SPAs, mobile apps) where a client secret can’t be kept confidential
• Client Credentials — for machine-to-machine (M2M) authentication; no user involved
• Device Authorization — for devices with limited input capability (smart TVs, CLI tools)

Phrase: “We use the Client Credentials flow for the data pipeline — it’s a backend service with no user context.”

PKCE (Proof Key for Code Exchange) (pronunciation: “pixie”) — An extension to the Authorization Code flow that protects against interception attacks by using a code verifier and code challenge. Required for public clients. Phrase: “The mobile app uses PKCE — it generates a code verifier locally and sends only the hashed challenge to the authorisation server.”

Tokens and Signing

JWT (JSON Web Token) (pronunciation: “jot”) — A compact, self-contained token format. A JWT has three Base64URL-encoded parts separated by dots: header, payload, and signature. Phrase: “Decode the JWT payload on jwt.io to inspect the claims — but never trust the payload without verifying the signature.”

Claims — The key-value pairs in a JWT payload describing the token’s subject, issuer, expiry, and custom data (e.g. sub, iss, exp, scope). Phrase: “The JWT has a custom claim tenant_id — the API uses it to route requests to the correct database shard.”

HMAC (Hash-based Message Authentication Code) — A symmetric signing algorithm used to sign JWTs (HS256) or validate webhook payloads. Both parties share the same secret key. Phrase: “Webhook payloads are signed with HMAC-SHA256 — verify the signature before processing.”

API key — A simple secret string passed in a request header or query parameter to authenticate an API client. Simpler than OAuth but offers less granularity. Phrase: “Rotate the API key immediately — it was accidentally committed to the public repository.”

mTLS (Mutual TLS) — Both client and server present certificates to authenticate each other. Common in service-to-service communication within a service mesh. Phrase: “mTLS is enforced between internal services — no service can call another without a valid client certificate.”

Common Vulnerabilities and Defences

CORS (Cross-Origin Resource Sharing) — A browser security mechanism that restricts which origins can make cross-origin requests. Misconfigured CORS (e.g. Access-Control-Allow-Origin: * on an authenticated API) is a common vulnerability. Phrase: “The CORS policy only allows requests from our production domain — wildcard origins are never permitted on authenticated endpoints.”

CSRF (Cross-Site Request Forgery) — An attack that tricks a user’s browser into making an authenticated request to your API. Mitigated by CSRF tokens, SameSite cookies, and checking the Origin header.

Injection prevention — Validating and sanitising all API inputs to prevent SQL injection, command injection, and similar attacks. Phrase: “Use parameterised queries — never interpolate user input directly into SQL.”

Rate limiting — Restricting the number of requests per client per time window to prevent abuse and brute-force attacks.

API gateway security — Centralising authentication, authorisation, rate limiting, and input validation at the gateway layer rather than in each service.

OWASP API Security Top 10 — A widely cited list of the most critical API security risks, including Broken Object Level Authorisation (BOLA), Broken Authentication, Excessive Data Exposure, and Mass Assignment. Phrase: “The security review checklist is based on the OWASP API Security Top 10 — BOLA is the most common finding.”

Practice: Read the OWASP API Security Top 10 (owasp.org/www-project-api-security/) and write a one-sentence definition of each risk in your own words. Then compare with a colleague — differences reveal gaps in understanding.