SAML token forgery is the creation or alteration of a SAML assertion so it is accepted as authentic by a service provider. It usually targets weak signature validation, trust misconfiguration, or replayable assertions, allowing an attacker to impersonate a user or bypass normal authentication controls.
How SAML token forgery works
SAML token forgery is dangerous because the attacker does not need to crack the user’s password if they can get a service provider to trust a fabricated or altered assertion. The security boundary is the issuer trust path, so the real question is whether the relying party validates the signature, issuer, audience and timing conditions with enough rigor.
Forgery usually succeeds when signature verification is weak, trust is configured too broadly, or the assertion can be replayed after issuance. In practice, that means the attacker is abusing federation trust rather than the login form itself.
Why forged SAML assertions are accepted
A SAML assertion is a signed statement about identity and session context, and service providers rely on that statement to grant access. If the verifier accepts unsigned data, mismatched certificates, ambiguous issuer values, or stale assertions, a forged token can look legitimate enough to cross the authentication boundary.
This is why federation failures often feel like authentication bypasses: the application is not being “logged into” in the normal sense, it is trusting an identity statement produced elsewhere. The service provider must therefore validate the assertion as an integrity-protected security object, not as ordinary application input.
Common attack paths and failure conditions
Attackers often target the identity provider, the federation configuration, or the signing material that protects SAML assertions. Compromise of a signing key, abuse of a rogue trust relationship, or manipulation of assertion handling can all turn a valid federation flow into a token forgery opportunity.
Replay is another important failure mode when assertions are accepted more than once or remain usable too long. If the environment does not bind the assertion tightly enough to the intended audience, time window, and relying party, the attacker can reuse it to impersonate a user from a different session or context.
What organisations should verify and harden
Defenders should inventory every SAML integration, identify which applications trust which identity provider, and confirm where signing material is stored and rotated. Federation trust reviews, vendor advisories, and configuration checks are the fastest way to find weak assumptions before they are abused.
It is also important to review whether the service provider enforces strict issuer, audience, and signature checks, and whether replay protections are active. For broader federation hygiene and sign-in protection practices, see the Workforce Identity Security Guide, which covers SSO, federation and session abuse patterns that often sit alongside SAML issues.
Risk and Threat Considerations
Forged SAML assertions can create direct account impersonation, privileged access abuse, and durable re-entry if the attacker can mint trusted assertions or replay them after the initial compromise. The risk is highest where federation trust is broad, signing keys are poorly protected, or token validation is inconsistent across applications.
Failure mechanism: A service provider accepts a fabricated or modified assertion because signature, issuer, audience, lifetime, or replay checks are incomplete, misconfigured, or bypassed.
Impact: The attacker can authenticate as the victim, access connected applications, and potentially pivot into mail, SaaS, administrative, or downstream business systems that trust the same federation path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SAML forgery defeats trusted user authentication for organizational access. |
| IA-5 — Authenticator Management | SAML assertions depend on protected signing material and its lifecycle. | |
| AC-3 — Access Enforcement | A forged assertion can bypass the access decision that follows authentication. | |
| Recommendation — Enforce strong authentication checks and federation validation before granting user sessions. Protect, rotate, and monitor federation signing material so forged assertions cannot be trusted. Tie access decisions to verified federation claims and reject assertions that fail policy checks. | ||
Related resources from NHI Mgmt Group
- Guide: Golden SAML and Federation Trust Abuse Defence Guide
- What happens when attackers disable GitHub security controls such as MFA, SAML, or personal access token approval?
- What are the signs that a service provider may have been targeted by SAML assertion forgery?
- What breaks when organisations rely on SAML or OAuth without strong token protection?
- What is the difference between rogue federation and token forgery in identity attacks?