How to Debug SAML Logins With SAML-tracer

What does the SAML-tracer browser extension do?

SAML-tracer watches the requests your browser makes during a single sign-on flow and shows you the SAML messages inside them. Those messages are normally compressed or base64-encoded, so you cannot read them in the address bar.

In a browser-based SAML login, the service provider (the app) sends you to the identity provider (your SSO), and the identity provider sends you back with a signed assertion. Everything passes through your browser, which makes the browser the best place to look when a login fails.

The extension started life as a Firefox add-on and now has a Chrome version. Its source and issue tracker are on the SAML-tracer GitHub page, and we list it in the directory as SAML-tracer. The other directory extensions below help with the surrounding steps.

Install it from its Chrome Web Store page like any other extension, then pin it from the puzzle-piece menu so the icon is one click away. It needs wide access to web requests, because that is how it sees the traffic. Read what browser permissions mean before adding any tool with that reach, and remove it when the investigation is over. You can also open it with the Alt + Shift + S keyboard shortcut.

How do you capture a SAML login in Chrome?

Open the tracer first, then sign in. The tool only records what happens after its window is open, so starting late means missing the message you need.

1. Click the SAML-tracer icon in the toolbar, or press Alt + Shift + S. A separate tracer window opens; keep it visible next to the browser.
2. Clear any old entries with the Clear button so the list only shows the new attempt.
3. In your main window, open the application's login page in a fresh tab or a private window (see the session section below).
4. Start the SSO flow, enter your credentials at the identity provider, and let it fail or complete.
5. Click Pause in the tracer once the error page loads, so later requests do not push the SAML entries out of view.

Requests that carry a SAML message are highlighted with a SAML logo at the right of the request list. Ordinary page loads, images and scripts appear too; turn on Hide resources or Show protocol requests only in the toolbar to cut the noise.

How do you read what SAML-tracer captured?

Click a request in the list, then use the tabs at the bottom of the tracer to see it from different angles. The SAML tab is the one that matters most.

HTTP

Raw request and response headers, including the Location header on redirects and Set-Cookie values, which is where to spot a missing session cookie after the return trip.

Parameters

Query string or form fields, including the SAMLRequest, SAMLResponse and RelayState values in their encoded form.

SAML

The decoded XML of the request or response, so you can read the issuer, destination, conditions and attributes.

A normal login shows at least two SAML entries. The first is the AuthnRequest going from the app to the identity provider. The second is the Response going back to the app's assertion consumer service (ACS) URL.

If you only see the request and no response, the identity provider stopped before issuing an assertion. If you see the response but the app still rejects it, the fault is usually a value inside that response, which is what the next sections cover.

Why do some SAML messages look different in the tracer?

SAML messages can travel in two common ways, called bindings, and the tracer shows each differently. Knowing which one you have explains what you see in the Parameters tab.

Requests from the app to the identity provider commonly use the redirect binding. Responses carrying assertions almost always use the POST binding, because they are too large for a URL.

A related trap is RelayState. It is an opaque value the app sends along so it can return you to the right page after login. If it is lost between the two legs, you land on a default page instead of where you started, and that is a configuration problem rather than an assertion problem.

Which SAML errors can you find in the decoded XML?

Most failed SAML logins come down to a small set of mismatched values. Open the decoded response and check each field against what the application has configured.

Work from the top of that table down. A non-success status makes the rest irrelevant, while a success status with a mismatched audience is a configuration fix on one side.

How do you get a clean run when the SSO session keeps interfering?

If you are already signed in to the identity provider, the flow skips the login screen and you may never see a fresh request. A clean session gives you a repeatable trace.

The simplest option is a private window, but extensions do not run in private windows unless you allow it. Open chrome://extensions, choose Details on SAML-tracer, and switch on Allow in Incognito.

The other option is to clear the session cookies for the two domains involved. Cookie-Editor lets you delete individual cookies for the current site without touching the rest of your browsing. Clear Cache does a broader reset in one click, at the cost of signing you out elsewhere.

• Test as a new user: use a second Chrome profile with only the tracer installed, so no other extension changes headers or blocks scripts.
• Try a forced login: some applications can send a request that forces the identity provider to prompt again, which is useful when you suspect a stale session.
• Watch the Set-Cookie headers: if the app never sets its session cookie after the response, the assertion was rejected even if the page looks normal.

If cookies are the suspect, Cookie Manager can export the state before and after a failed attempt so you can compare them.

How do you share a SAML trace without leaking data?

A saved trace can contain session cookies, names, email addresses and group memberships, so treat it as sensitive. Redact before it leaves your machine.

1. In the tracer, use the Export option to save the captured session to a file, or copy just the decoded XML from the SAML tab.
2. Open the file in a text editor and remove cookie values, Set-Cookie lines and any authorization headers.
3. Replace personal values in NameID and attributes with placeholders like user@example.com.
4. Keep the structural parts: issuer, destination, audience, conditions, status and the signature block layout.
5. Send the redacted file to your vendor's support team through their approved channel.

Avoid pasting a live assertion into an online decoder website. The tracer already decodes it locally, and a live assertion within its validity window can be dangerous in the wrong hands.

When should you use Chrome DevTools instead of, or alongside, SAML-tracer?

Use DevTools for network, console and cookie details, and SAML-tracer for decoding the SAML payload. The two answer different questions, and combining them covers most SSO failures.

1. Press F12 or Ctrl + Shift + I (Cmd + Option + I on Mac) to open DevTools.
2. Open the Network tab and tick Preserve log, so redirects do not clear the list.
3. Tick Disable cache, then reproduce the login.
4. Look at the status codes of each hop: a 302 is a redirect, a 200 with a form is the POST binding, and a 4xx or 5xx points to a server-side error page.
5. Switch to the Application tab to inspect cookies and check SameSite and Secure flags on the app's session cookie.

DevTools can show the raw base64 SAMLResponse, but it will not decode it for you. That is the gap the tracer fills. If you have not used the panel before, read how to enable developer mode in Chrome for the related settings.

Some SSO failures are not SAML at all. A blocked third-party cookie, an extension that rewrites headers or a corporate proxy can break the flow before any assertion is created. If the trace shows no SAML message, check those first.

Which other extensions help with SSO and login debugging?

SAML-tracer covers the assertion, but a few other tools make the surrounding work quicker. Browse the developer tools category or the developers hub for more.

Keep the toolset small. Every extra extension in the profile is one more thing that can alter headers or block a redirect, which is exactly what you do not want when tracing.