SP- and IdP-Initiated SSO

## Two ends of the same exchange SAML 2.0 web single sign-on is one message exchange between two parties, carried by an ordinary browser. A **service provider** owns a protected resource and will not serve it to an unknown visitor. An **identity provider** is willing to make a signed statement about who the person at the browser is. The only structural question left is which end starts. In an **SP-initiated** login the service provider starts. A reader follows a citation into an inter-library loan request page for one specific volume. The service provider finds no session for that browser and, instead of showing a login form of its own, builds a `<samlp:AuthnRequest>`, names itself in `<saml:Issuer>`, generates an `ID` and stores it with the pending login, and hands the browser to the identity provider's single sign-on endpoint. The identity provider authenticates the reader and sends the browser back to the service provider's assertion-consumer endpoint with a `<samlp:Response>` whose `InResponseTo` attribute quotes that `ID`. In an **IdP-initiated** login nobody asked. The reader is already signed in at their institution's portal and clicks the loan service in a list. The identity provider produces a `<samlp:Response>` and sends the browser to the service provider's assertion-consumer endpoint with it. There was no request, so there is no request identifier to quote, and the specification is explicit that `InResponseTo` MUST NOT be present when the response was not generated in answer to a request. ## What the request carries, and what is therefore missing the other way The attributes of `<AuthnRequest>` are the service provider's entire side of the conversation — everything it gets to say before the identity provider takes over: - **`ID`** — unique, generated and stored by the service provider; the answer must quote it back. - **`IssueInstant`** and **`Version`** — when the message was produced, and that it is a SAML 2.0 message. - **`Destination`** — the endpoint this message is intended for. - **`AssertionConsumerServiceURL`** together with **`ProtocolBinding`**, or the mutually exclusive **`AssertionConsumerServiceIndex`** — where the answer should be delivered and how. - **`AttributeConsumingServiceIndex`** — which set of attributes about the person the service provider wants. - **`<NameIDPolicy>`** with its `Format` and `AllowCreate` — what kind of identifier for the person is acceptable, and whether the identity provider may mint a new one. - **`<RequestedAuthnContext>`** — how strongly the service provider wants that person authenticated. - **`ForceAuthn`** and **`IsPassive`** — whether to authenticate afresh, and whether to do so without showing anything. In an IdP-initiated login none of that is sent, so none of it can be asked for. The service provider takes what arrives. ## What actually changes for the service provider | | SP-initiated | IdP-initiated | |---|---|---| | First message on the wire | `<AuthnRequest>` from the service provider | `<Response>` from the identity provider | | `InResponseTo` on the `<Response>` | present, equal to the request's `ID` | MUST NOT be present | | Stored state at the service provider | a pending request keyed by that `ID` | none | | The deep link the reader wanted | held with the pending request, echoed through `RelayState` | only whatever the identity provider chose to put in `RelayState` | | Authentication demands | expressible with `<RequestedAuthnContext>`, `ForceAuthn`, `IsPassive` | none — nothing was asked | Both directions are legitimate. Both end at the same assertion-consumer endpoint, and the same code path can serve both: the service provider branches on whether `InResponseTo` is present. Present means it must match an outstanding request; absent means the login is unsolicited, and accepting it at all is a policy decision the service provider makes deliberately rather than by omission. ## Why the direction is the first thing an interviewer asks Most engineers have only ever integrated one direction, and they tend to describe it as though it were the protocol. A candidate who says "the app redirects you to the identity provider with a request" has described SP-initiated only, and will be surprised the first time a business-to-business counterparty announces that its portal will simply post an assertion at them. A candidate who says "the identity provider sends us the user" has described IdP-initiated only, and has probably never stored a request identifier in their life. For the loan service the practical difference is mundane and decisive. In the SP-initiated case the reader lands on the volume they clicked, because the service provider knew what they were reaching for before the detour started. In the IdP-initiated case the reader arrives at the service cold: the service provider knows who they are and nothing about what they wanted, and must either pick a default landing page or trust a target the identity provider supplied.