Every Scheme, Side by Side
A map of all the commonly used API authentication types and when each one is the right answer.
Here is the whole field on one page. Each row is covered in depth later in the course.
| Scheme | Credential | Best for | Main weakness |
|---|---|---|---|
| HTTP Basic | user:password, base64 | internal tools, quick scripts | sends the password every request |
| HTTP Digest | hashed challenge response | legacy devices | obsolete; weak hashes |
| API key | long random string | server-to-server, identifying an app | static, rarely rotated, no user identity |
| HMAC signing | signature over the request | webhooks, payments, AWS-style APIs | fiddly to implement; clock skew |
| mTLS | client certificate | service-to-service, regulated sectors | certificate lifecycle management |
| Session cookie | opaque session id | first-party browser apps | CSRF; cross-site cookies get blocked |
| Bearer token / JWT | signed token | SPAs, mobile, cross-origin APIs | XSS storage risk; hard to revoke |
| OAuth 2.0 | delegated access token | third-party access to user data | complexity; easy to misconfigure |
| OpenID Connect | ID token (JWT) | "sign in with…" login | often confused with OAuth's access token |
| SAML | signed XML assertion | enterprise SSO | XML; browser-only |
| TOTP / OTP | 6-digit code | a second factor | phishable; never a first factor alone |
| WebAuthn / passkeys | device-held key pair | phishing-resistant login | recovery flows; device binding |
Three questions that pick for you
- Who is calling — a person in a browser, or a machine? Browser pushes you toward cookies or tokens; machine pushes you toward API keys, mTLS, or OAuth client credentials.
- Is the caller first-party or third-party? Your own frontend can hold a session. Someone else's app must never hold your users' passwords — that is what OAuth exists for.
- Do the frontend and the API share a site?
abc.comcallingapi.abc.comcan use cookies comfortably.abc.comcallingdfg.comis cross-site, and that changes everything — the whole cross-origin category of this course is about that case.
Example
# One request, five different ways to prove who you are
# 1. Basic — password on every call
curl https://dfg.com/api/me -u alice:s3cret
# 2. API key — identifies the application, not the human
curl https://dfg.com/api/me -H "X-API-Key: sk_live_9f2c..."
# 3. Session cookie — the browser sends this automatically
curl https://dfg.com/api/me -H "Cookie: sid=8f2b..."
# 4. Bearer token — explicit, attached by your code
curl https://dfg.com/api/me -H "Authorization: Bearer eyJhbGci..."
# 5. mTLS — the credential is the TLS handshake itself
curl https://dfg.com/api/me --cert client.pem --key client-key.pemWhen to use it
- A team building a public SaaS ships OIDC login for humans, API keys for customer server integrations, and OAuth for third-party marketplace apps — three schemes, three audiences.
- An internal admin tool behind a VPN uses Basic auth because the threat model does not justify anything more and the tool has four users.
- A payments provider signs webhook deliveries with HMAC so the receiver can prove the request really came from them and was not replayed.
More examples
Decision shortcut
Everything after this in the course is the detail behind one of these lines.
Your own browser app, same site as the API
→ session cookie (HttpOnly, Secure, SameSite=Lax) + CSRF protection
Your own browser app, different site from the API (abc.com → dfg.com)
→ bearer access token in memory + refresh token, OR move the API to
api.abc.com and keep cookies (see the BFF pattern)
Mobile / desktop app
→ OAuth 2.0 Authorization Code + PKCE, then bearer tokens
Another company's app acting for your users
→ OAuth 2.0 (never share passwords)
One of your servers calling another of your servers
→ mTLS, or OAuth client credentials, or a rotated API key
A webhook you send to a customer
→ HMAC signature over body + timestampLayering, not choosing
Each layer answers a different question. Skipping the last line is how authenticated users end up reading each other's data.
Browser (abc.com)
│ OIDC login at accounts.abc.com ← who is the human
│ access token, 10 min, in memory ← calling the API
▼
API gateway (dfg.com)
│ verifies JWT signature + audience ← authentication
│ checks scopes ← coarse authorization
▼
Internal services
│ mTLS between pods ← service identity
│ row-level ownership checks in SQL ← the check people forget
Discussion