Solicited and unsolicited responses in SAML

In this post we will have a look on the uses and disadvantages of unsolicited responses in the context of SAML.

Solicited and unsolicited responses

So what is a solicited or unsolicited response? Simply put, a solicited response is a response you asked for, as opposed to a unsolicited response that arrives without you asking for it.

In the context of SAML, a unsolicited response is a SAML authentication response received from the IdP without the SP first having sent an authentication request.

This is allowed in SAML and is also known as IdP initiated authentication, as opposed to SP initiated authentication, when the SP initiated authentication by sending the authentication request.

In order to keep track of this in SAML, when the SP sends a request to the IdP, SP saves the Id of the request. When the IdP send the authentication response back includes the id for the request it responds to in a an attribute, InResponseTo

1<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
2    ID="de8b79c37092487aa7f9c5cb6c5a542a"
3    InResponseTo="id-5PGmWNaR9dLIoTGOf"
4    Version="2.0"
5    IssueInstant="2023-12-02T13:17:14.765Z"
6    Destination="http://localhost:5000/acs">

When the SP receives the response it verifies that the InResponseTo id in the response is the same as the request it sent, ensuring that the response is actually an response to the request that was sent.

In a IdP initiated authentication, the IdP start the authentication itself and send a ready SAML Response with the authenticated user without the SP asking for it.

This is a topic a dive deep into in my book on SAML.

Common reasons to use unsolicited responses

The reason to choose to use unsolicited response flow is often that it makes for a simple login flow for the user in some cases. Lets say that you have a IdP that acts as a kind of portal site, where users enter, login and then choose a app to use. And lets say these apps apps are SAML SPs. If using unsolicited response the IdP only need to create a SAML response and send it with the user when it is redirected to the chosen app.

If you where to use the normal request response flow here the user would first be redirected to the app, the redirected back to the IdP with a SAML request and lastly redirected back to the app again, now with a solicited SAML response.

Another reason this might be used is that because it allows the SP to be completely stateless as it does not need to save the request Ids while writing for for the SAML responses to com back.

Challenges and Disadvantages of IdP-Initiated Authentication

Cross-Site Request Forgery (XSRF) Vulnerability: IdP-initiated SSO is susceptible to XSRF attacks, where an attacker can trick a user into logging into the attacker’s account. For example, the attacker can post a valid SAML response to a public webpage, which is then used to trick users into logging into the attacker’s account. This vulnerability is mitigated in SP-initiated SSO, where the SP ensures that the authentication response corresponds to a specific request.

Deep Linking Problems: Deep linking refers to linking directly to a specific resource on a website. With IdP-initiated SSO, if a user wants to access a specific page on the SP without being authenticated, the process becomes cumbersome. The user must first authenticate via the IdP and then navigate to the desired resource, often requiring custom modifications that undermine SAML’s standardization.

Inflexible Authentication Behavior: SP-initiated SSO allows the SP to specify various authentication requirements through the AuthnRequest. These can include user identifier formats, re-authentication requirements, and preferred authentication methods (e.g., MFA). IdP-initiated authentication lacks this flexibility, making it harder to enforce tailored security measures for different resources.


While IdP-initiated authentication offers a straightforward approach, its disadvantages often outweigh its simplicity. The lack of standardization, susceptibility to XSRF attacks, issues with deep linking, and inflexible authentication behavior make SP-initiated SSO the preferred method. Nonetheless, understanding IdP-initiated authentication is essential for making informed decisions about your authentication strategy and mitigating potential risks when its use is unavoidable. Always strive to use SP-initiated authentication where possible to leverage its security and interoperability benefits.