What are the steps of the SP-initiated SAML Web Browser SSO flow?

The user requests a resource at the SP, the SP sends an <AuthnRequest> via the browser to the IdP, the IdP authenticates the user and returns a signed assertion via the browser, and the SP verifies it and grants access.

* SP-initiated Web Browser SSO: every message between SP and IdP is relayed by the browser. *

1. HTTP request to a protected resource: the browser asks the SP for a page. The SP has no security context; the user is unknown.
2. <AuthnRequest> to the browser: the SP creates an authentication request and redirects the browser.
3. <AuthnRequest> to the IdP: the browser delivers it to the IdP (typically HTTP Redirect binding).
4. Authentication: the IdP authenticates the user (password, MFA, smart card), or reuses an existing IdP session, and generates the assertion.
5. <Response> with assertion to the browser: the IdP returns a page with an auto-submitting form.
6. <Response> with assertion to the SP: the browser posts it to the SP's assertion consumer service (HTTP POST binding). The SP verifies the assertion.
7. HTTP response: access to the resource, or an error.

Note that SP and IdP never talk directly in this flow: the browser carries both messages. That is why it works across organisations without opening firewalls, and also why steps 5 and 6 are where an attacker would try to grab the assertion.

Go deeper:

• SAML 2.0: Web browser SSO profile (Wikipedia) — the same flow with the exact HTTP exchanges per binding.
• OASIS: SAML V2.0 Technical Overview — section 5.1.2 explains SP-initiated SSO with Redirect/POST bindings.
• Auth0: How SAML Authentication Works (video) — the request-and-response round trip animated.