Category: Federation & SSO

Assertion Consumer Service

Also known as: ACS, ACS endpoint, Assertion Consumer Service URL, SP sign-in URL

Simply put

The Assertion Consumer Service (ACS) is the specific web address at a service provider where the results of a SAML single sign-on are delivered after a user has been authenticated. When an identity provider vouches for a user, it sends that confirmation to this endpoint, which then reads the information and establishes a logged-in session for the user.

Formal definition

In SAML 2.0 web SSO, the Assertion Consumer Service (ACS) is the service provider (SP) endpoint that receives SAML responses containing authentication assertions from the identity provider (IdP). The ACS typically validates the inbound response, extracts assertion contents such as the authentication event and subject attributes, and uses them to establish a local application session. A service provider may expose multiple ACS URLs (for example distinguished by binding or index), with one designated as the default in most deployments; the specific endpoint used is determined by partner metadata or configuration. Note that the ACS is an SP-side runtime consumer of assertions and is distinct from the authorization decisions the application subsequently enforces.

Why it matters

The Assertion Consumer Service is the point at which a federated authentication event crosses from the identity provider's assertion into a live session at the service provider. Because the ACS is where inbound SAML responses are received and consumed, it is the natural place for the SP to enforce the validation that keeps SSO trustworthy, verifying signatures, checking the response against expected issuer and audience, and confirming the assertion was intended for that endpoint. Misconfiguration or weak validation at this boundary can undermine the entire federation trust chain, since a session established here typically grants the user access to the application.

The ACS also matters operationally because service providers often expose multiple ACS URLs, distinguished by binding or index, with one designated as the default in most deployments. Which endpoint the identity provider targets is determined by partner metadata or configuration, so mismatches between what the SP registers and what the IdP is configured to send are a common source of failed SSO. Getting the ACS URL, its binding, and its default designation right is a routine but consequential part of onboarding any SAML federation partner.

It is important to keep the ACS scoped to what it actually does. The ACS is an SP-side runtime consumer of authentication assertions; it establishes a local session but does not itself make the authorization decisions the application enforces afterward. Treating the ACS as though it governs what the authenticated user may do conflates authentication delivery with downstream authorization and can lead to gaps in how access is actually controlled.

Who it's relevant to

IAM and Federation Engineers

Engineers configuring SAML 2.0 SSO must register the correct ACS URL, binding, and default index in both SP configuration and IdP partner metadata. Mismatches between the endpoint the SP exposes and the one the IdP targets are a frequent cause of failed sign-on, so precise coordination of these values is part of routine partner onboarding.

Security Architects

Because the ACS is the runtime boundary where an inbound SAML response is consumed and turned into a local session, architects should ensure appropriate validation of the response occurs at this endpoint. They should also keep the ACS's role, delivering the authentication result, distinct from the authorization decisions the application enforces afterward.

Application and SP Administrators

Administrators operating service providers that support multiple ACS URLs need to understand how the endpoint used is selected via metadata or configuration and which endpoint is designated as the default. This is relevant when troubleshooting SSO or supporting applications that require a specific ACS among several configured.

Inside ACS

ACS Endpoint URL

The specific service provider (SP) URL, defined in SAML 2.0 metadata, to which the identity provider (IdP) delivers SAML responses containing authentication assertions. It is typically registered with the IdP so that responses are only sent to a trusted, pre-configured location.

SAML Response Handler

The logic at the ACS responsible for receiving the SAML response, typically via HTTP POST binding, and initiating processing of the enclosed assertion. This is the entry point where the browser-relayed response arrives at the SP.

Assertion Validation

The steps performed at the ACS to verify the received assertion, which typically include checking the XML signature to confirm integrity and origin, validating conditions such as time-based validity (NotBefore/NotOnOrAfter), and confirming audience restriction so the assertion is intended for this SP. A signed assertion establishes integrity and authenticity but is not necessarily encrypted.

Binding Support

The transport mechanism used to deliver the SAML response to the ACS. The HTTP POST binding is commonly used, where the response is relayed through the user's browser. The applicable binding is declared in SP metadata for the ACS endpoint.

Subject and Attribute Extraction

After validation, the ACS extracts the authenticated subject (identifying who the principal is) and any attribute statements from the assertion. These attributes may subsequently inform authorization decisions, though authorization enforcement is a separate step from the authentication that the assertion conveys.

Session Establishment

Following successful assertion validation, the ACS typically establishes a local authenticated session for the principal at the SP, completing the web SSO flow.

Common questions

Answers to the questions practitioners most commonly ask about ACS.

Is the Assertion Consumer Service the same thing as an identity provider endpoint?

No. The Assertion Consumer Service (ACS) is an endpoint hosted by the service provider (relying party), not the identity provider. In SAML 2.0 web SSO, the identity provider issues the assertion, and the ACS is the SP-side endpoint that receives and processes it. Conflating the two reverses the roles: the IdP asserts identity, while the ACS consumes what the IdP asserts.

Does the Assertion Consumer Service authenticate the user?

Not directly. Authentication of the user typically occurs at the identity provider. The ACS consumes the resulting SAML assertion and validates it, checking the signature, conditions such as time windows and audience, and other constraints, so that the service provider can establish a local authenticated session. In other words, the ACS relies on authentication performed elsewhere and focuses on validating the assertion that conveys it, rather than performing the credential check itself.

How does an identity provider know which Assertion Consumer Service endpoint to send an assertion to?

In most SAML 2.0 deployments, the SP publishes one or more ACS endpoints, along with their bindings and index values, in its SAML metadata, which the IdP consumes during trust configuration. An authentication request from the SP can also specify an AssertionConsumerServiceIndex or an AssertionConsumerServiceURL, though whether an IdP honors a requested URL depends on configuration and its validation against registered metadata. Exact behavior varies by product and profile.

What validation should an Assertion Consumer Service perform on an incoming assertion?

Depending on the profile and configuration, ACS processing typically includes verifying the XML signature against the IdP's configured signing certificate, confirming the assertion's audience restriction matches the SP's entity ID, checking NotBefore/NotOnOrAfter time conditions (allowing for clock skew), validating the InResponseTo value against a pending request where applicable, and enforcing single-use of the assertion to mitigate replay. Note that a signed assertion is not necessarily encrypted; whether the assertion or its NameID is encrypted is a separate configuration concern.

Which binding is commonly used for the Assertion Consumer Service endpoint?

In many SAML 2.0 web SSO deployments the ACS endpoint uses the HTTP POST binding, where the assertion is delivered via a browser form POST. Other bindings may be supported depending on the deployment and the SP's advertised metadata. The specific binding in use should be confirmed against the SP metadata and vendor documentation rather than assumed.

Can a service provider register multiple Assertion Consumer Service endpoints?

Yes, in most SAML 2.0 implementations an SP can advertise multiple ACS endpoints in its metadata, each distinguished by an index and potentially a different binding, with one typically marked as the default. This can support multiple bindings or multiple application entry points. Which endpoint is used for a given flow depends on the SP's request and the IdP's configuration and validation rules.

Common misconceptions

The Assertion Consumer Service authorizes the user's access to resources.

The ACS is concerned with consuming and validating an authentication assertion, which establishes who the principal is. Determining what the principal may do is a separate authorization step, typically handled by the SP's application logic or a distinct policy enforcement mechanism after the session is established.

A signed SAML assertion arriving at the ACS is also confidential because it is signed.

Signing provides integrity and origin authenticity, allowing the ACS to verify the assertion has not been tampered with and came from the trusted IdP. It does not provide confidentiality. Encryption of the assertion or its elements is a separate, optional measure depending on the deployment and profile.

The Assertion Consumer Service is a generic OAuth or OpenID Connect component.

The ACS is specific to SAML 2.0 web SSO and refers to the SP endpoint that receives and processes SAML responses. OAuth 2.0 is a delegated authorization framework and OpenID Connect is an authentication layer on top of it; their flows use different endpoints and terminology (such as redirect URIs) rather than an ACS.

Best practices

Register only trusted, pre-configured ACS endpoint URLs with the IdP so SAML responses cannot be redirected to unintended locations.

Always validate the XML signature on incoming assertions to confirm integrity and that the assertion originated from the expected IdP before trusting its contents.

Enforce audience restriction and time-based conditions (NotBefore/NotOnOrAfter) at the ACS to reject assertions not intended for this SP or that fall outside their validity window.

Keep authentication and authorization as distinct steps: use the ACS to establish who the principal is, and defer resource authorization decisions to separate application or policy enforcement logic.

Where confidentiality of assertion contents is required, apply assertion or attribute encryption in addition to signing, since signing alone does not protect confidentiality.

Declare the correct binding (commonly HTTP POST) and endpoint details accurately in SP metadata so the IdP delivers responses in a form the ACS is configured to process.