Walk me through what happens, message by message, in a service-provider-initiated SAML login to Salesforce.

The user hits a Salesforce URL — say a deep link to a record — and has no session.

1. Salesforce sees the org is configured for single sign-on and builds a SAML AuthnRequest, recording where the user was trying to go in RelayState.
2. The browser is redirected to the identity provider's login URL, carrying that request.
3. The identity provider authenticates the user however it likes — password, certificate, multi-factor prompt — which is the whole point: Salesforce never sees the credential.
4. The identity provider builds a signed assertion and posts it, via the browser, to Salesforce's Assertion Consumer Service URL.
5. Salesforce validates the signature against the certificate held in the single sign-on settings, checks that the issuer matches, that the audience is this org, that the recipient is this ACS endpoint, and that the current time falls inside the assertion's validity window.
6. It resolves the subject to a user — by username, Federation ID, or User ID, depending on the configured identity type — establishes the session, and redirects to the URL held in RelayState.

The reason I tell it this way in an interview is that every common failure maps to one of those checks: signature to the certificate, audience and recipient to a My Domain or sandbox mismatch, validity window to clock skew, subject resolution to the Federation ID.