The OAuth2/OIDC Debugger Has Learned a New Trick: SAML2 Support Is Here

Identity engineers have a complicated relationship with SAML.

On good days, it provides reliable enterprise federation that quietly enables Single Sign-On across thousands of applications.

On bad days, it produces a Base64-encoded, compressed XML document wrapped inside another XML document, signed with a certificate that expired three weeks ago, while an administrator insists that “nothing changed.”

To make those days a little less painful, I’m excited to announce that the OAuth2/OIDC Debugger on IDP Tools now includes SAML 2.0 protocol support. There is, also, basic SAML 1.0 and 1.1 support, but these are old protocols (that I haven’t personally seen in years) and KeyCloak (used in our test suite) doesn’t support these older versions (and we didn’t want to introduce additional dependencies for the test suite).

The goal is to make it easier to understand, inspect, generate, and troubleshoot SAML messages without spending half the afternoon decoding XML by hand or with half a dozen different tools. There are other OAuth2 debugging tool sites — ours supports multiple identity protocols (with more to come).

Why Add SAML Support?

Although OAuth 2.0 and OpenID Connect have become the dominant protocols for modern application development, SAML remains a critical component of enterprise identity infrastructure.

SAML continues to power:

• Enterprise Single Sign-On
• Workforce identity platforms
• SaaS integrations
• Government systems
• Educational federations
• Legacy applications that are still very much alive

Many organizations operate environments where OAuth, OpenID Connect, and SAML coexist. Troubleshooting those ecosystems often requires jumping between multiple tools and manually decoding protocol messages.

The OAuth2/OIDC Debugger was built to simplify identity troubleshooting, and SAML support is a natural extension of that mission.

New SAML Features

Decode SAML AuthnRequests

Ever received a SAMLRequest parameter and wondered what was actually being sent?

The debugger can decode AuthnRequests and display the underlying XML in a readable format, making it easier to inspect:

• Issuer values
• Assertion Consumer Service URLs
• Destination URLs
• NameID policies
• Requested authentication contexts
• Request identifiers

No more manually copying compressed Base64 blobs into random online decoders.

Decode SAML Responses

When a login fails, the answer is often hiding somewhere inside a SAMLResponse.

The debugger allows you to decode and inspect SAML responses, including:

• Assertions
• Attributes
• NameID values
• Audience restrictions
• Conditions
• Issuers
• Status codes

This makes it much easier to identify federation issues and configuration mismatches.

Generate AuthnRequests

Need to test a Service Provider integration?

The debugger can generate SAML AuthnRequests, allowing you to quickly create requests for testing and validation scenarios without building custom tooling or a functioning app (Service Provider).

Generate Service Provider Metadata

Metadata exchange is one of the most common steps in a SAML integration.

The debugger can generate Service Provider metadata documents that can be shared with Identity Providers during setup and testing.

XML Pretty-Printing

Raw SAML XML is technically readable.

In the same sense that a wiring diagram for a nuclear power plant is technically readable.

The debugger automatically formats XML into a cleaner, easier-to-understand structure so you can focus on troubleshooting instead of deciphering indentation.

Support for Common SAML Bindings

HTTP-Redirect Binding

The debugger supports inspection and troubleshooting of SAML messages transmitted using the HTTP-Redirect binding, including handling compressed requests commonly used by Service Providers.

HTTP-POST Binding

SAML responses frequently arrive through the HTTP-POST binding.

The debugger can process and analyze these messages, helping you inspect the contents without manually decoding every step.

SAML / HTTP-Artifact Binding

The SAML Artifact Binding is a SAML 2.0 protocol binding that avoids sending the full SAML message through the user’s browser. Instead, the Identity Provider (IdP) sends a small reference value called an artifact to the Service Provider (SP), typically via the browser, and the SP then retrieves the actual SAML message directly from the IdP over a secure back-channel SOAP connection. This approach reduces the exposure of assertions in browser traffic, avoids URL length limitations, and can provide additional security by ensuring sensitive assertions are exchanged server-to-server rather than passing through the user’s browser.

While Artifact Binding offers security and privacy advantages over HTTP-Redirect and HTTP-POST bindings, it is less commonly implemented because it requires additional infrastructure, SOAP support, and direct network connectivity between federation partners.

Signature Validation and Generation

Cryptographic signatures are often at the center of SAML troubleshooting.

The debugger includes tools for:

Signature Validation

Verify XML signatures and identify issues involving:

• Invalid signatures
• Certificate mismatches
• Incorrect signing configurations
• Trust problems

XML Signature Generation

Generate XML signatures for testing and validation scenarios, making it easier to build and verify SAML integrations.

Federation Troubleshooting Tools

The hardest part of federation is often answering the question_, “Why are these two systems refusing to trust each other?”_

The new SAML functionality includes tools designed specifically for federation troubleshooting, helping identify common issues involving:

• Metadata configuration
• Issuer mismatches
• Assertion Consumer Service URLs
• Certificates
• Signing requirements
• Protocol binding differences
• Trust configuration errors

In other words, the sorts of problems that tend to consume entire afternoons.

One Place for Identity Troubleshooting

Modern identity environments rarely use a single protocol.

Many organizations simultaneously support:

• OAuth 2.x
• OpenID Connect
• SAML 2.0

Identity teams often need to move between these protocols while troubleshooting authentication and federation issues.

By adding SAML 2.0 support, IDP Tools continues its goal of providing a centralized toolkit for understanding how identity systems communicate and where they sometimes go wrong.

Try It Today

All SAML functionality is available now on IDPTools.

Whether you’re debugging a failed federation, inspecting a SAMLResponse, validating signatures, generating metadata, or simply trying to understand what an Identity Provider is sending back, the new SAML tools are designed to make the process faster and less frustrating.

Because life is too short to manually decode compressed, base64-encoded XML every time a login breaks.

Explore the new SAML tools at IDP Tools and let me know what additional identity and federation capabilities you’d like to see next.