How does IdP-initiated SSO differ from SP-initiated SSO, and what security drawback does the IdP-initiated variant have?
In SP-initiated SSO the user goes to the application first, which asks the IdP to authenticate them; in IdP-initiated SSO the user logs in at the IdP first (for example a portal) and is sent to the SP with an unsolicited assertion. Without a matching request, the SP cannot check InResponseTo, which weakens its defence against injected responses.
* IdP-initiated: two steps, starting at the IdP. SP-initiated: three steps, starting at the application. *
| IdP-initiated | SP-initiated | |
|---|---|---|
| Starting point | IdP portal ("my apps" page) | A bookmark or link to the application |
| Steps | ① authenticate at IdP, ② access SP successfully | ① attempt access at SP, ② authenticate at IdP when asked, ③ succeed in the attempt |
<AuthnRequest> |
None, the response is unsolicited | Yes, the response answers it |
| Deep links | Lands on a default page | The SP can return the user to the page they asked for (RelayState) |
| Security | Weaker: no request to bind the response to | Stronger: InResponseTo ties response to request |
Because an unsolicited response is accepted at any time, an attacker who obtains a valid response (or tricks a victim's browser into posting one) has an easier time getting it accepted, and login CSRF (logging the victim into the attacker's account) becomes possible. SPs that support IdP-initiated SSO should keep the replay cache strict and the validity window short.
Go deeper:
OWASP SAML Security Cheat Sheet: unsolicited responses — what an SP must do if it accepts IdP-initiated SSO.- OASIS: SAML V2.0 Technical Overview — section 5.1.4 shows IdP-initiated SSO with the POST binding.