0Pricing
Cyber Security Academy · Lesson

Token Attacks and Hardening

Defending auth flows from abuse.

Token Attacks and Hardening is a free Cyber Security Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

Tokens as Credentials

In modern auth, tokens are credentials. Whoever holds a valid bearer token is treated as the authenticated party until it expires or is revoked.

  • This makes token theft equivalent to credential theft.
  • Hardening focuses on limiting token lifetime, binding tokens to a holder, and enabling fast revocation.

This lesson covers attacks against OAuth/OIDC/SAML tokens and the defensive controls that counter them.

JWT Algorithm Confusion

A classic JWT attack abuses the alg header.

  • alg: none if accepted, lets an attacker forge unsigned tokens.
  • RS256 to HS256 confusion the attacker resigns a token using the public RSA key as an HMAC secret.

Defense: pin the expected algorithm server-side and never let the token dictate which verification path runs.

Vulnerable: verify(token, key)  // alg taken from header
Hardened:   verify(token, key, { algorithms: ["RS256"] })
// reject alg:none, reject HS* when RS* expected

Token Theft via XSS and Logs

The most common token compromise is plain theft of a valid token.

  • XSS reads tokens from localStorage or memory.
  • Tokens in URLs leak via browser history, referrer headers, and server logs.
  • Verbose logging of Authorization headers.

Prefer httpOnly, Secure, SameSite cookies for browser sessions, and scrub tokens from logs and URLs.

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax
// keeps JS (and thus XSS) from reading the token

Replay Attacks

A replay attack reuses a captured valid token to act as the victim.

  • Mitigated by short expirations, one-time nonce (OIDC) and assertion-ID tracking (SAML).
  • TLS prevents passive network capture.
  • Sender-constrained tokens stop reuse even if stolen.
Replay defenses:
  short exp + nonce/jti uniqueness
  TLS everywhere
  sender-constrained tokens (mTLS / DPoP)

Sender-Constrained Tokens

Bearer tokens are usable by anyone who holds them. Sender-constrained tokens bind a token to a specific client key.

  • mTLS-bound tokens (RFC 8705) tie the token to the client TLS certificate.
  • DPoP (RFC 9449) binds the token to a proof-of-possession key the client signs per request.

A stolen token is then useless without the matching private key.

DPoP: each request carries a signed proof JWT
  DPoP: <proof-jwt signed with client private key>
  Authorization: DPoP <access_token>

Short Lifetimes and Refresh Rotation

Limit the window of usefulness for any stolen token.

  • Keep access tokens short-lived (minutes).
  • Use refresh token rotation: each refresh issues a new refresh token and invalidates the old one.
  • Detect reuse of a rotated refresh token as a theft signal and revoke the whole chain.
On /token refresh:
  issue new RT, invalidate old RT
  if old RT presented again -> breach -> revoke family

Token Revocation and Introspection

Self-contained JWTs are valid until expiry, which complicates revocation. Provide mechanisms to cut access fast.

  • Revocation endpoint (RFC 7009) invalidates refresh/access tokens.
  • Introspection (RFC 7662) lets a resource server check a token status in real time.
  • Maintain a deny list by jti for critical revocations.
POST /introspect  token=...
  -> { "active": true, "sub": "...", "scope": "read" }
POST /revoke      token=...

Audience and Scope Enforcement

A valid token is not automatically authorized for your API. Enforce intent.

  • Check aud so a token minted for another service cannot be replayed to yours.
  • Enforce scope per endpoint; do not assume a valid token implies full access.
  • Validate iss to block tokens from untrusted issuers.

This stops cross-service token reuse and confused-deputy abuse.

Mix-Up and Cross-Provider Attacks

When a client supports multiple identity providers, mix-up attacks can trick it into sending a code or token issued by one IdP to a different, attacker-chosen endpoint.

  • The client loses track of which AS a response came from.
  • Defense: bind responses to the issuer using the iss parameter (RFC 9207) and validate state per provider.
/authorize ... &state=<provider-bound>
callback must include &iss=<expected-AS>
client verifies iss matches the AS it started with

Secure Storage and Transport

Where and how tokens live determines exposure.

  • Browser sessions: httpOnly, Secure, SameSite cookies; avoid localStorage.
  • Mobile: OS keychain/keystore, never plaintext files.
  • Servers: secrets manager, encrypted at rest, scoped least privilege.
  • Always TLS in transit; never embed tokens in query strings.

A Token Hardening Checklist

Bring the controls together into an operational baseline.

  • Pin algorithms; reject alg: none and confusion attacks.
  • Validate iss, aud, exp, signature, nonce/state.
  • Short access-token TTL plus refresh rotation with reuse detection.
  • Prefer sender-constrained tokens (DPoP/mTLS) for high-value APIs.
  • Support revocation and introspection.
  • Store securely; keep tokens out of URLs and logs.
Hardening baseline:
  [ ] alg pinned, none rejected
  [ ] iss/aud/exp/sig/nonce validated
  [ ] short TTL + RT rotation + reuse detection
  [ ] DPoP/mTLS for sensitive scopes
  [ ] revoke + introspect available

Quick Check: Neutralizing Stolen Tokens

Choose the control that best limits the damage of token theft itself.

Recap: Token Attacks and Hardening

Key takeaways:

  • Tokens are credentials; theft equals account takeover.
  • Defend JWTs by pinning algorithms and validating iss, aud, exp, signature, nonce.
  • Limit exposure with short lifetimes and refresh rotation with reuse detection.
  • Sender-constrained tokens (DPoP/mTLS) neutralize stolen bearer tokens.
  • Provide revocation and introspection, and keep tokens out of URLs, logs, and localStorage.

Frequently asked questions

Is the “Token Attacks and Hardening” lesson free?

Yes — the full text of “Token Attacks and Hardening” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.

What will I learn in “Token Attacks and Hardening”?

Defending auth flows from abuse. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cyber Security Academy?

No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Token Attacks and Hardening” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cyber Security Academy lesson?

Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. OAuth 2.0 Flows
  2. OpenID Connect (OIDC)
  3. SAML and Federation
  4. Token Attacks and Hardening
← Back to Cyber Security Academy