Authn.tech
Home
  • SAML 2.0
  • OAuth 2.0
  • OIDC
  • WebAuthn / Passkey
  • MFA / TOTP
  • LDAP
  • All Tools
  • JWT Decode
  • JWT Sign
  • JWK Gen
  • JWK → PEM
  • PEM → JWK
  • PKCE Gen
  • OIDC Discovery
  • TOTP
  • WebAuthn
  • SAML Codec
  • SAML Metadata
  • SAML Response
  • X.509 Cert
  • PEM Inspect
  • Base64URL
  • LDAP Filter
  • Overview & Roles
  • OIDC Mock
  • SAML Mock
  • Mail Server
  • LDAP Directory
  • OIDC Login Demo
  • SAML Login Demo
  • 简体中文
  • English
  • Deutsch
GitHub
Home
  • SAML 2.0
  • OAuth 2.0
  • OIDC
  • WebAuthn / Passkey
  • MFA / TOTP
  • LDAP
  • All Tools
  • JWT Decode
  • JWT Sign
  • JWK Gen
  • JWK → PEM
  • PEM → JWK
  • PKCE Gen
  • OIDC Discovery
  • TOTP
  • WebAuthn
  • SAML Codec
  • SAML Metadata
  • SAML Response
  • X.509 Cert
  • PEM Inspect
  • Base64URL
  • LDAP Filter
  • Overview & Roles
  • OIDC Mock
  • SAML Mock
  • Mail Server
  • LDAP Directory
  • OIDC Login Demo
  • SAML Login Demo
  • 简体中文
  • English
  • Deutsch
GitHub
  • SAML 2.0

    • SAML 2.0 Overview
    • Core Concepts
    • Typical Flows
    • Typical Parameters and Message Reference

Typical Parameters and Message Reference

This page is a quick reference organized by message type. Flow context is in Typical Flows, concept explanations are in Core Concepts.

AuthnRequest Key Elements and Attributes

Element/AttributeRequiredDescription
IDYesRequest unique identifier (NCName, cannot start with digit, convention adds _ prefix). SP must retain this to compare with Response's InResponseTo
VersionYesFixed as 2.0
IssueInstantYesIssue time, UTC ISO 8601 (e.g., 2026-07-03T08:29:55Z). IdP will reject requests with excessive time deviation
DestinationRecommendedIdP SSO endpoint URL. When message is signed, IdP must validate it matches the actual reception address
AssertionConsumerServiceURLRecommendedExpected SP ACS address to receive Response. IdP must verify it's within the registered SP Metadata range, otherwise can be exploited to steal Assertion
ProtocolBindingOptionalExpected Response Binding, typically urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
AssertionConsumerServiceIndexOptionalUse index instead of explicit URL (mutually exclusive)
ForceAuthnOptionalWhen true, require IdP to ignore existing sessions and force re-authentication (commonly used for step-up before sensitive operations)
IsPassiveOptionalWhen true, prohibit IdP from interacting with user; return NoPassive error if no session exists (used for silent login status probing)
<Issuer>YesSP Entity ID
<NameIDPolicy>OptionalFormat declares expected NameID format; AllowCreate="true" allows IdP to create identifiers for new users
<RequestedAuthnContext>OptionalRequired authentication strength, containing one or more <AuthnContextClassRef>; Comparison takes exact/minimum/maximum/better
<Scoping> / <ProxyCount>OptionalProxy/intermediary IdP scenarios, rarely used

Response and Assertion Structure

Response Outer Layer

Element/AttributeDescription
ID / Version / IssueInstantSame as above; ID used for logging correlation and replay prevention
InResponseToCorresponds to AuthnRequest ID. Does not exist in IdP-initiated flow
DestinationSP ACS URL; SP must validate it matches itself
<Issuer>IdP Entity ID
<samlp:Status>Processing result; see StatusCode table below
<saml:Assertion> or <saml:EncryptedAssertion>Assertion on success (0..n, typically exactly 1 in Web SSO); may be absent on failure

Status

ElementDescription
<StatusCode Value="...">Top-level status code (see table below), can be nested with secondary StatusCode for refinement
<StatusMessage>Human-readable information; check this first for troubleshooting
<StatusDetail>Machine-readable supplementary details

Subject and SubjectConfirmation (bearer)

Element/AttributeDescription
<NameID>Subject identifier; Format see list below
<SubjectConfirmation Method>Web SSO fixed to urn:oasis:names:tc:SAML:2.0:cm:bearer ("possession proves identity")
SubjectConfirmationData/@RecipientMust equal the ACS URL receiving this Assertion; SP must validate
SubjectConfirmationData/@NotOnOrAfterExpiration time of bearer confirmation; must validate; note bearer scenario does not contain NotBefore
SubjectConfirmationData/@InResponseToSame semantics as Response outer layer; SP-initiated must match

Conditions

Element/AttributeDescription
NotBefore / NotOnOrAfterAssertion overall validity window (left-closed, right-open); allow 2–3 minutes clock skew tolerance when validating
<AudienceRestriction>/<Audience>Audience; must contain this SP's Entity ID (not ACS URL)
<OneTimeUse>When present, SP must ensure single use

AuthnStatement

Attribute/ElementDescription
AuthnInstantActual authentication time (may be much earlier than Assertion issue time, especially when IdP session is reused)
SessionIndexIdP-side session index; SP should save this; fill it back in SLO
SessionNotOnOrAfterIdP's recommended SP session upper limit; SP should respect
<AuthnContextClassRef>Authentication method; common: ...ac:classes:PasswordProtectedTransport (HTTPS password), ...ac:classes:Password, ...ac:classes:TimeSyncToken, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified. SP should validate this value when enforcing MFA

AttributeStatement

Attribute/ElementDescription
<Attribute Name>Attribute name. May be short form (mail) or URI/OID style (urn:oid:0.9.2342.19200300.100.1.3, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress); match based on what the other party actually sends
NameFormat...attrname-format:basic / :uri / :unspecified
FriendlyNameHuman-readable alias, not used in matching logic
<AttributeValue>Can be multi-valued (e.g., multiple groups); note xsi:type may be present

Common StatusCode

Top-level codes (Value prefix all urn:oasis:names:tc:SAML:2.0:status:):

ValueMeaning
SuccessSuccess
RequesterRequestor (SP) error—malformed request, unaccepted parameters
ResponderResponder (IdP) error—IdP internal reason for inability to process
VersionMismatchProtocol version mismatch

Common secondary codes (nested within top-level code):

Value (same prefix)Meaning
AuthnFailedAuthentication failed (wrong password, user canceled, etc.)
InvalidNameIDPolicyIdP cannot satisfy the requested NameID Format
NoAuthnContextCannot satisfy RequestedAuthnContext strength requirement
NoPassiveIsPassive=true but user has no session; interaction needed
RequestDeniedPeer understands request but refuses to execute (often due to trust configuration mismatch)
UnknownPrincipalCannot identify the subject
UnsupportedBindingDoes not support the Binding specified in request
PartialLogoutSLO could not notify all participants
ProxyCountExceededProxy hops exceeded limit

NameID Format List

Format URIDescription
urn:oasis:names:tc:SAML:1.1:nameid-format:unspecifiedUnspecified; semantics agreed offline between parties (compatibility fallback, use cautiously)
urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddressEmail format
urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectNameX.509 certificate subject name
urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedNameDOMAIN\user form
urn:oasis:names:tc:SAML:2.0:nameid-format:kerberosKerberos principal
urn:oasis:names:tc:SAML:2.0:nameid-format:entityIdentifies the SAML entity itself (default for Issuer element)
urn:oasis:names:tc:SAML:2.0:nameid-format:persistentPersistent pseudonym: opaque, stable for a single SP, different across SPs; recommended as account association primary key
urn:oasis:names:tc:SAML:2.0:nameid-format:transientTransient identifier, valid only for this session

Binding Parameters

HTTP-Redirect Binding (URL Query Parameters)

ParameterDescription
SAMLRequest / SAMLResponseMessage body: XML → raw deflate → Base64 → URL-encode (encoding details in Typical Flows)
RelayStateOpaque state, ≤80 bytes; recipient must echo unchanged
SigAlgSignature algorithm URI, e.g., http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
SignatureSignature over string SAMLRequest(or SAMLResponse)=..&RelayState=..&SigAlg=.. (URL-encoded form, fixed order, only parameters actually present), Base64-encoded then URL-encoded

HTTP-POST Binding (Form Fields)

FieldDescription
SAMLRequest / SAMLResponseXML → Base64 (no deflate), submitted via browser auto-form POST
RelayStateSame as above

Signature in POST Binding is embedded XML <ds:Signature>, not a separate field.

Metadata Key Elements

Common

Element/AttributeDescription
<EntityDescriptor entityID>Root element; entityID is the entity identifier
validUntil / cacheDurationMetadata validity/cache duration; consumer should periodically refresh
<KeyDescriptor use="signing">Signature verification certificate (contains <ds:X509Certificate>); omitting use means signing/encryption dual-use
<KeyDescriptor use="encryption">Encryption public key certificate

IdP Side (<IDPSSODescriptor>)

Element/AttributeDescription
protocolSupportEnumerationFixed to contain urn:oasis:names:tc:SAML:2.0:protocol
<SingleSignOnService Binding Location>SSO endpoint; one per Binding
<SingleLogoutService Binding Location>SLO endpoint
WantAuthnRequestsSignedWhether to require SP to sign AuthnRequest

SP Side (<SPSSODescriptor>)

Element/AttributeDescription
<AssertionConsumerService Binding Location index isDefault>ACS endpoint, can be multiple; index for reference by AssertionConsumerServiceIndex
<SingleLogoutService>SP's SLO endpoint
AuthnRequestsSignedSP commits to signing AuthnRequest
WantAssertionsSignedSP requires Assertion be signed
<NameIDFormat>List of NameID formats SP supports/expects

Troubleshooting Quick Reference

SymptomCommon Causes
IdP reports unable to parse SAMLRequestRedirect Binding encoding order wrong (missing deflate / zlib header / URL-safe Base64 / double URL-encoding)
Signature validation failedPeer certificate rotated but local Metadata not updated; signature/digest algorithm rejected (e.g., SHA-1 disabled); Redirect signature string concatenation order or URL encoding wrong; XML modified by middleware (formatting, charset)
Invalid Destination / RecipientACS or SSO endpoint URL mismatch: http vs https, port, trailing slash, reverse proxy rewrote Host header
Audience validation failureSP Entity ID misconfigured (common: filled ACS URL as Entity ID in IdP)
Response expired / not yet validClock offset between parties; SP not configured with clock skew tolerance; user lingered on IdP login page before submitting
InResponseTo mismatchSP cluster doesn't share request ID storage (node A issued, node B received); user browser back/refresh consumed ID; IdP-initiated Response sent to SP that only accepts SP-initiated
Successful login but no attributesIdP didn't configure Attribute Release policy; attribute name mismatch (short name vs URI/OID); Assertion encrypted and SP didn't decrypt before reading
Redirect loop (SP↔IdP bouncing)SP session Cookie not set (SameSite/Secure/domain config wrong); SP always thinks not logged in
IdP reports unknown/invalid SPAuthnRequest Issuer doesn't match IdP-registered Entity ID
Other SPs still online after SLOOne hop in SLO chain failed (check if PartialLogout returned); SP didn't save SessionIndex; browser blocked third-party cookies
Fails only on IE/certain proxiesURL too long (Redirect Binding message oversized); switch to POST Binding for AuthnRequest

Troubleshooting Tools

Browser plugin SAML-tracer (Firefox/Chrome) can directly decode captured SAMLRequest/SAMLResponse. For backend investigation, Base64-decode and examine the XML source, then cross-check with this page's tables item by item. The vast majority of issues stem from URL/Entity ID/certificate configuration inconsistencies.

Last updated: 7/6/26, 7:49 AM
Contributors: linux, Claude Opus 4.8
Prev
Typical Flows