How SSO/OIDC flows are silently abused through the browser

Federated login — Google Sign-In, Microsoft SSO, Okta, Ping, Auth0, etc. — promises stronger authentication, fewer passwords, and cleaner user experience.
But federated identity systems introduce a hidden and powerful attack vector: token replay.

In a token replay attack, an attacker doesn’t bypass authentication — they reuse a valid identity assertion or session token captured in the browser, typically via client-side compromise.

This blog breaks down how federated login token replay actually works, why backend logs show nothing wrong, how attackers abuse it, and how BreachFin detects the early warning signs.

---

1. What Federated Login Actually Delivers

Federated identity provides:

• Reduced password exposure
• Strong MFA
• Centralized login events
• Short-lived OIDC authorization codes
• Signed ID tokens and access tokens

In theory, this makes authentication stronger.

In practice, the browser becomes the weak point.

---

2. Where Token Replay Happens

Federated login depends on users performing these steps in the browser:

1. Redirect to identity provider (IdP)
2. Authenticate (MFA, biometrics, etc.)
3. Receive authorization code
4. Site exchanges code for tokens
5. Browser stores or holds session token
6. API requests use that token

Attackers don’t break the identity provider.
They hijack steps 4–6, inside the user’s browser.

---

3. The Federated Token Replay Attack Flow

Phase 1 — Capture the Token

Token capture occurs through:

• Malicious browser extensions
• Compromised third-party scripts
• AI assistants scraping network requests
• XHR/fetch hooks in injected JS
• DOM manipulation near login flows

The attacker steals:

• OIDC ID token
• Access token
• Refresh token
• Session cookie

---

Phase 2 — Validate or Decode the Token

Tokens are often:

• JWTs signed by a trusted IdP
• Valid for defined scopes
• Accepted by backend without questions

Attackers can decode the token to confirm:

• Issuer
• Expiry
• Audience
• Scopes
• User identity

Everything looks legitimate.

---

Phase 3 — Replay the Token

The attacker sends:

• The stolen token
• From a different device
• Through a different network
• Into the target application

Backend systems accept it because:

• Signature is valid
• Expiry is valid
• Audience matches
• Session is active
• User was MFA-verified earlier

This is the core weakness.

---

Phase 4 — Abuse the Session

Now the attacker can:

• Access protected APIs
• Download data
• Perform account actions
• Change settings
• Access billing or payment portals

All using a valid, legitimate identity.

---

4. Why Traditional Security Controls Fail

Backend sees valid requests

Token is valid. Traffic matches expected patterns.

IdP logs show successful login

Because the login was legitimate — by the real user.

SIEM sees no anomalies

No brute-force. No password guessing. No MFA failures.

WAF sees normal behavior

Traffic is authenticated and syntactically correct.

CSP/SRI do not apply

Client-side compromise happens before headers matter.

Device fingerprinting often fails

Attackers mimic or replay fingerprint data.

Session binding techniques rarely enforced

Most apps prioritize usability over strict binding.

---

5. What Makes Token Replay So Dangerous

• Completely bypasses MFA
• No need for phishing
• No need for exploits
• Works across devices
• Leaves logs looking clean
• Can scale to multiple victims
• Hard to detect after the fact

This is why attackers increasingly target the browser.

---

6. Real-World Replay Scenarios

Scenario 1 — Session cookie replay

Extension captures cookies → attacker uses them → instant account takeover.

Scenario 2 — Refresh token theft

Refresh token gives long-term access, even after session expiry.

Scenario 3 — Access token interception

Malicious script hooks fetch and XHR to read Authorization headers.

Scenario 4 — OAuth implicit flow failures

Legacy implicit flows expose tokens in URL fragments.

Scenario 5 — AI assistant scraping

Generative AI sidebar tools capture responses containing tokens.

---

7. Where Detection Was Possible — but Missed

Early signals appear only in the browser, not the backend.

Missed indicators include:

• New, unauthorized event listeners on login forms
• Unexpected JavaScript executing post-login
• DOM mutation near authentication components
• Hidden scripts calling IdP endpoints
• Token values accessed in JS memory
• Calls to remote AI/extension servers
• Fetch/XHR interception attempts

Without runtime visibility, organizations never saw these signals.

---

8. How BreachFin Detects Federated Token Replay Early

BreachFin focuses on what backend systems cannot see.

It detects:

• Token interception attempts
• Fetch/XHR hooking by unknown scripts
• DOM tampering during login redirects
• Unauthorized manipulation of OAuth flows
• Suspicious script origins influencing authentication
• Behavior drift on login pages
• Extension interference patterns

BreachFin’s realtime runtime telemetry shows:

• When a script accesses sensitive tokens
• When authentication flows are altered
• When new network destinations appear
• When replay indicators emerge

This lets teams intervene before replay, not after the damage.

---

Final Takeaway

Federated login is secure.
Federated runtime environments are not.

SSO/OIDC protects:

• Authentication
• Identity verification
• Token issuance

But it cannot protect:

• Token storage in the browser
• Token usage
• Token interception
• Token replay
• Runtime behavior

If your security model ends at “SSO is enabled,”
then your real attack surface — the browser — is completely unprotected.

BreachFin closes this gap by detecting client-side tampering long before attackers can replay federated credentials.

---