Authentication Methods & Their Attack Surface

Authentication Methods & Their Attack Surface

The first trap: they are not the same kind of thing

“API keys, Basic auth, JWT, OAuth” is a mixed list — a credential, a transport, a format, and a framework. Sorting them correctly is what the exam tests.

Method	What it actually is	Category
API key	shared secret identifying an application	credential
Basic Auth	base64(user:pass) in a header	credential transport
JWT	token format	token encoding
OAuth 2.0	delegated authorization framework	framework
OIDC	identity layer on top of OAuth	authentication protocol
Session cookie	opaque ID referencing server-side session	credential transport
mTLS	client certificate	credential (machine)
HMAC signing	request signed with shared secret (SigV4-style)	credential (machine)

Two corrections worth memorizing:

1. OAuth ≠ authentication. OAuth 2.0 grants access to resources on a user’s behalf. It says nothing about who the user is. OIDC (OpenID Connect) adds the identity layer (issues an id_token). The four-item list above is missing the actual authentication standard.
2. JWT is a format, not a scheme. You don’t “use JWT” for auth — you carry a JWT in an Authorization: Bearer <token> header, usually issued via OAuth. Same slot as an opaque token. Only the validation matters.

Basic Auth — mechanics

Header (the correct name is Authorization, not Authentication):

Authorization: Basic dXNlcjpwYXNz

dXNlcjpwYXNz = base64 of user:pass. Base64 is encoding, not encryption — reversible in one line.

It is challenge-response, not fire-and-forget:

1. Client → GET /admin            (no credentials)
2. Server → 401 Unauthorized
            WWW-Authenticate: Basic realm="Admin", charset="UTF-8"
3. Client → GET /admin
            Authorization: Basic dXNlcjpwYXNz
4. Server → 200 / 403 / 401

realm is a label for the protection space — effectively a cache key, telling the client which credential set to use and letting the browser cache credentials per realm. It grants nothing. It is not a role. Authorization happens after the credentials are verified.

Deprecated variant (recognize in recon, never use):

https://user:pass@host/admin

Browsers stripped support; servers mostly ignore it.

Footnotes with security impact:

• Scheme token is case-insensitive (Basic/basic). Filters matching only exact-case Basic are bypassable → API8 misconfiguration / filter evasion.
• -u user:pass in curl sends the header preemptively — a client convenience, not the protocol.
• No logout, no expiry, no revocation, no built-in rate limiting.

Summary line:

Basic = Authorization header + base64(user:pass) + TLS required + zero session management

Attack surface per method

Method	Where it breaks
API key	Leaked in frontend JS / mobile binary / git history. No expiry by default. Placed in URL query string → logged by proxies and referrers. No per-user scoping. Often the same key for all users.
Basic Auth	Credential stuffing (password retransmitted every request). Assumed-encrypted base64. Replay. Case-sensitivity filter bypass. No lockout.
JWT	alg: none accepted. Weak HMAC secret → offline brute force. kid header injection (path traversal / SQLi into key lookup). exp not validated. No revocation (stateless by design). aud/iss unchecked → token from another service accepted.
OAuth 2.0	redirect_uri manipulation → authorization code / token theft. CSRF on the authorization code (missing state). Implicit flow leaks tokens in the URL fragment. Token leakage via Referer. Scope creep (requested scope wider than needed).
Session cookie	Fixation (attacker sets the session ID pre-login). Missing HttpOnly / Secure / SameSite. No rotation on privilege change. Predictable IDs.
mTLS	Misissued/over-broad CA trust. Cert not checked for revocation. Private key stored on disk unencrypted.
HMAC signing	Replay (no timestamp/nonce). Signature computed over a canonicalised string that differs between signer and verifier. Secret leakage.

The mental model

Who are you?         → authentication  → Basic, API key, OIDC, session, mTLS
What may you do?     → authorization   → OAuth scopes, JWT claims, RBAC
How is it carried?   → Bearer header / cookie / query param
What form is it?     → JWT / opaque

All of the above lands under OWASP API2 Broken Authentication when it fails.

Sharpest single question to ask of any API

After the user authenticates, is every request re-checked for what this specific identity may touch?

Most APIs get authentication right and authorization wrong. That is why BOLA (API1) outranks broken auth in the OWASP list.

Sources

• RFC 7617 (HTTP Basic Authentication), RFC 6750 (Bearer tokens), RFC 6749 (OAuth 2.0), OpenID Connect Core
• OWASP API Security Top 10 — API2 Broken Authentication
• CAPIE course section 1.3 (Auth & Authorization)