Encrypt Online
Theme

Encoding & Transport

Fix SAML Audience and ACS URL Mismatches

Fix SAML audience and ACS URL mismatches by comparing issuer, entity ID, recipient, request IDs, and timing. Includes a tested response and field comparisons.

Encrypt Online Editorial Team5 min read
Encrypt Online guide cover on a matte sky background with the headline Fix SAML mismatches and the established SAML Decoder glyph.

An audience error usually means the assertion names a different service provider. An ACS or recipient error points to the endpoint receiving the response. Those values can look alike while serving different roles.

Decode the response in the SAML Decoder, then compare its fields with the settings for the application that rejected it. A response can be well-formed XML and still address the wrong application or callback URL.

Match each field to its configuration

Response field Compare with Example
Response and assertion Issuer The identity provider's entity ID https://idp.example.test/metadata
Audience inside AudienceRestriction The service provider's entity ID https://sp.example.test/metadata
Response Destination The response's intended ACS endpoint https://sp.example.test/saml/acs
Bearer subject-confirmation Recipient The expected ACS endpoint https://sp.example.test/saml/acs
InResponseTo The ID of the corresponding authentication request _request-example-1

The audience identifies the application. The assertion consumer service (ACS) URL identifies its receiving endpoint. Copying the ACS URL into an audience field can therefore produce a valid-looking URL with the wrong meaning.

Tip: Compare the values emitted in the failing exchange with that application's active configuration. A test application, a production application, and an old identity-provider registration may each have different entity IDs or ACS URLs.

Decode a complete test response

Paste this unsigned synthetic response into the workbench using Raw XML. Its entity IDs, ACS URL, and request ID match the values used by the tool's built-in response example. The broad 2020-2099 conditions keep this fixture useful for field comparisons; they are not suggested lifetimes for a live login.

XML
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="_response-guide-1" Version="2.0"
  IssueInstant="2026-01-01T00:00:00Z"
  Destination="https://sp.example.test/saml/acs"
  InResponseTo="_request-example-1">
  <saml:Issuer>https://idp.example.test/metadata</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion ID="_assertion-guide-1" Version="2.0"
    IssueInstant="2026-01-01T00:00:00Z">
    <saml:Issuer>https://idp.example.test/metadata</saml:Issuer>
    <saml:Subject>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData InResponseTo="_request-example-1"
          Recipient="https://sp.example.test/saml/acs"
          NotOnOrAfter="2099-01-01T00:00:00Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2020-01-01T00:00:00Z"
      NotOnOrAfter="2099-01-01T00:00:00Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://sp.example.test/metadata</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
  </saml:Assertion>
</samlp:Response>

Expand Optional exact mismatch checks and enter these expectations above Decode and inspect SAML:

Workbench expectation Value
Expected issuer https://idp.example.test/metadata
Expected audience / SP entity ID https://sp.example.test/metadata
Expected ACS / recipient URL https://sp.example.test/saml/acs
Expected request ID _request-example-1

All four comparisons match. The sample has no signature. The workbench decodes and compares fields and reports signature markers; XML and Redirect signature verification remain separate checks in the identity provider or service provider.

Reproduce an audience mismatch

Leave the XML unchanged and set Expected audience to https://sp.example.test/metadata/, with a trailing slash. The audience comparison changes to a mismatch, while issuer, ACS, and request ID still match.

The workbench compares these identifiers exactly. Case, path, scheme, port, and trailing slash differences stay visible. Check the provider's expected entity ID and its comparison rules rather than trimming or rewriting values until the diagnostic looks successful.

If the application expects an entity ID that differs from the assertion's audience, review the identity provider's application registration. Fields are commonly called Audience, Entity ID, or SP entity ID, but the names vary by provider. Google's SAML audience troubleshooting illustrates the same entity-ID requirement for workforce federation.

When an assertion contains multiple audience restrictions, inspect each one. The tool accepts the expected audience as an alternative within one restriction and requires it to appear in every restriction.

Reproduce a recipient or destination mismatch

Restore the expected audience. In the XML, change only Recipient to https://sp.example.test/saml/acs/. Keep Expected ACS and Destination without that final slash.

The ACS / recipient comparison now reports a mismatch. The tool also identifies that the response destination and subject-confirmation recipient differ. This separates a response delivered to the expected destination from an assertion that names another recipient.

Check all three values together:

  1. The application's configured ACS URL.
  2. The response Destination.
  3. Each bearer subject-confirmation Recipient.

An authentication request has a different shape: AssertionConsumerServiceURL carries its ACS value, while the request's Destination normally names the identity provider's SSO endpoint. Do not compare that request destination with the service provider's ACS URL.

Check request correlation and time separately

Symptom Field to examine
Response belongs to another login attempt Response and subject-confirmation InResponseTo
Assertion is not yet valid Conditions NotBefore and the receiving server's clock
Assertion or subject confirmation has expired The applicable NotOnOrAfter value
Audience and ACS match but sign-in still fails Signature verification, trust configuration, status, and application-specific claim rules

Set Expected request ID to the ID from the request for this exchange. A different ID makes the comparison fail even if every URL matches. Some systems permit unsolicited identity-provider-initiated flows without request correlation; follow the service provider's configured flow rather than adding an arbitrary request ID.

The workbench's default clock-skew allowance is 180 seconds. A skew setting helps compare timing; it does not change the application's clock or its acceptance policy. A successful set of field comparisons is one part of diagnosing sign-in, not a complete sign-in test.

  • SAML Decoder for request/response fields, expected values, and timing evidence.
  • XML Formatter for reading a decoded document's structure.
  • Base64 Decode for inspecting a separate Base64 value when no SAML protocol interpretation is needed.

For the distinction between reading a token and checking its signature, see JWT Decode vs JWT Verify.

Report a correction