SAML Shield

Stytch-hosted installation

Install and integrate Stytch's managed SAML Shield into your application.

Introduction

SAML Shield's SaaS SDK lets you validate SAML assertions against a hardened, protocol-aware backend with automatic updates to threat protections, meaning no patching or rule maintenance required. Here's a diagram of how your authentication flow will look after integrating SAML Shield:

SAML Shield Managed Integration Flow

Pre-req:

Before you begin, you'll need:

  • Stytch Public token. Log in or sign up →
  • A application that acts as a Service Provider and validates SAML assertions.

Installation

SAML Shield currently supports SDKs for Python and Node.js. For other language support, use SAML Shield via HTTP API using curl or any HTTP client.

1. Install SDK

Install the SAML Shield SDK from npm or yarn:

~
npm install stytch

2. Initialize the SDK

Import and configure the SDK using your Stytch Public Token:

~
const stytch = require("stytch");
const client = new stytch.SamlShieldClient({
// Retrieved from SAML Shield Dashboard
public_token: process.env.PUBLIC_TOKEN,
})

Tip: Store your public token in environment variables

3. Validate a SAML response

Send a SAML response (Base64-encoded XML) to SAML Shield for validation:

~
const params = {
SAMLResponse: 'base64 encoded SAML Response',
};
client.saml.validate(params)
.then(resp => { console.log(resp) })
.catch(err => { console.log(err) });

Testing Your Integration

Once SAML Shield is integrated, we recommend testing both standard and malicious SAML flows to ensure it's operating correctly.

1. Run a Normal SAML Flow

First, verify that your integration handles a valid SAML assertion end-to-end. Use your existing identity provider (e.g., Okta, Entra ID, or Google Workspace) and log in through your connected service (SP). If the assertion is valid and your SAML Shield integration is functioning, the flow should succeed without error.

2. Query your SAML endpoint with a malicious SAML response.

To confirm that SAML Shield is actively enforcing validation, try submitting an intentionally malformed or non-compliant response. For example, here is a SAML response that doesn’t sign the assertion or response. We should outright reject this input since we cannot verify if the response was faked. You can run this query against your application by running the following command:

~
EXAMPLE_SAML_RESPONSE="$(curl https://samlshield.com/examples/unsigned_saml_response.txt | base64)"
# Replace the SAML_CALLBACK_ENDPOINT with your SAML ACS endpoint
SAML_CALLBACK_ENDPOINT="https://samlshield.com/api/examples/callback"
curl -X POST $SAML_CALLBACK_ENDPOINT \
-H 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode "SAMLResponse=$EXAMPLE_SAML_RESPONSE"

Next steps

If both tests behave as expected, your integration is correctly enforcing SAML Shield’s security guarantees and is ready to catch a broad class of SAML-based attacks. To stay protected as new threats emerge, subscribe to SAML Shield release updates to stay informed about newly added validation rules and improvements.

From here, it’s also important to enforce critical checks such as strict Audience and Issuer validation to prevent lateral movement or misissued assertion abuse that are outside of the scope of SAML Shield. For a clear breakdown of what SAML Shield protects against—and what remains your application’s responsibility, please refer to our security coverage page.