1 Authentication vs Authorization
Authentication answers "who are you?" — a password, certificate, API key, OAuth client credentials, smart card, or Kerberos ticket. Authorization answers "what are you allowed to do?" — read users, create users, reset passwords, delete devices, view audit logs, manage configuration. A user can authenticate successfully and still get 403 Forbidden because they lack the required authorization — the same distinction Lesson 2 introduced, now from the credential side.
Enterprise APIs use a genuinely wide range of authentication mechanisms, often several at once across one organisation: no authentication (rare, and usually a red flag), HTTP Basic Authentication, API keys, session cookies, bearer tokens, OAuth 2.0, JWTs, client certificates, mutual TLS, HMAC/request signing, Kerberos, NTLM, proprietary tokens, and WS-Security for SOAP APIs (Lesson 5).
2 Basic Authentication & API Keys
Basic Authentication looks like Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= — the value is usually Base64 of username:password. Critically: Base64 is encoding, not encryption. Anyone who obtains the Base64 value can decode it instantly, so Basic Auth must always run over HTTPS. It's still common in older enterprise software, internal systems, appliances, legacy REST APIs, monitoring products, and administrative interfaces.
API keys travel as X-API-Key: 83e71ad9... or Authorization: ApiKey 83e71ad9..., commonly for machine-to-machine integrations. Simple and easy to implement — but often long-lived, frequently copied into configuration files, sometimes accidentally committed to source-code repositories, often overly broad in what they grant, and difficult to rotate safely. Treat an API key exactly like a password, and never put a production API key into course screenshots or documentation.
3 Bearer, Access & Refresh Tokens
A very common mechanism: Authorization: Bearer eyJhbGciOiJSUzI1NiIs.... "Bearer" means exactly what it sounds like — whoever possesses the token can present it, like a temporary access card. If an attacker steals a bearer token, they can use it until it expires or gets rejected some other way, which is exactly why bearer tokens need careful protection (Module 9, Lesson 6's session-hijacking discussion applies directly here).
OAuth commonly issues an access token the client sends to an API:
Client → Authenticate/obtain authorization → Authorization Server
→ Access Token → Client
→ Authorization: Bearer TOKEN → API (validates before processing)Access tokens are deliberately short-lived. A token response might look like:
{
"access_token": "abc123",
"refresh_token": "xyz789",
"expires_in": 3600,
"token_type": "Bearer"
}When the access token (valid here for 3600 seconds, i.e. one hour) expires, a refresh token can obtain a new one without the user re-authenticating: Refresh Token → Authorization Server → New Access Token. Refresh tokens are extremely sensitive credentials — Module 9's Lesson 3 covers exactly why a stolen refresh token is often more dangerous than a stolen access token.
4 OAuth 2.0 — Scopes & Flows
OAuth is an authorization framework letting applications get controlled access to protected resources without ever handing over the user's actual password. Core concepts: Resource Owner, Client, Authorization Server, Resource Server, Access Token, Refresh Token, and Scopes (Module 9, Lesson 3 covers the full picture). As of August 2026, OAuth 2.1 remains an IETF Internet-Draft rather than a published RFC — the current working-group draft is version 15 from March 2026, consolidating modern OAuth security practice, but it should still be described as an emerging specification, not a completed standard.
Scopes define what a client is actually requesting — users.read, users.write, devices.manage, payments.create. A token carrying "scope": "users.read devices.read" attempting DELETE /users/1001 (which needs users.delete) gets 403 Forbidden — a very common IAM troubleshooting scenario, and a good reminder that a valid, unexpired token can still fail for authorization reasons alone.
No human involved: the SIEM authenticates itself with a client ID and secret, gets an access token back, then uses it as a bearer token against the Security API.
Client Credentials flow (machine-to-machine, no human) is exactly what's diagrammed above. A token request typically looks like:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=myclient&client_secret=mysecretAuthorization Code flow is what user-facing applications use instead, involving a browser redirect: User → Application → redirect → Authorization Server → Login + MFA → Authorization Code → Application → Token Endpoint → Access Token. Modern implementations commonly add PKCE, particularly for public clients (Module 9, Lesson 3 covers this exact flow, plus PKCE, in full).
5 JWT: Structure, Claims & Why Decoding ≠ Validating
A JWT (JSON Web Token) has three Base64URL-encoded sections: HEADER.PAYLOAD.SIGNATURE. The header might carry the signing algorithm and key identifier: {"alg": "RS256", "kid": "4c683..."}. The payload carries claims:
{
"iss": "https://login.example.com",
"sub": "user123",
"aud": "https://api.example.com",
"exp": 1782395000,
"iat": 1782391400,
"scope": "users.read devices.read"
}iss = issuer, sub = subject, aud = audience, exp = expiration, iat = issued at, nbf = not before.
🔮 Predict first
You Base64-decode a JWT and the payload looks completely legitimate — correct issuer, correct audience, not expired. Is the token valid?
Reveal the answer
You still don't know. Anyone can Base64-decode a JWT payload — that's an encoding operation, not a security check, and it proves nothing about legitimacy. The receiving API has to actually validate the cryptographic signature, issuer, audience, expiration, not-before time, expected algorithm, and required claims before trusting anything in the payload. "The JWT decoded successfully, so the token is valid" is one of the most common and most dangerous misconceptions in this whole module — Module 9, Lesson 3 makes exactly this point too.
Not every bearer token is a JWT, either — Authorization: Bearer 7a9d1f648c221b094... may simply be a random opaque token, where the API has to ask the authorization server whether it's still valid (token introspection). Bearer token ≠ JWT.
6 Mutual TLS & HMAC-Signed Requests
Normal HTTPS authenticates the server to the client. Mutual TLS (mTLS) authenticates both directions — server presents a certificate, client presents one back. Common in banking, financial services, government, healthcare, B2B APIs, payment infrastructure, and Zero Trust architectures (Module 8, Section 13; Module 9, Lesson 6). Troubleshooting mTLS often means checking for an expired or wrong certificate, a missing private key, an unsupported cipher, an invalid certificate chain, an untrusted CA, a hostname mismatch, revocation, or a certificate not correctly mapped to the right client.
Some APIs (especially cloud APIs) authenticate requests by cryptographically signing parts of them — HTTP method, path, timestamp, headers, body, and a secret key together produce a signature; the server independently recalculates the expected signature and compares. A mismatch means authentication failed, potentially because of the wrong secret, an incorrect timestamp, a modified body, wrong header order, an incorrect path, clock skew, or incorrect canonicalisation. This is considerably harder to troubleshoot than a simple API key precisely because so many small details all have to line up exactly.
7 Session Cookies, Kerberos & NTLM
Not every API uses bearer tokens. Traditional web applications often authenticate a user and return a session cookie (Set-Cookie: SESSIONID=82ab43...), which the browser then sends back on every subsequent request (Cookie: SESSIONID=82ab43...). Legacy administrative applications frequently work exactly this way, so understanding cookies matters even when your focus is APIs.
Internal Windows applications may use Kerberos or older NTLM for Integrated Windows Authentication: Domain User → Internal Web Application → Integrated Windows Authentication → Active Directory. Troubleshooting here can involve SPNs, service accounts, DNS, time synchronisation, Kerberos tickets, delegation, browser configuration, proxy behaviour, and NTLM fallback — linking straight back to Module 9, Lesson 5's Kerberos/NTLM/LDAP content.
Lesson Outcome
You should now be able to distinguish authentication from authorization, explain Basic Auth's Base64-is-not-encryption trap, describe bearer/access/refresh tokens and OAuth's client credentials and authorization code flows, explain JWT structure and why decoding a token never proves it's valid, distinguish opaque tokens from JWTs, and recognise mTLS, HMAC signing, session cookies and Kerberos/NTLM as API authentication mechanisms in their own right. Lesson 4 moves to the tools you'll actually use to test all of this — Postman, curl, jq and PowerShell.