Authentication answers "who are you?" while authorization answers "what are you allowed to do?" In practice, an Authorization header such as Bearer <token> proves identity; the server then decides what that identity may access based on roles, scopes, or claims. Authentication testing checks that an API properly identifies the caller using credentials like tokens, sessions, or API keys; authorization testing checks that an authenticated caller is allowed to access a specific resource or perform an action. API key authentication sends a shared secret in a header or query parameter with each request, but its main weakness is that the key is a single long-lived credential—anyone who obtains it can impersonate the caller. Basic authentication simply base64-encodes a username and password on every request and is trivially decoded, while Digest authentication uses a challenge–response hash so the password never travels on the wire.
More robust schemes include Bearer tokens sent in Authorization headers, where possession of the token is sufficient to authenticate the caller, and OAuth 2.0, an authorization framework in which a client obtains a delegated access token from an authorization server and uses it to call a resource server on behalf of a resource owner. OAuth uses short-lived access tokens for calling the API and long-lived refresh tokens only for obtaining new access tokens without prompting the user. JWTs—a compact, signed token format with three base64url-encoded parts (header, payload, signature)—carry their own claims such as sub (subject, the principal identifier) and exp (expiration in Unix seconds). Because JWTs are self-contained, they should generally be signed so receivers can verify the issuer and that the claims were not altered in transit. Mutual TLS (mTLS) takes a different approach, requiring both client and server to present X.509 certificates during the TLS handshake, proving identity at the transport layer.
Browser-based clients face additional concerns. Cross-Site Request Forgery (CSRF) tricks a victim's browser into sending a request with the victim's cookies attached, so APIs relying on session cookies must defend against it with CSRF tokens, SameSite cookies, or custom headers. Cross-Origin Resource Sharing (CORS) governs how browsers allow cross-origin requests: APIs advertise their policy through Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials, and Access-Control-Max-Age. Notably, Access-Control-Allow-Origin: * is incompatible with credentialed requests—browsers require a specific origin in that case to prevent leaking the user's session to arbitrary sites. API tests should verify both the presence and correctness of these headers because misconfigurations break clients without producing obvious server errors.