Skip to main content
Promotional banner for the pentest readiness checklist
Token Theft Isn't a Breach Anymore, It's the BreachOAuth & OIDC
4 min readFor IAM Architects

Token Theft Isn't a Breach Anymore, It's the Breach

What Happened

CISA and NIST released Interagency Report 8587 in response to a shift in how attackers target identity infrastructure. The report highlights a pattern: tokens and assertions, which prove your identity after authentication, are now primary targets. Traditional defenses assume authentication occurs once and the token remains trustworthy for its lifetime. That assumption is failing.

The report highlights two OpenID Foundation specifications: the Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP). SSF standardizes how identity providers and relying parties exchange security event signals. CAEP builds on SSF to enable continuous re-evaluation of access decisions based on changing risk, not just a single authentication event.

Timeline

This timeline isn't about a single breach; it's about the evolution of an attack method:

Years 1-3: Attackers steal credentials, authenticate as victims, and get valid tokens. Detection relies on anomaly signals like impossible travel or device fingerprinting.

Years 4-6: Attackers bypass MFA through session hijacking, token replay, or social engineering. They don't need your password if they can steal the token your browser received after authentication.

Current state: AI-driven tools speed up reconnaissance and credential harvesting. Attackers can identify high-value tokens, understand their scope, and use them before your session timeout. The window between compromise and detection has shrunk.

This autumn: The OpenID Foundation will launch a self-certification suite aligned with SSF and CAEP, providing a compliance pathway.

Which Controls Failed or Were Missing

IR 8587 describes a control gap, not a failure. Most identity systems treat authentication as a one-time event. You prove your identity, get a token, and that token grants access until it expires. The missing control is continuous evaluation.

Specifically:

No real-time signal sharing between providers and relying parties. When a user's risk posture changes, that signal stays siloed in the identity provider. The relying party doesn't know, so the token remains valid.

No mechanism to revoke or re-evaluate access mid-session. Token revocation exists but is reactive and manual. By the time you detect suspicious activity and revoke the token, the attacker may have already exfiltrated data or moved laterally.

No standard way to communicate session state changes. If your identity provider detects a compliance issue or compromise, there's no standard protocol to inform every relying party holding an active token for that user.

What the Relevant Standard Requires

IR 8587 recommends existing OpenID Foundation specifications for federal agencies and cloud service providers.

Shared Signals Framework (SSF) defines the transport layer. It specifies how security events move between identity providers and relying parties in a standard format. When something changes, SSF ensures that signal reaches every system that needs it.

Continuous Access Evaluation Profile (CAEP) defines event types and decision logic. It builds on SSF to specify re-evaluation triggers and how relying parties should respond. CAEP provides enough context to make an access decision without forcing re-authentication.

The report emphasizes these specifications on page 31, paragraph 2. It's a directive: if you're implementing token protection controls, use these standards.

The OpenID Foundation developed these specifications through a working group process, and they're proven in production deployments. The test suite is open-source and free to use. Self-certification launches this autumn.

Lessons and Action Items for Your Team

Static tokens in dynamic environments create exposure windows. Your session timeout might be 30 minutes. An attacker needs 90 seconds to identify valuable data and initiate exfiltration.

Action: Map every system in your environment that issues or consumes tokens. Document their timeout policies. Calculate the exposure window. If it exceeds your acceptable risk threshold, you need continuous evaluation.

Token revocation without signal sharing is ineffective. You can revoke a token in your identity provider, but if the relying party doesn't check revocation status on every request, the token remains valid until it expires.

Action: Implement SSF to push revocation signals to relying parties in real time.

Compliance without interoperability is fragmentation. Every vendor has a proprietary way to signal risk events, leading to integrations that break when you swap vendors or add new applications.

Action: Require SSF and CAEP support in your procurement process. Use the OpenID Foundation's conformance tools.

AI-driven attacks don't give you time to react manually. Automate your response to session state changes.

Action: Automate your response to session state changes. Define your decision logic in advance: which signals trigger re-authentication, which trigger step-up verification, which trigger immediate revocation.

Open standards reduce your implementation risk. SSF and CAEP aren't vendor products. They're specifications with open-source reference implementations and free test suites.

Action: Start with the Shared Signals Working Group homepage. Review the specifications. Run the test suite against your current implementation. Identify gaps. This autumn's self-certification suite will give you a clear path to compliance.

The report is available now. The specifications are stable. The test suite is free. The only missing piece is your implementation plan.

Application Security Isn’t Optional Anymore.

You Might Also Like