Understanding SAML Request Signing and Response Encryption

SAML is the most widely used standard for enabling SSO between enterprise applications. Because SAML messages carry sensitive identity data, securing them is critical. Two of the most important mechanisms for strengthening SAML security are Request Signing (RS) and Response Encryption (RE).

These features serve two key security goals: integrity/authenticity (i.e., the message hasn’t been tampered with and comes from the expected party) and confidentiality (i.e., sensitive data can’t be read by unauthorized parties).

In this article, we’ll explain what each one is, why it matters, how they work, and how they fit into a SAML-based SSO solution.

Why these features matter

When an application (the Service Provider, or SP) and an Identity Provider (IdP) exchange authentication messages, those messages travel over multiple systems and sometimes across the public internet. Even with HTTPS in place, SAML messages can still be intercepted, altered, or logged at intermediate layers, especially when HTTPS is terminated by a proxy or load balancer before reaching the IdP.

Without additional protections:

• A malicious actor could spoof a SAML request or response.
• Sensitive user data, such as email addresses or group memberships, could be exposed.
• Outdated or invalid certificates could cause silent authentication failures.

Request Signing and Response Encryption mitigate these risks by using public-key cryptography to verify message authenticity and to protect sensitive data in transit.

What is Request Signing?

In a standard SAML flow, the SP initiates authentication by sending an AuthnRequest to the IdP. If that request isn’t signed, the IdP must simply trust that it came from a legitimate SP instance. Request Signing solves this problem by attaching a digital signature generated using the SP’s private key.

When the IdP receives the request, it:

1. Retrieves the SP’s public key from its metadata.
2. Verifies that the signature matches the content of the request.
3. Confirms that the request hasn’t been tampered with and originated from the expected SP.

If the signature is valid, the IdP processes the request; if not, it rejects it.

Why it’s important

Request Signing provides integrity and authenticity for messages traveling from the SP to the IdP. It ensures that:

• The authentication request is genuine and not forged by an attacker.
• The content (like RelayState or AssertionConsumerServiceURL) hasn’t been modified.
• The IdP can trust the SP even if HTTPS is terminated early in the network path.

Request Signing is especially valuable when there are multiple intermediaries (such as CDNs, proxies, or reverse gateways) between the SP and IdP, or when compliance frameworks require message-level integrity in addition to transport-level security.

How it works

The SP generates a pair of keys and an X.509 certificate, which it provides to the IdP via SAML metadata. The IdP uses the public key embedded in that certificate to verify the digital signature. Many SAML implementations also support exclusive canonicalization, which defines how the XML is normalized before signing, to avoid verification failures caused by minor formatting differences.

WorkOS supports signing all outbound SAML authentication requests using the SP’s private key. The signature can be embedded within the request XML or transmitted via the URL query string, depending on the binding used (HTTP-POST or HTTP-Redirect). For details, see the docs.

What is Response Encryption?

Once the user successfully authenticates, the IdP issues a SAML Response that includes one or more Assertions. These assertions often contain personally identifiable information (PII) such as email, full name, or role assignments.

Response Encryption ensures that these assertions can only be read by the SP they’re intended for. The process looks like this:

1. The IdP retrieves the SP’s public encryption certificate (provided in metadata).
2. Before sending the response, the IdP encrypts the assertion (or specific attributes within it) using that public key.
3. The SP uses its private key to decrypt the assertion after receiving it.

This encryption process can use different algorithms depending on configuration (for example, AES for the data and RSA for the key exchange).

Why it’s important

Encryption protects the confidentiality of user attributes during transmission. Even if an encrypted SAML response were intercepted, only the SP with the correct private key could decrypt it. This is particularly important in environments that handle:

• Highly sensitive user data (e.g., internal employee records, financial data).
• Federated access across networks with multiple layers of logging and inspection.
• Regulatory requirements such as GDPR, SOC 2, or HIPAA that demand end-to-end confidentiality.

Implementation details

Response Encryption doesn’t replace digital signatures; in fact, it’s typically used alongside response signing. The IdP first signs the response or assertion to guarantee authenticity, then encrypts it to guarantee confidentiality.

WorkOS’s SAML implementation supports encrypted assertions for all major IdPs. The platform automatically handles decryption and validation, so developers don’t need to manage the XML or cryptographic operations manually. For more info, see the docs.

Putting Request Signing & Response Encryption together

When you combine both request signing (RS) and response encryption (RE), you get a robust SAML flow with both strong integrity/authenticity and confidentiality. Here’s what a full cycle might look like:

1. The SP signs the AuthnRequest → IdP: protects from spoof or tamper of the request.
2. The IdP verifies the signed request, authenticates the user.
3. The IdP signs the SAML Response (or at least the assertion) → SP: protects from tamper and ensures authenticity of the response.
4. The IdP encrypts the assertion (or attributes) using the SP’s public key: protects sensitive data confidentiality.
5. The SP decrypts, verifies the signature, consumes the data.

This layered approach addresses multiple threat categories: replay attacks, tampered requests/responses, eavesdropping or logging of sensitive attributes, and mis-routing of authentication flows.

When to use what

Request Signing is recommended:

• When the IdP policy requires it (some enterprise IdPs mandate signed requests).
• When the SP → IdP path passes through intermediaries (e.g., HTTPS termination, proxies) that might expose the request or allow tampering. WorkOS explicitly says request signing is especially important in such cases.
• When you want to raise the security posture (even if not strictly required).

Response Encryption is recommended:

• When the SAML response includes highly sensitive information (personally identifiable information, financial or HR data, roles/groups with sensitive access).
• When you suspect there may be stages of the flow where data is logged, stored in cleartext, or intercepted (for example, enterprise load balancers or proxies).
• When compliance/regulation demands confidentiality of identity data in transit.

Certificate management and key rotation

Both signing and encryption rely on X.509 certificates: digital documents that associate a public key with an entity. Each certificate has an expiration date and must be periodically rotated. Poor certificate hygiene is one of the most common causes of SAML failures.

Best practices include:

• Separate signing and encryption keys. Use distinct key pairs for each purpose to simplify rotation and limit blast radius if one is compromised.
• Overlap validity periods during rotation. Maintain both old and new certificates in metadata until all parties have updated.
• Monitor certificate expiration. Implement alerts well before expiry to prevent unexpected downtime.
• Automate certificate updates. Many IdPs and SPs, including WorkOS, support automatic metadata refreshes to keep keys in sync.

During rotation, both parties must trust at least one common key; otherwise, requests or responses may begin failing due to invalid or missing signatures.

Challenges and considerations

• Compatibility: Not all IdPs or SPs support request signing or response encryption. If one side doesn’t support it, you’ll need to coordinate and possibly disable or limit the feature.
• Metadata synchronization: If certificates are rotated and metadata isn’t updated, SAML authentication may fail silently (e.g., “invalid signature”, “cannot decrypt”). WorkOS lists expired or mismatched certificates as common sources of failure.
• Clock skew and timing: SAML requests include timestamps (e.g., <IssueInstant>). If the clocks between SP and IdP differ significantly, requests may be considered stale or invalid. WorkOS highlights this in the certificate article.
• Key security: Private keys must be held securely (e.g., HSM or managed key vault). If a private key is compromised, signatures could be forged or decryptions performed by an attacker.
• Performance overhead: Encryption/decryption and signature verification add computational cost and complexity—important in high-volume flows.
• Operational burden: Certificate rotation, metadata exchange, monitoring, they all add to operational overhead. Using a platform like WorkOS can help streamline this.

Summary

SAML Request Signing and Response Encryption are essential features for securing enterprise SSO.

• Request Signing ensures that SAML authentication requests are authentic and tamper-proof.
• Response Encryption ensures that user attributes remain private and can only be read by the intended recipient.

Together, they deliver strong integrity, authenticity, and confidentiality guarantees for every SAML exchange. Proper certificate management completes the picture, ensuring these protections remain valid and effective over time.

Implementing these features gives organizations confidence that their SSO connections meet the security expectations of modern enterprise environments, protecting both user data and trust between identity systems.