What is NameID in a SAML assertion?

NameID (Name Identifier) is the field in a SAML assertion that identifies the user — SAML's equivalent of a username. Depending on how your IdP is configured, it may be an email address, a persistent opaque identifier, or a temporary session identifier. When this tool lists NameID in its summary, it is showing the value the IdP used to identify the user to the SP.

What is IdP metadata?

Identity provider metadata is a standard XML document (a SAML 2.0 EntityDescriptor ) that a provider publishes so service providers can configure federation automatically instead of typing values by hand. It contains: entityID — the provider's unique, stable identifier SingleSignOnService — the login endpoint URLs, one per binding (typically HTTP-POST and HTTP-Redirect) SingleLogoutService — the logout endpoints NameIDFormat — the identifier format the IdP is willing to emit KeyDescriptor use="signing" — the X.509 certificate used to sign assertions Typical metadata URLs: ADFS: https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml Okta: https://{tenant}.okta.com/app/{app}/{key}/sso/saml/metadata Entra ID / Azure AD: https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml Because IdP metadata carries the signing certificate, you should always import it from the HTTPS URL the provider publishes (or a copy you downloaded from it) — never from a third party.

SAML Assertion Decoder Online

Turn Base64 (or DEFLATE-compressed) SAML responses from ADFS, Okta, or Keycloak into readable XML to debug SSO failures.

Input is Base64Deflated (Redirect binding)

Input

Decoded XML

—

What is SAML Assertion Decoder?

SAML (Security Assertion Markup Language) is the XML format behind enterprise Single Sign-On (SSO). When you log in to a company app through ADFS, Okta, Entra ID, or Keycloak, the identity system sends the app a SAML assertion — a signed document stating who you are (email, name, roles) and when that proof expires. Two parties are always involved: the Identity Provider (IdP) is the system that verifies your login (ADFS, Okta, Entra ID); the Service Provider (SP) is the app that consumes the assertion.

XML assertions carry user identity, attributes, and authorization decisions from the IdP to the SP.

Two bindings — HTTP POST (Base64 encoded) and HTTP Redirect (DEFLATE compressed + Base64 encoded).

IdP metadata is a standard XML document (EntityDescriptor) that publishes the entityID, SSO/SLO endpoints, NameIDFormat, and signing certificates for automated federation setup.

Validity windows — every assertion carries NotBefore / NotOnOrAfter conditions that define the exact instant the proof becomes valid and when it expires.

Widely used in enterprise — ADFS, Azure AD / Entra ID, Okta, OneLogin, and PingFederate all speak SAML natively.

No JavaScript involved — unlike OIDC, SAML assertions are server-to-server XML documents, not browser-based tokens.

Zero-Server Tool Data Guarantee

All decoding and parsing happens entirely in your browser. SAML assertions are never sent to any server for processing. The only optional network request is the metadata URL you explicitly ask the tool to fetch, which is proxied through the site's own server purely to bypass CORS blocks — nothing is stored or logged.

How to Use

Paste SAML Content

Input your SAMLResponse or raw XML. You can toggle Base64 decoding and DEFLATE inflation depending on the binding used.

Configure Options

Check 'Input is Base64' for standard POST bindings, or 'Deflated' for Redirect bindings commonly used in SSO flows.

Inspect Results

View the decoded XML and a summary of key fields like Issuer, NameID, and user attributes automatically extracted from the assertion.

Import IdP Metadata

Switch to the IdP Metadata tab, paste an EntityDescriptor XML or its URL, and get entityID, SSO/SLO endpoints, NameIDFormat, and signing certificates.

Common Use Cases

SSO Debugging

Paste a SAMLResponse from your browser's developer tools to quickly inspect what the IdP is sending to your service provider.

Attribute Mapping

View all user attributes in the assertion to verify correct attribute mapping between your IdP and application.

Integration Testing

Decode assertions during SAML integration setup to confirm the user identifier (NameID), issuer URL, and recipient endpoint.

Security Auditing

Inspect raw SAML XML during a security review to check for missing signatures, weak conditions, or overly broad audience restrictions.

Federation Setup

Import the IdP's EntityDescriptor metadata to copy the exact entityID, SSO endpoint, NameIDFormat, and signing certificate into your SP configuration.

Expiry Auditing

Watch the live validity indicator to confirm an assertion is currently valid, not yet valid, or expired — essential when debugging clock-skew and replay issues.

Certificate Rotation

Parse IdP metadata to compare signing-certificate fingerprints before and after a certificate rollover in ADFS, Okta, or Entra ID.

Implementation Examples

XMLExample SAML Assertion Structure

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="_abc123" IssueInstant="2024-01-15T09:30:00Z" Version="2.0">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
      user@example.com
    </saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2024-01-15T09:25:00Z"
      NotOnOrAfter="2024-01-15T09:35:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://myapp.example.com</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AttributeStatement>
    <saml:Attribute Name="role">
      <saml:AttributeValue>admin</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

SAML vs OIDC

Feature	SAML 2.0	OpenID Connect
Data format	XML	JSON / JWT
Transport	HTTP POST or Redirect	HTTP (REST APIs)
Primary use	Enterprise SSO	Web & mobile apps
Token format	XML assertion	JWT (ID Token)
Complexity	High (XML signing, certs)	Lower (simpler crypto)
Mobile support	Poor (browser redirects)	Native / OAuth2 flows
Adoption trend	Legacy / enterprise	Modern / growing
Discovery	Metadata XML files	Well-known endpoints

Production Best Practices & Security

Always verify XML signatures — this tool is for decoding only; never trust an unverified assertion in production. Why:Without signature verification, an attacker can forge or modify SAML assertions to impersonate any user. XML digital signatures prove the assertion was created by the trusted IdP and hasn't been tampered with.

Validate the issuer (IdP) — ensure the assertion came from a trusted Identity Provider you've pre-configured. Why:An attacker can craft a validly signed SAML assertion from a different IdP. If your application doesn't check the issuer, it will accept assertions from any IdP, including malicious ones set up by attackers.

Import metadata, don't hand-type endpoints — use the published EntityDescriptor URL or XML so SSO/SLO endpoints and certificates match exactly. Why:Typed endpoints drift out of sync with the real IdP and silently break federation; metadata is the single source of truth the IdP controls.

Check NotBefore and NotOnOrAfter — reject assertions outside the valid time window to prevent replay attacks. Why:Without time validation, an attacker can capture a legitimate assertion and replay it hours or days later to gain unauthorized access. The time window limits how long a captured assertion remains valid.

Enforce audience restriction — verify the AssertionConsumerServiceURL matches your SP's endpoint. Why:Without audience restriction, an attacker can take a valid assertion meant for one service provider and replay it against a different service, gaining unauthorized access to a system the user never intended to authenticate to.

Protect against XML injection — use a hardened XML parser and disable external entity resolution (XXE). Why:XXE attacks allow an attacker to include external file references in the XML, potentially reading sensitive files from your server or causing server-side request forgery. Disabling entity resolution eliminates this attack vector.

Use encrypted assertions when possible — SAML supports encrypting the entire assertion to prevent attribute leakage. Why:Even signed assertions travel in base64-encoded XML that can be decoded by anyone who intercepts the HTTP request. Encryption ensures that only the intended Service Provider can read the user's identity attributes and authorization data.

Frequently Asked Questions

In your Identity Provider admin console (ADFS or Okta), locate the SAML response for the service provider. Copy the Base64-encoded assertion from your browser's developer tools network tab — look for the SAMLResponse parameter in the POST form data.

Paste it into the tool. Leave the 'Deflated' checkbox unchecked for HTTP POST binding, or check it for HTTP Redirect binding.

The tool will decode the XML and display the assertion structure, attribute statements, and authentication context for inspection.

No. The SAML Decoder is designed for decoding and inspection only. It decompresses (DEFLATE), Base64-decodes, and pretty-prints the XML content so you can read the assertion structure, attribute statements, and conditions.

It does not perform XML signature verification (xmldsig). To verify a SAML response's signature, you would need the IdP's X.509 certificate and a dedicated XML security library.

This tool is intended for debugging and learning, not production-level assertion validation.

In the SAML HTTP Redirect binding (the most common SSO flow), your identity provider encodes the XML assertion by first DEFLATE-compressing it (using zlib's raw deflate algorithm) and then Base64-encoding it to fit in a URL query parameter.

When you check the 'Deflated' box, the SAML tool reverses this process: it Base64-decodes the input, inflates (decompresses) the result, and formats the XML for readability.

If your SAML response came from an HTTP POST binding, it won't be deflated — leave the option unchecked.

Every SAML assertion contains a <saml:Conditions> element with two timestamps:

NotBefore — the moment the assertion becomes valid. Rejecting it earlier prevents a provider from issuing back-dated proofs.
NotOnOrAfter — the moment the assertion expires. SAML service providers must reject assertions at or after this instant.

This window limits how long a captured assertion can be replayed. The tool's live badge compares both timestamps against your current clock every second and reports Valid now, Not yet valid, or Expired — plus how long remains (or how long until it becomes valid). In production, libraries also apply a small clock skew allowance (typically 1–5 minutes) on both sides so that legitimate assertions are not rejected because two servers' clocks differ.

Yes. SAML decoding happens entirely in your browser — both the Base64 decoding and DEFLATE decompression are performed locally.

SAML assertions often contain sensitive PII like email, roles, and authentication context. None of that data is transmitted to any server. No decoded assertion data is stored or logged.

The only optional network request is the metadata URL you ask the tool to fetch, which is proxied through the site's own server purely to bypass cross-origin (CORS) blocks. Only the URL you enter leaves your browser; the public XML is returned to you and nothing is stored or logged.

SAML uses XML for its assertion format and is primarily used in enterprise SSO environments with systems like ADFS, Okta, and Azure AD. It's been around since 2002 and is deeply embedded in legacy enterprise infrastructure.

OIDC is built on OAuth 2.0, uses JSON (smaller payloads, simpler parsing), and is designed for modern applications including mobile apps and single-page applications.

For new projects, OIDC is generally the better choice. Use SAML only when integrating with legacy enterprise federation systems that require it.

An assertion is the package of proof SAML uses to log you in. When your identity provider (IdP) verifies your credentials, it builds an XML assertion that states who you are (email, name, roles), which app it's intended for (the audience), and when the proof expires.

In this tool, what you paste — often a form field labeled SAMLResponse — is a Base64-encoded version of that assertion. Decoding it turns it back into readable XML.

These are the two parties in every SAML exchange. The Identity Provider (IdP) is the system that verifies who you are — Okta, ADFS, and Azure AD are common examples. The Service Provider (SP) is the application you are logging into, such as Salesforce or an internal portal.

SP-initiated SSO starts when you visit the app first; it then redirects you to the IdP to log in. IdP-initiated SSO starts at the IdP (for example, an Okta dashboard) — you click an app icon and the assertion is sent to the app without visiting it first.

Identity provider metadata is a standard XML document (a SAML 2.0 EntityDescriptor) that a provider publishes so service providers can configure federation automatically instead of typing values by hand. It contains:

entityID — the provider's unique, stable identifier
SingleSignOnService — the login endpoint URLs, one per binding (typically HTTP-POST and HTTP-Redirect)
SingleLogoutService — the logout endpoints
NameIDFormat — the identifier format the IdP is willing to emit
KeyDescriptor use="signing" — the X.509 certificate used to sign assertions

Typical metadata URLs:

ADFS: https://adfs.example.com/FederationMetadata/2007-06/FederationMetadata.xml
Okta: https://{tenant}.okta.com/app/{app}/{key}/sso/saml/metadata
Entra ID / Azure AD: https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml

Because IdP metadata carries the signing certificate, you should always import it from the HTTPS URL the provider publishes (or a copy you downloaded from it) — never from a third party.