Encrypted SAML Assertion

What is an encrypted SAML assertion?

A SAML assertion is the signed statement an Identity Provider sends to a Service Provider to vouch for a user’s identity during SSO. By default it’s signed (so the SP can verify it’s authentic and unaltered) but its contents are readable — anything or anyone that handles the message in transit can see the attributes inside: username, email, roles, group memberships. An encrypted SAML assertion additionally encrypts that payload so only the intended Service Provider — the holder of the right private key — can read it. Signing proves who sent it and that it wasn’t tampered with; encryption ensures nobody but the recipient can read it. They solve different problems and are often used together.

Signing vs encryption — a distinction that matters for privacy

This is the crux: signature ≠ confidentiality. A signed-but-unencrypted assertion is tamper-evident but fully visible. That visibility is a real concern because SAML assertions frequently carry personal and sensitive attributes (identifiers, email, entitlements), and the SAML flow is typically browser-mediated — the assertion passes through the user’s browser on its way from IdP to SP (the HTTP POST binding), meaning it exists, decoded, in a place the user (or malware on their machine, or browser history/logs) can inspect. Even with TLS protecting each hop, TLS only guards data in transit between two endpoints; it doesn’t stop the browser or an intermediary from reading a message that legitimately passes through it. Encrypting the assertion closes that gap: the sensitive attributes stay confidential end-to-end, decryptable only by the SP’s private key, regardless of what the assertion passes through.

When it’s warranted — and the cost

Encryption is warranted when assertions carry data whose exposure matters: regulated personal data (privacy regimes like GDPR/HIPAA), sensitive role/entitlement information, or any deployment where the browser-mediated path is considered untrusted. It’s a defense-in-depth measure — you still sign (for authenticity) and encrypt (for confidentiality). The costs are the usual encryption tradeoffs: key management (the SP’s key pair must be provisioned, protected, and rotated), added configuration complexity in the IdP↔SP metadata exchange, and slightly more processing. Many enterprise deployments skip encryption when assertions carry only innocuous identifiers over trusted channels — a defensible choice — but reach for it the moment sensitive attributes are in play. The modern alternative ecosystem, OIDC, has an analogous concept (encrypted JWTs / JWE) for the same reason.

What people get wrong

• Assuming a signature keeps data private — signing proves authenticity, not confidentiality; an unencrypted assertion is fully readable.
• Relying on TLS alone: TLS protects transit between endpoints, but the browser-mediated SAML flow means the assertion passes through the user’s browser in readable form.
• Encrypting without managing keys — the SP’s decryption key becomes critical infrastructure; poor key handling undermines the whole benefit.

Primary source: OASIS SAML V2.0 core (encrypted elements)