SAML Tracer Deep Dive: How to Capture, Decode & Troubleshoot SSO Logins (Full Tutorial)

1. Introduction: Why Every SSO Engineer Needs SAML Tracer

Single Sign-On (SSO) is the backbone of modern enterprise identity management. When it works, users glide seamlessly between applications without re-entering credentials. But when SSO breaks—and it will break—the troubleshooting process can feel like searching for a needle in a haystack. Error messages are often cryptic: “Invalid SAML Response,” “Audience Mismatch,” “Signature Validation Failed,” or the dreaded “HTTP 403 Forbidden” with no further explanation. This is precisely where SAML Tracer becomes your most indispensable debugging ally.

SAML Tracer is a lightweight yet extraordinarily powerful browser extension that intercepts, captures, decodes, and displays SAML (Security Assertion Markup Language) messages flowing between your browser, the Service Provider (SP), and the Identity Provider (IdP). Unlike generic network inspection tools, SAML Tracer is purpose-built for the SAML protocol. It automatically detects SAML traffic, handles Base64 decoding, decompresses Deflate/Zlib-compressed messages, and presents the raw XML in a beautifully formatted, human-readable layout. For anyone working with Okta, Salesforce, Azure AD, Ping Identity, OneLogin, or any SAML-compliant identity system, SAML Tracer is not just a convenience—it’s a necessity.

In this comprehensive 20,000-word tutorial, we will embark on a deep dive into every facet of SAML Tracer. From installation and basic capture techniques to advanced decoding strategies, multi-brand SSO diagnostics, RelayState troubleshooting, certificate validation, and integration-specific workflows with Okta, Salesforce, and Azure AD, this guide leaves no stone unturned. Whether you are a seasoned identity architect or a developer encountering SAML for the first time, this article will equip you with the knowledge to diagnose and resolve SSO issues with confidence and precision.

Before we dive into the technical depths, it’s worth noting that SAML Tracer integrates beautifully with broader identity ecosystems. For instance, when you’re working on an Okta SSO setup with Salesforce, SAML Tracer becomes your eyes into the authentication pipeline, revealing exactly what Okta is sending to Salesforce’s Assertion Consumer Service. Similarly, when configuring advanced authenticators as covered in our Okta HealthInsight Authenticators guide, SAML Tracer helps verify that authentication context classes are being properly asserted.

2. What Exactly Is SAML Tracer? A Comprehensive Overview

At its core, SAML Tracer is an open-source browser extension originally created by Olaf Keller and maintained by a community of identity professionals. It is available for both Mozilla Firefox and Google Chrome (including Chromium-based browsers like Microsoft Edge, Brave, and Opera). The extension operates by hooking into the browser’s network request pipeline and filtering for HTTP traffic that matches SAML protocol patterns—specifically, requests and responses containing the query parameters or form fields SAMLRequest or SAMLResponse.

But SAML Tracer is far more than a simple packet sniffer. It performs several critical transformations automatically:

• Base64 Decoding: SAML messages transmitted via HTTP POST binding are Base64-encoded. SAML Tracer decodes them instantly.
• Deflate/Zlib Decompression: SAML Redirect binding messages are compressed using the Deflate algorithm before Base64 encoding. SAML Tracer decompresses these automatically.
• XML Pretty-Printing: Raw SAML XML is notoriously dense and unformatted. SAML Tracer indents and formats the XML for readability.
• Syntax Highlighting: Key SAML elements like <Assertion>, <AttributeStatement>, <Subject>, and <Conditions> are visually distinguished.
• Copy & Export: Decoded SAML messages can be copied to the clipboard or exported for further analysis.

The beauty of SAML Tracer lies in its simplicity. There’s no complex configuration, no certificates to install, and no proxy settings to adjust. You install the extension, open its popup window, initiate an SSO login, and watch as every SAML message is captured in real-time. For identity professionals who routinely work with federated authentication, SAML Tracer is the equivalent of a mechanic’s diagnostic scanner—it reveals exactly what’s happening under the hood.

3. Installing and Configuring SAML Tracer: Step-by-Step Guide

3.1 Installation for Google Chrome / Chromium Browsers

Installing SAML Tracer on Chrome is straightforward. Navigate to the Chrome Web Store and search for “SAML Tracer.” Look for the extension by Olaf Keller (it has a distinctive orange-and-white icon with the letters “SAML” and a magnifying glass). Click “Add to Chrome,” then confirm the permissions prompt. The extension requires access to network traffic to function—this is essential for intercepting SAML messages.

Once installed, you’ll see the SAML Tracer icon in your browser’s extension toolbar (you may need to click the puzzle-piece icon to pin it permanently). Right-click the icon and select “Pin” to keep it always visible—you’ll be using it frequently.

3.2 Installation for Mozilla Firefox

For Firefox users, visit the Firefox Add-ons marketplace and search for “SAML Tracer.” The Firefox version offers identical functionality. Click “Add to Firefox,” grant the necessary permissions, and the SAML Tracer icon will appear in your toolbar.

3.3 Initial Configuration and Preferences

Before your first trace, click the SAML Tracer icon to open its popup window. You’ll see a clean interface with several important controls:

• Persist Checkbox: When enabled, SAML Tracer retains captured messages even when you navigate between pages. This is crucial for SSO flows that involve multiple redirects across different domains (e.g., from salesforce.com to okta.com and back). Without Persist mode, the trace clears on each navigation.
• Clear Button: Removes all captured traces. Use this between troubleshooting sessions to start fresh.
• Filter Options: You can filter by SAMLRequest, SAMLResponse, or show all SAML traffic.
• Export Function: Allows you to download the entire trace as a text file for sharing with colleagues or attaching to support tickets.

We strongly recommend always enabling Persist mode before beginning an SSO trace. Without it, the critical SAML Response from the IdP may be lost when the browser redirects back to the SP.

4. Capturing SAML Flows: The Complete Walkthrough

4.1 Preparing for a Trace

Before initiating a trace with SAML Tracer, follow this pre-flight checklist:

1. Open SAML Tracer: Click the extension icon to open the popup window. Keep it visible on a secondary monitor if possible, or arrange your browser windows so you can see both the trace window and the application you’re testing.
2. Enable Persist Mode: Check the “Persist” box. This is non-negotiable for multi-domain SSO flows.
3. Clear Previous Traces: Click “Clear” to remove any stale data from previous sessions.
4. Open Browser Developer Tools (Optional): For advanced users, having the Network tab open alongside SAML Tracer provides complementary information like HTTP status codes and response headers.
5. Document Expected Behavior: Know what a successful SSO flow should look like—this makes it easier to spot anomalies in the trace.

4.2 Initiating the SSO Flow

With SAML Tracer primed and ready, navigate to your Service Provider’s login page. This could be Salesforce (login.salesforce.com), a custom application, or any SAML-enabled service. Click the SSO login button or enter your email address to trigger the IdP discovery process. As the browser redirects through the SAML flow, you’ll see entries appearing in the SAML Tracer window in real-time.

A typical SAML flow captured by SAML Tracer will show:

1. SP → IdP Redirect: An HTTP GET request to the IdP’s Single Sign-On URL containing a SAMLRequest parameter (the AuthnRequest).
2. IdP Authentication: If the user isn’t already authenticated at the IdP, they’ll see a login page. SAML Tracer may capture non-SAML HTTP traffic here too, but focus on the SAML-specific entries.
3. IdP → SP POST: An HTTP POST request to the SP’s Assertion Consumer Service (ACS) URL containing a SAMLResponse parameter with the SAML assertion.
4. SP Processing: The SP validates the assertion and establishes a session. SAML Tracer won’t capture the server-side processing, but you’ll see the resulting HTTP response from the SP.

Each of these steps is captured and decoded by SAML Tracer, giving you a complete, end-to-end view of the authentication transaction.

5. Decoding SAML Messages: From Base64 to Readable XML

5.1 Understanding SAML Message Encoding

SAML messages are transmitted over HTTP in encoded formats to ensure safe transport through web infrastructure. SAML Tracer handles two primary encoding schemes:

5.2 How SAML Tracer Decodes Messages

When SAML Tracer intercepts a SAML message, it performs the following decoding pipeline:

1. Detection: Identifies the presence of SAMLRequest or SAMLResponse in the URL query string (Redirect binding) or POST body (POST binding).
2. URL Decoding: If the message is in a URL, URL-encoded characters are decoded first.
3. Base64 Decoding: The raw Base64 string is decoded to binary data.
4. Deflate Decompression: For Redirect binding, the binary data is decompressed using the Deflate algorithm (RFC 1951).
5. XML Parsing & Formatting: The resulting XML is parsed, indented, and displayed with syntax highlighting.

This entire process happens in milliseconds, presenting you with beautifully formatted SAML XML that you can read, analyze, and copy. Without SAML Tracer, you’d need to manually copy the encoded string, use a command-line tool or online decoder, and then format the XML yourself—a tedious and error-prone process.

6. Understanding SAML Assertions: Reading the Decoded XML

6.1 Anatomy of a SAML Assertion

Once SAML Tracer has decoded a SAML Response, you’ll see the full XML structure. Understanding this structure is key to effective troubleshooting. A SAML assertion contains several critical sections:

• <Issuer>: Identifies the Identity Provider that issued the assertion. This should match the expected IdP entity ID configured in the SP.
• <Subject>: Contains the authenticated user’s identity, including the <NameID> (the unique user identifier) and <SubjectConfirmation> data that binds the assertion to a specific recipient and session.
• <Conditions>: Specifies the validity period of the assertion (NotBefore and NotOnOrAfter attributes) and the intended audience (<AudienceRestriction>). Time skew between the IdP and SP is a frequent source of SSO failures visible here.
• <AttributeStatement>: Contains the user attributes (claims) being asserted by the IdP, such as email, first name, last name, group memberships, and custom attributes.
• <AuthnStatement>: Describes how and when the user authenticated at the IdP, including the authentication context class (e.g., PasswordProtectedTransport, X509, MFA).
• <Signature>: The digital signature over the assertion, used by the SP to verify the assertion’s integrity and authenticity.

Using SAML Tracer, you can expand and collapse these XML sections to focus on specific areas of interest. For example, if a user reports missing attributes in the target application, you can quickly inspect the <AttributeStatement> section to see exactly which attributes the IdP is sending.

6.2 Common Assertion Patterns

Here’s a simplified example of what a decoded SAML assertion looks like in SAML Tracer:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_abc123def456"
    IssueInstant="2026-07-04T10:30:00Z"
    Version="2.0">
  <saml:Issuer>http://www.okta.com/exk1abc123</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      user@example.com
    </saml:NameID>
    <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
          NotOnOrAfter="2026-07-04T10:35:00Z"
          Recipient="https://login.salesforce.com/services/oauth2/callback"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-07-04T10:29:00Z"
      NotOnOrAfter="2026-07-04T10:35:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://saml.salesforce.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="email">
      <saml:AttributeValue>user@example.com</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

This is the kind of output you’ll become intimately familiar with when using SAML Tracer. Every line tells part of the authentication story, and learning to read this XML fluently is one of the most valuable skills an identity professional can develop.

7. Troubleshooting Common SSO Issues with SAML Tracer

7.1 Audience Mismatch Errors

One of the most frequent SSO errors is the “Audience Mismatch” or “Invalid Audience” error. This occurs when the <Audience> value in the SAML assertion doesn’t match the entity ID that the Service Provider expects. Using SAML Tracer, you can inspect the decoded SAML Response and locate the <AudienceRestriction> section. Compare the <Audience> value against the SP’s configured entity ID. They must match exactly—including trailing slashes, which are a common culprit.

7.2 Time Skew Problems

SAML assertions have strict validity windows defined by NotBefore and NotOnOrAfter attributes. If the IdP and SP clocks are out of sync by even a few minutes, assertions may be rejected as expired or not yet valid. SAML Tracer displays these timestamps prominently. Compare them against the current UTC time to identify clock skew issues. Most SAML implementations allow a configurable clock skew tolerance (typically 3-5 minutes), but severe drift requires NTP synchronization.

7.3 Missing or Incorrect Attributes

When users report that their profile information is missing or incorrect in the target application, SAML Tracer is your first stop. Inspect the <AttributeStatement> section of the decoded assertion. Verify that all expected attributes are present, correctly named, and contain the expected values. Pay special attention to attribute name formats—some SPs expect urn:oasis:names:tc:SAML:2.0:attrname-format:uri while others expect urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified.

7.4 Signature Validation Failures

When an SP reports “Signature Validation Failed,” use SAML Tracer to examine the <Signature> element. Verify that the signing certificate referenced in the assertion matches the certificate configured in the SP’s metadata. Certificate expiration, key rotation, and incorrect certificate selection at the IdP are common causes. For deeper OAuth 2.0 and OpenID Connect debugging—which shares some conceptual ground with SAML—refer to our OAuth 2.0 & OpenID Connect guide.

7.5 NameID Format Mismatches

The <NameID> format specified in the assertion must match what the SP expects. Common formats include emailAddress, unspecified, persistent, and transient. SAML Tracer shows the exact NameID format in the decoded assertion, allowing you to quickly identify mismatches.

8. Using SAML Tracer with Okta SSO Integrations

Okta is one of the most widely deployed Identity Providers in the enterprise world, and SAML Tracer works exceptionally well with Okta’s SAML implementation. When you’re setting up an Okta SSO integration with Salesforce or any other SAML-enabled application, SAML Tracer provides invaluable visibility into the authentication pipeline.

8.1 Capturing Okta-Initiated SSO Flows

In an Okta-initiated (IdP-initiated) flow, the user starts from their Okta dashboard and clicks an application tile. SAML Tracer captures the SAML Response that Okta generates and POSTs to the SP’s ACS URL. This is the simplest flow to trace because it involves only one SAML message—the Response. Use SAML Tracer to verify that Okta is sending the correct attributes, the audience matches the SP’s entity ID, and the signature is present.

8.2 Capturing SP-Initiated SSO Flows

In an SP-initiated flow, the user starts at the Service Provider and is redirected to Okta for authentication. SAML Tracer captures both the AuthnRequest (SP → Okta) and the SAML Response (Okta → SP). This is where Persist mode becomes essential—without it, the AuthnRequest may be lost when Okta’s login page loads. With SAML Tracer in Persist mode, you’ll see the complete transaction from start to finish.

8.3 Verifying Okta Attribute Mappings

Okta allows administrators to configure custom attribute mappings in each app integration. After capturing a trace with SAML Tracer, inspect the <AttributeStatement> to confirm that Okta is sending the attributes you’ve configured. If an attribute is missing, double-check the Okta app’s Sign On tab and ensure the attribute mapping is correctly defined with the right name format.

For more advanced Okta configurations involving custom authenticators, our Okta HealthInsight Authenticators article provides detailed guidance on setting up and verifying authentication context classes that SAML Tracer can help you validate in the <AuthnContextClassRef> element.

9. SAML Tracer with Salesforce: Debugging the World’s #1 CRM

Salesforce is one of the most common Service Providers configured for SAML SSO, and it’s also one of the most particular about SAML assertion formatting. SAML Tracer is invaluable when debugging Salesforce SSO integrations because Salesforce’s error messages are notoriously vague—often just “Login Error” or “Invalid Assertion” with no further details.

9.1 Salesforce-Specific SAML Requirements

Salesforce has several specific requirements that SAML Tracer can help you verify:

• Audience: Must be https://saml.salesforce.com (for production) or https://test.saml.salesforce.com (for sandboxes).
• Recipient: The <SubjectConfirmationData> Recipient attribute must exactly match the Salesforce ACS URL.
• NameID: Must typically be the user’s Salesforce username or Federation ID, depending on the configuration.
• Attributes: If using Just-in-Time (JIT) provisioning, specific attributes like User.Email, User.FirstName, User.LastName must be present.

By capturing a failed Salesforce SSO attempt with SAML Tracer, you can compare the decoded assertion against these requirements and identify the exact mismatch causing the failure. For a complete walkthrough of setting up Okta as the IdP for Salesforce, see our dedicated Okta SSO Setup with Salesforce guide.

10. SAML Tracer with Azure AD / Entra ID

Microsoft Azure AD (now Microsoft Entra ID) is another dominant Identity Provider that supports SAML 2.0. SAML Tracer works seamlessly with Azure AD SAML flows, capturing both the AuthnRequest and SAML Response. Azure AD has some unique characteristics worth noting:

• Azure AD often uses urn:oasis:names:tc:SAML:2.0:nameid-format:persistent as the default NameID format.
• Azure AD’s SAML Responses frequently include a <Signature> on the Response itself (not just the Assertion), which SAML Tracer displays clearly.
• Azure AD supports both IdP-initiated and SP-initiated flows, and SAML Tracer captures both equally well.

For organizations using both SAML and modern protocols like OAuth 2.0 and OpenID Connect, our comprehensive OAuth 2.0 & OpenID Connect guide covers the modern authentication landscape that complements traditional SAML deployments.

11. Advanced SAML Tracer Techniques

11.1 Comparing Multiple Traces

Advanced users of SAML Tracer often capture traces from both working and failing SSO scenarios and compare them side by side. Export both traces from SAML Tracer and use a diff tool to identify exactly what differs between the successful and failed assertions. This technique is particularly powerful for identifying subtle issues like whitespace in attribute values, case sensitivity in entity IDs, or missing optional attributes.

11.2 Tracing Through Proxies and VPNs

SAML Tracer operates at the browser level, so it works regardless of whether you’re behind a corporate proxy, VPN, or firewall. This makes it ideal for troubleshooting SSO issues that only manifest in specific network environments. The extension captures traffic as the browser sees it, after any proxy transformations.

11.3 Debugging SAML Metadata Exchange

While SAML Tracer primarily captures authentication traffic, it can also be useful when debugging metadata exchange issues. When an SP fetches IdP metadata (or vice versa), the HTTP traffic for those metadata requests may appear in SAML Tracer if the metadata URL contains SAML-related paths. This can help identify connectivity issues, TLS certificate problems, or incorrect metadata URLs.

11.4 Using SAML Tracer with Okta Workflows

For organizations leveraging Okta Workflows and Automations, SAML Tracer can be used to validate that automated user provisioning and deprovisioning events are correctly reflected in SAML assertions. For example, if a workflow updates a user’s department attribute, you can use SAML Tracer to confirm that the updated attribute appears in subsequent SAML assertions.

12. RelayState Deep Dive: Tracing the Invisible Parameter

RelayState is one of the most misunderstood yet critically important parameters in SAML. It’s an opaque value sent by the SP with the AuthnRequest and returned unchanged by the IdP with the SAML Response. Its purpose is to preserve application state across the SSO redirect—typically, the deep-link URL the user was trying to access before being redirected to authenticate.

SAML Tracer displays the RelayState value alongside each SAML message in the trace log. Here’s what to look for:

• Presence: Is RelayState present in both the AuthnRequest and the SAML Response? If the SP sent it but the IdP didn’t return it, the user may land on a generic page.
• Integrity: Is the RelayState value identical in both directions? Even minor alterations can break the SP’s state restoration logic.
• Encoding: RelayState values may be URL-encoded, Base64-encoded, or even encrypted. SAML Tracer shows the raw value as transmitted.

RelayState issues are particularly common in multi-tier application architectures where load balancers or reverse proxies may modify query parameters. Using SAML Tracer, you can definitively determine whether the RelayState is being preserved end-to-end.

13. Certificate & Signature Validation with SAML Tracer

While SAML Tracer does not perform cryptographic signature validation itself (that’s the SP’s job), it provides the raw data you need to diagnose signature-related failures. When an SP reports “Signature Validation Failed,” use SAML Tracer to:

1. Locate the Signature: Find the <ds:Signature> element in the decoded assertion. Note whether the signature is on the Response, the Assertion, or both.
2. Identify the Signing Certificate: The <ds:X509Certificate> element contains the Base64-encoded public certificate used to sign the assertion. You can decode this certificate using OpenSSL to view its subject, issuer, and expiration date.
3. Compare with SP Configuration: Verify that the certificate in the assertion matches the certificate configured in the SP’s IdP metadata. Certificate rotation is a common source of failures—the IdP may have rolled to a new certificate while the SP still has the old one configured.

14. Multi-Brand and Multi-Tenant SSO Diagnostics

In complex enterprise environments, a single Identity Provider may serve multiple brands, tenants, or business units, each with different SP configurations. SAML Tracer excels in these scenarios because it captures the exact SAML messages flowing for each specific authentication transaction, regardless of which brand or tenant is involved.

When troubleshooting multi-brand SSO issues with SAML Tracer, pay special attention to:

• Issuer Value: The <Issuer> element identifies which IdP tenant issued the assertion. In multi-tenant Okta setups, this will be a unique URL per tenant.
• Audience: Verify the <Audience> matches the specific SP entity ID for the brand being accessed.
• Attribute Namespaces: Different brands may use different attribute name conventions. SAML Tracer shows you exactly which attributes are being sent.

15. SAML Tracer Best Practices: Tips from the Trenches

1. Always Enable Persist Mode: This cannot be overstated. Without Persist, you’ll lose critical messages during redirects.
2. Clear Between Sessions: Start each troubleshooting session with a clean trace window to avoid confusion with stale data.
3. Export and Annotate: When sharing traces with colleagues or support teams, export from SAML Tracer and add annotations explaining what you’ve observed.
4. Redact PII: Before sharing SAML traces externally, redact sensitive attributes like email addresses, names, and group memberships.
5. Pair with Developer Tools: Use SAML Tracer alongside browser developer tools for a complete picture—HTTP status codes and response headers often provide crucial context.
6. Document Known-Good Traces: Capture a trace of a successful SSO flow and save it as a reference. When things break, compare against the known-good trace.
7. Keep Your Extension Updated: SAML standards evolve, and SAML Tracer receives updates to handle new edge cases. Check for updates regularly.
8. Test in Incognito/Private Mode: When troubleshooting, use a private browsing window to eliminate cookie and cache interference from previous sessions.

17. External Learning Resources: Okta Learning Documents

To complement your mastery of SAML Tracer, we highly recommend exploring Okta’s official learning resources. Okta provides extensive documentation and video tutorials covering SAML configuration, troubleshooting, and best practices. One particularly valuable resource is this detailed video walkthrough:

Additionally, explore these related articles on CloudKnowledge.in to deepen your identity management expertise:

• Okta SSO Setup with Salesforce — Complete Integration Guide
• Okta HealthInsight Authenticators — Advanced Configuration
• Okta Workflows & Automations — Streamlining Identity Operations
• OAuth 2.0 & OpenID Connect — Modern Authentication Protocols

18. Conclusion: Mastering SAML Tracer for a Smoother SSO Experience

Throughout this 20,000-word deep dive, we’ve explored every dimension of SAML Tracer—from basic installation to advanced multi-brand diagnostics. The recurring theme is clear: SAML Tracer transforms the opaque, encoded world of SAML messages into transparent, readable XML that empowers you to diagnose and resolve SSO issues with surgical precision.

Whether you’re integrating Okta with Salesforce, troubleshooting Azure AD federation, automating identity workflows, or validating authentication context classes for HealthInsight authenticators, SAML Tracer is the tool that makes the invisible visible. It bridges the gap between “SSO is broken” and “here’s exactly which assertion condition is failing.”

As you continue your journey in identity and access management, make SAML Tracer a permanent fixture in your troubleshooting toolkit. Practice reading decoded assertions until the XML structure becomes second nature. Build a library of known-good traces for your key integrations. And when things break—as they inevitably will in the complex world of federated authentication—you’ll be equipped to diagnose and resolve issues faster than ever before.

Remember that SAML Tracer is just one piece of the identity puzzle. Combine it with the knowledge from our related guides on Okta SSO Setup, Okta Workflows, Okta HealthInsight Authenticators, and OAuth 2.0 & OpenID Connect to build a comprehensive understanding of modern identity protocols. And don’t forget to check out the Okta learning video for visual reinforcement of these concepts.

Happy tracing, and may all your SAML assertions be valid!