6.3.2. SSO, JIT Provisioning, and Trust Relationships
💡 First Principle: A session token is a temporary credential that represents an authenticated state. If an attacker obtains a valid session token, they inherit the authentication and authorization of the legitimate user — without needing to know their password. Session management is the set of controls that prevent session tokens from being stolen, guessed, or abused.
Session token requirements:
| Requirement | Why | Implementation |
|---|---|---|
| Cryptographically random | Unpredictable; cannot be guessed | 128+ bits of entropy from CSPRNG |
| Sufficient length | Brute force infeasible | 128 bits minimum |
| Bound to user identity | Token not transferable to another user | Server-side session store; token validated against user on each request |
| Transmitted securely | Cannot be intercepted | HTTPS only; Secure cookie flag |
| Not accessible to scripts | XSS cannot steal the token | HttpOnly cookie flag |
| Bounded lifetime | Limits exposure window | Idle timeout + absolute timeout |
| Invalidated on logout | Cannot be reused after logout | Server-side session store deletion |
Session attack types:
Session fixation: Attacker sets a session ID (before authentication) and tricks the user into authenticating with that ID. After authentication, the session is associated with the legitimate user, but the attacker knows the session ID. Defense: generate a new session ID upon successful authentication.
Session hijacking: Attacker steals a valid session token (XSS, network sniffing, predictable token). Uses it to impersonate the user. Defense: HttpOnly + Secure cookie flags; HTTPS; short token lifetime; re-authentication for sensitive operations.
Cross-Site Request Forgery (CSRF): Attacker tricks the user's browser into sending an authenticated request to a site the user is logged into. The request carries the session cookie automatically. Defense: CSRF tokens (anti-forgery tokens) in forms; SameSite cookie attribute; verify Origin/Referer headers.
Cookie security flags:
| Flag | Effect | Required For |
|---|---|---|
| Secure | Cookie sent only over HTTPS | All session cookies |
| HttpOnly | Cookie not accessible to JavaScript | Session tokens (prevents XSS theft) |
| SameSite=Strict | Cookie not sent with cross-site requests | CSRF prevention |
| SameSite=Lax | Cookie sent with top-level navigation but not cross-site subresource requests | Balance of CSRF protection and usability |
Token-based authentication (JWT):
JSON Web Tokens (JWT) are stateless session tokens: they contain claims (user identity, roles, expiration) encoded in a signed (and optionally encrypted) format. The server validates the signature without querying a session store.
JWT structure: Header.Payload.Signature (Base64URL encoded, dot-separated)
JWT security concerns:
- Algorithm confusion: If the server accepts "none" as a signing algorithm, an attacker can forge tokens. Always validate the algorithm in the header against a whitelist.
- Weak secret: If the HMAC secret is short or guessable, the signature can be brute-forced. Use strong secrets.
- No built-in revocation: Unlike server-side sessions, a signed JWT cannot be invalidated until it expires. Use short expiry times and implement token revocation lists for high-security use cases.
⚠️ Exam Trap: "Logout ends the session." This is true for server-side sessions — the server deletes the session record. For JWT-based authentication, logout on the client side doesn't invalidate the token — it only removes it from client storage. The token remains valid until expiry. A properly implemented JWT system uses short expiration (minutes) plus refresh tokens (longer-lived, revocable) to balance usability and security.
Reflection Question: A web application stores session tokens in localStorage (accessible to JavaScript) and transmits them via HTTP (not HTTPS). It uses 32-bit sequential session IDs. Identify all three security vulnerabilities, the specific attack each enables, and the correct implementation for each.
