Skip to main content
Identity Authority
Category: Federation & SSO

Signed Assertion

Also known as: Signed SAML Assertion
Simply put

A signed assertion is a message from an identity provider that carries information about a user, such as who they are and what they are allowed to access, with a digital signature attached to prove it is genuine and unaltered. The signature lets the receiving application confirm the message truly came from the trusted identity provider and was not tampered with in transit. In practice this term most often refers to SAML assertions, where the assertion portion of a login message is digitally signed.

Formal definition

In SAML 2.0, a signed assertion is an <Assertion> element that carries a digital signature (typically an XML Signature) applied specifically to the assertion, as distinct from signing the enclosing SAML <Response>. The assertion conveys authentication and/or attribute claims from an identity provider (IdP) to a service provider (SP), and the signature allows the SP to verify the assertion's integrity and origin authenticity against the IdP's trusted key. Signing the assertion is often described as a more lightweight option than signing the full response, as only the assertion itself is covered; some deployments sign the response, the assertion, or both, and this is frequently configurable on a per-SP basis or per binding. Note that signing establishes integrity and authenticity but is not the same as encryption, which would be required to protect confidentiality of assertion contents. The specific coverage, canonicalization, and algorithm details depend on the SAML profile, binding, and vendor configuration in use.

Why it matters

In federated single sign-on, the service provider (SP) has no direct visibility into how the identity provider (IdP) authenticated the user; it must rely entirely on the assertion it receives. A signed assertion is what makes that trust enforceable. Without a valid signature over the assertion, an SP cannot reliably distinguish a genuine authentication statement from a forged or tampered one, since the assertion travels through the user's browser and other intermediaries in many SAML bindings. The signature gives the SP a cryptographic basis to confirm both the origin (the assertion came from the expected IdP's key) and the integrity (the claims were not altered in transit) of the message before it acts on the identity and attribute claims inside.

The distinction between signing the assertion, signing the enclosing SAML <Response>, or signing both is not merely a configuration detail; it directly affects the security posture of a federation. Depending on the deployment, an SP may accept a signed response, a signed assertion, or require both, and misalignment between what the IdP produces and what the SP actually validates has historically been a source of SAML processing weaknesses. Because signing coverage is frequently configurable on a per-SP basis or per binding, architects and engineers need to be explicit about exactly which element is signed and which signatures the SP verifies, rather than assuming a signature anywhere in the message is sufficient.

It is equally important to remember what a signed assertion does not provide. Signing establishes integrity and origin authenticity, but it does not protect the confidentiality of the assertion's contents. Any attribute or identity data carried in a signed-but-unencrypted assertion may be readable by parties that handle the message in transit. Where confidentiality of assertion claims matters, encryption of the assertion is a separate control that must be applied in addition to signing.

Who it's relevant to

Security Architects
Architects designing federation trust models need to decide whether the assertion, the response, or both must be signed, and ensure the choice is consistent across every SP relationship. They should also weigh whether signing alone is sufficient or whether encryption of the assertion is required to protect the confidentiality of the claims it carries.
IAM and SSO Engineers
Engineers configuring IdP and SP integrations work directly with signing options such as per-SP or per-binding settings, including options that always sign the assertion regardless of binding. They are responsible for making sure the SP actually validates the specific signature the IdP produces, since a mismatch between what is signed and what is verified can undermine the trust the signature is meant to provide.
System Administrators
Administrators managing SAML relationships handle the operational configuration of signing on a per-SP basis and manage the IdP keys and certificates used to verify signatures. Correct key management and clear documentation of which elements are signed for each SP are essential to keeping federation functioning and auditable.
Compliance and Audit Leads
Those responsible for assurance need to confirm that assertion integrity and origin authenticity are enforced in federation flows, and to recognize that a signed assertion establishes authenticity but not confidentiality. Where sensitive attributes are conveyed, they should verify whether additional protection such as encryption is in place rather than assuming a signature covers confidentiality.

Inside Signed Assertion

Assertion payload
The set of statements being conveyed, such as authentication statements, attribute statements, or authorization decision statements in a SAML 2.0 assertion. The payload identifies the subject (principal) and carries claims about that subject.
Digital signature
A cryptographic signature (for example, an XML Signature in SAML 2.0) computed over the assertion or a specified portion of it, allowing a relying party to verify integrity and origin. Signing establishes that the content was not altered and originates from the expected issuer; it does not by itself provide confidentiality.
Issuer identity
An indication of the identity provider or authority that produced and signed the assertion, typically bound to the signing key or certificate so the relying party can determine trust.
Signing key and certificate reference
Material used to validate the signature, such as a reference to the signer's public key or X.509 certificate. In most deployments the relying party validates this against a pre-established trust configuration rather than trusting arbitrary keys.
Validity conditions
Constraints commonly included alongside the signed content, such as time-based validity windows and intended audience restrictions, that a relying party evaluates in addition to signature verification. Exact fields depend on the standard and profile in use.

Common questions

Answers to the questions practitioners most commonly ask about Signed Assertion.

Does a signed assertion mean the assertion is also encrypted and its contents are confidential?
No. Signing and encryption are distinct operations that serve different purposes. A signature provides integrity and authenticity, letting a relying party verify that the assertion came from the expected issuer and was not altered in transit. It does not conceal the contents. A signed-but-not-encrypted assertion can typically be read by anyone who intercepts it, including through browser tools or logs when transported via the user agent. If confidentiality of the claims is required, the assertion must be separately encrypted (for example, XML Encryption for SAML assertions or a JWE-wrapped JWT), and in most deployments transport-layer protection such as TLS is also used. Treat the signature as protecting against tampering and spoofing, not against disclosure.
Does verifying an assertion's signature by itself prove the user is authenticated and authorized to access my application?
No. A valid signature only establishes that the assertion is authentic and unmodified and that it originated from a trusted issuer. It does not, on its own, complete the access decision. The relying party must still validate the assertion's contents and conditions, such as audience restriction, issuer, validity time window, one-time-use or replay constraints, and any subject confirmation data, before treating the authentication event as trustworthy. Authorization is a separate step: what the authenticated subject may do is determined by the relying party's own access control logic (for example RBAC, ABAC, or a policy decision point), potentially using attributes carried in the assertion but not decided by the signature itself. A signature is a necessary check, not a sufficient one.
Which parts of a SAML assertion should be covered by the signature, and does signing the whole response cover the assertion?
This is a common source of validation gaps. In SAML 2.0, both the response and the individual assertion can be signed, and profiles differ on what is required. A signature over the response does not necessarily protect an embedded assertion, and vice versa, so a relying party should verify that the specific element it relies on for the security decision is within the signed scope. When enforcing this, confirm the signature reference actually covers the intended element and reject cases where the signed region and the processed region diverge, which is a class of vulnerability historically associated with XML signature wrapping. The exact requirements depend on the SAML profile and your library, so consult the relevant profile rather than assuming response-level signing is enough.
How should a relying party validate the signature on a self-contained token such as a signed JWT?
In most deployments the relying party retrieves the issuer's public signing key, commonly via a published JWKS endpoint, and verifies the JWT signature against it. Beyond the cryptographic check, validation typically includes confirming the algorithm matches an expected allowlist (rejecting none and avoiding algorithm-confusion between HMAC and asymmetric schemes), and validating standard claims such as issuer, audience, and expiry. Whether a token is a signed JWT or an opaque token affects this: opaque tokens usually require introspection at the issuer rather than local signature verification. The precise claim set and endpoints depend on the profile (for example OIDC Core) and the identity provider's configuration.
How are signing keys rotated without breaking verification of assertions already in flight?
Key rotation is typically handled by publishing multiple valid keys simultaneously and identifying which key signed a given assertion. In JWT-based flows the header key identifier (kid) lets the relying party select the correct key from the JWKS, and issuers commonly keep the retiring key published until outstanding tokens expire. SAML deployments often manage this through metadata that can carry more than one signing certificate during an overlap window. In practice, the safe pattern is to add the new key, allow validators to accept both old and new for a transition period, then retire the old key once no valid assertions signed by it remain. The exact mechanics depend on the vendor and how metadata or JWKS refresh is configured.
What checks beyond signature validation help prevent replay of a signed assertion?
Signature validation does not by itself stop replay, since a captured, still-valid assertion presented again will pass the signature check. To mitigate replay, relying parties typically enforce a short validity window (such as the NotBefore and NotOnOrAfter conditions in SAML or the expiry and issued-at claims in a JWT), validate audience and, where present, one-time-use or in-response-to correlation values, and in many deployments track identifiers to reject assertions seen before within their validity period. Transport protection such as TLS reduces the opportunity for interception in the first place. The specific anti-replay controls available depend on the standard, profile, and library in use.

Common misconceptions

A signed assertion is also encrypted and therefore confidential.
Signing provides integrity and origin authentication, not confidentiality. Unless the assertion is separately encrypted, its contents may be readable by intermediaries. Signing and encryption are distinct protections that can be applied independently.
A valid signature alone means the assertion can be accepted.
Signature verification confirms integrity and issuer origin, but a relying party should also evaluate other conditions such as validity time windows, audience restriction, and whether the issuer is trusted for the requested operation. A cryptographically valid signature from an untrusted or unintended issuer should not be accepted.
A signed assertion by itself proves what the principal is authorized to do.
A signed assertion typically carries authentication and attribute statements about a subject; authorization is a separate determination made by the relying party or a policy decision point based on those statements. Identification, authentication, and authorization remain distinct steps.

Best practices

Validate the full signature chain against a pre-established trust configuration and reject assertions signed by unknown or untrusted issuers rather than trusting any presented key.
Verify all applicable conditions, including time-based validity windows and audience restriction, in addition to the signature, so that a valid signature is never the sole acceptance criterion.
Apply encryption separately when assertion contents are sensitive, since signing alone does not provide confidentiality.
Confirm that the signature covers the assertion elements you rely on, and be cautious of profiles or configurations where only part of the message is signed.
Manage signing keys and certificates with defined rotation and revocation procedures, and ensure relying parties can obtain updated trust material.
Keep the assertion's authentication and attribute statements distinct from your authorization logic, treating the signed assertion as verified input to a separate access decision.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide