SAML Request Decoder

SAML (Security Assertion Markup Language) is an XML-based SSO standard used primarily in enterprise environments. It allows an Identity Provider (IdP like Okta, Azure AD, ADFS) to authenticate a user and pass their identity to a Service Provider (SP — your app). SAML is widely used for enterprise SSO. For new apps, consider OIDC/OAuth2 instead — it's simpler and more developer-friendly. SAML is still required for integration with legacy enterprise systems.

SAMLRequest is sent from the Service Provider (your app) to the Identity Provider to initiate authentication — it's an AuthnRequest XML document. SAMLResponse is sent from the Identity Provider back to the Service Provider after the user authenticates — it contains assertions (user identity, attributes, session info). Both are Base64-encoded XML, usually URL-encoded in the query string (redirect binding) or sent as form fields (POST binding).

When your app generates a SAMLRequest, it embeds an ID. The IdP's SAMLResponse includes InResponseTo with that ID to prevent replay attacks. If they don't match, it means either: (1) the response is for a different request (clock skew or session mismatch), (2) someone is replaying an old response, or (3) your SP lost track of the original request ID. Fix: ensure your app correctly stores and retrieves the request ID, and check NTP time sync between SP and IdP (allow ±5 minutes tolerance).

Open Chrome DevTools → Network tab → filter by 'saml'. Look for POST requests to your app's ACS (Assertion Consumer Service) URL. In the request payload, find SAMLResponse form field. Copy the value. In GET requests (redirect binding), the SAMLRequest appears in the URL query string. Alternatively, use the SAML Chrome extension or Firefox SAML DevTools extension which automatically decode SAML messages as you browse.

NameID is the primary identifier for the authenticated user — often an email address, username, or persistent opaque ID. Attributes are additional claims about the user sent in the assertion: email, displayName, groups, department, etc. The exact attribute names vary by IdP. In Okta they might be 'email' and 'firstName'; in Azure AD they use URN format like 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'. Map these attributes in your SP configuration to standardize them.

SAML responses are signed with the IdP's private key and verified using their public certificate. Verification fails when: (1) you're using the wrong IdP certificate — download the current certificate from your IdP's metadata URL, (2) the certificate has expired — IdPs rotate certificates periodically, (3) the XML was modified after signing — some proxies or middleware corrupt the response. Check your SP's stored IdP certificate matches what the IdP is currently using.