Instantly decode and validate SAML assertions, OIDC tokens, and metadata to eliminate authentication errors and security risks.
Select the protocol type and paste your SAML response or OIDC token for validation.
Analysis is performed entirely in your browser. No data is transmitted.
Conceptual calculation: For SAML, the tool detects Base64 encoding, decodes the response, parses the XML DOM, and extracts assertion attributes. For signature validation, it requires the IdP certificate and verifies the XML digital signature. For OIDC, it decodes the JWT segments, parses the payload JSON, and checks standard claims like exp, iat, iss, and aud.
Key assumptions: SAML responses are assumed to follow the SAML 2.0 specification. OIDC tokens are assumed to be valid JWT format. Timestamps are assumed to be Unix epoch seconds.
Limitations and edge cases: Browser-based signature validation for SAML requires the exact certificate used by the IdP. Encrypted SAML assertions cannot be decoded without the SP private key. OIDC tokens signed with RS256/ES256 algorithms cannot be verified in the browser without the JWKS endpoint.
Select the protocol type (SAML or OIDC) and paste your authentication response or token. For SAML, you can paste raw XML or Base64-encoded responses. For OIDC, paste the ID token JWT.
Provide the expected SP Entity ID or Audience for audience validation. For SAML signature verification, paste the IdP public certificate in PEM format.
The tool parses the input based on the selected protocol. For SAML, it decodes Base64 if needed, parses the XML, and extracts assertion attributes. For OIDC, it splits the JWT, decodes the Base64URL payload, and parses the claims JSON.
Timestamp validation compares NotBefore and NotOnOrAfter values against the current time. Audience validation checks that the response audience matches the expected value.
Success cards indicate valid fields. Warning cards indicate potential issues that may not block authentication. Error cards indicate validation failures that will cause SSO to reject the response.
The troubleshooting section provides specific guidance for resolving common errors, including which SAML assertions or OIDC claims need correction.
This tool provides debugging information for SSO configurations. It cannot replicate the exact behavior of all IdP and SP implementations. Use it as a first-pass diagnostic, but always test with actual SSO flows in your environment.
Single Sign-On (SSO) protocols enable users to authenticate once and gain access to multiple applications. SAML 2.0 and OpenID Connect (OIDC) are the two dominant standards in enterprise identity federation. Understanding their differences helps choose the right protocol for your use case.
Security Assertion Markup Language (SAML) 2.0 is an XML-based standard for exchanging authentication and authorization data between parties. The SAML flow involves an Identity Provider (IdP) authenticating a user and issuing a SAML Assertion, which the Service Provider (SP) receives and trusts.
SAML assertions contain claims about the user (NameID, attributes) and metadata (issuer, timestamps, conditions). The SP validates the assertion's signature, issuer, audience, and timestamps before granting access.
OpenID Connect (OIDC) is an OAuth 2.0-based identity layer built on JSON. Unlike SAML's XML format, OIDC uses JSON Web Tokens (JWTs), making it easier to parse in modern web applications. OIDC is more common in mobile apps and modern cloud-native applications.
| Aspect | SAML 2.0 | OpenID Connect |
|---|---|---|
| Format | XML | JSON / JWT |
| Primary Use | Enterprise SSO | Consumer and mobile apps |
| Complexity | Higher (XML parsing) | Lower (JSON parsing) |
| Token Type | SAML Assertion | ID Token (JWT) |
| Session Management | SP-driven | Built-in (id_token_hint) |
Understanding common SAML errors helps diagnose authentication failures quickly.
A signature validation failure indicates the assertion was modified after signing, or the wrong certificate was used. Verify you have the current IdP certificate and that the SP is configured to trust it. Certificate rotation without SP updates is a common cause.
The assertion's Audience element must match the SP's Entity ID exactly. A mismatch indicates the assertion was intended for a different SP or the SP configuration is incorrect.
Conditions/NotOnOrAfter errors indicate the assertion has expired. Check server clocks for synchronization. Assertions with future NotBefore times indicate clock skew between IdP and SP.
The token's iss claim must exactly match the expected issuer URL. Query parameters, trailing slashes, and case sensitivity all matter. Verify the issuer configuration matches the OIDC discovery document.
The token's aud claim must include the client's registered identifier. For single-audience tokens, aud is a string. For multiple audiences, aud is an array.
The exp claim indicates expiration. ID tokens typically have short lifetimes (15-60 minutes). If exp is in the past, the token has expired and a new one must be obtained.
Browser-based signature verification for OIDC tokens signed with RS256 or ES256 requires access to the IdP's JWKS (JSON Web Key Set) endpoint. This tool performs basic decoding and validation but cannot verify asymmetric signatures without the public key.
For production SSO testing, use dedicated libraries that properly implement signature verification, key caching, and algorithm validation according to OIDC specifications.
Verify you have the correct IdP certificate configured in your SP. Check that the certificate hasn't expired or been rotated. Ensure the XML was not modified after signing. Use this tool to validate the signature with the current certificate.
Common extractions include: NameID (user identifier), attributes (email, name, groups), Issuer, Conditions (timestamps, audience), and signature status. The tool displays all parseable elements in a structured format.
Common causes: expired token (exp in the past), issuer mismatch, audience mismatch, or malformed JWT structure. Check that the issuer and audience values match your OIDC provider configuration exactly.
No. All processing happens entirely in your browser. No SAML responses, OIDC tokens, certificates, or validation results are transmitted or stored externally.
Paste the SAML response in the tool and examine the Decoded Attributes section. Verify that required attributes like email, name, and groups are present and contain expected values. Compare against your SP's expected attribute mapping configuration.
This tool can decode and validate the claims structure, but browser-based RS256 signature verification requires the IdP's public key or JWKS endpoint. Use the tool to inspect claims while implementing proper signature verification in your application backend.
Decode and inspect JWT tokens to verify payloads, headers, and signature status.
Create and sign custom JSON Web Tokens for API authentication testing.
Visualize OAuth 2.0 authentication flows with sequence diagrams and security recommendations.
Parse and inspect X.509 certificates to view subject, issuer, and validity dates.
Generate secure API tokens with custom permissions and TTL for granular access control.
Analyze session tokens and JWTs for security properties and vulnerability detection.
Generate SAML 2.0 SP metadata XML for Service Provider configuration.
Create strong, random passwords with customizable character sets and length.