The Second App, and the IdP-Initiated Flow
Module 2 of 7 in the chapter Salesforce as the Service Provider: SAML, chapter 6 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: What happens at the second app of the day, and what changes when the day starts at the identity provider?
Ten minutes later
Section titled “Ten minutes later”Module 1 walked Priya’s first login of the day: a link to Salesforce, a redirect to the identity provider, a login screen, and back. Now let’s say she started her day somewhere else. She opened the company’s expense app first, signed in at the identity provider, and did her expenses. Ten minutes later she clicks a link to a Salesforce record.
Which flow kicks in? I ask this in every class. Say the words: it’s the SP-initiated flow, again.
Salesforce has never seen her today. It doesn’t matter that she logged in to the expense app; Salesforce has no session for her. So it does exactly what it did in module 1: it redirects her to the identity provider with a SAML request.
What’s different is at the identity provider. It has seen her today. She has a session there from this morning. So there’s no login screen. It writes a signed SAML response at once and sends her straight back.
Every redirect still happens. They’re just fast. All Priya sees is a flicker in the address bar, and then the record. This is the moment single sign-on earns its name: one login in the morning, and every app after that just opens.
Notice the identity provider’s session is doing the work here. Salesforce’s own session, its wristband, starts only when its checks pass. Each service provider has its own session; the identity provider holds the one that ties them together.
Starting at the identity provider
Section titled “Starting at the identity provider”Now the other way to start the day. Some people go straight to the identity provider first thing: they open the company’s sign-in page, the Okta or the Entra ID or whatever the company uses, by its own address. They log in. And where does the identity provider take them?
Usually, to an app launcher: a page of buttons, one for every app they’re allowed to use. Salesforce, Workday, the expense app. When I was a contractor at one large company, the app launcher had about 20 icons on it. It was crazy. But here’s the thing about an app launcher that makes it a little bit magic.
When Priya clicks the Salesforce button, the identity provider doesn’t send her to Salesforce to start a login. It sends her there with a SAML response already in hand. No SAML request, because Salesforce never asked. The browser posts the response straight to Salesforce, Salesforce checks it, and she’s in. It’s a quicker flow.
That’s the IdP-initiated flow. Salesforce’s own description is exact: “a SAML request is unnecessary because the identity provider starts the flow with a SAML response”, which makes it “a shortened version of a service provider-initiated flow” (S3).
Put the two pictures side by side and you can see it: the IdP-initiated flow is the SP-initiated flow with the first half cut off.
What the shortcut changes
Section titled “What the shortcut changes”Two things follow from having no request.
The response answers nothing. In chapter 4, module 6, you saw that a response carries the ID of the request it answers, InResponseTo, so it can’t come in cold. In the IdP-initiated flow there was no request, so there’s no ID to match. Salesforce still checks everything else: the signature, the issuer, the audience, the time window, the assertion’s own ID so it can’t be used twice, and the user. That’s why the time window and the one-use ID matter so much here: they’re doing the job the request ID did.
She lands on Home, unless you say otherwise. In the SP-initiated flow, Salesforce knows which record she asked for. In the IdP-initiated flow, she clicked a button, so there’s no page to go back to. She lands on Home, unless the identity provider adds the page she should land on to its link (S4). That’s the relay state, and module 6 is all about it.
And then ten minutes later
Section titled “And then ten minutes later”Here’s how the day really goes. Priya starts at the app launcher and clicks Salesforce: IdP-initiated. Ten minutes later, she clicks a link in an email that goes to Workday. Which flow kicks in at Workday? SP-initiated, because Workday hasn’t seen her yet. And like the second app above, there’s no login screen, because the identity provider already has her session.
So in one morning, she can use both flows without ever knowing. That’s all the flows you need to know for single sign-on with an identity provider. And it’s just some redirects. There’s nothing magical here.
Test knowledge. In my experience, know which flow is which, and which one kicks in for the second app. SP-initiated starts with a SAML request from the service provider. IdP-initiated starts at the identity provider, usually its app launcher, with a SAML response and no request. The second app you open from a link is SP-initiated, with no login screen.
On the map
Section titled “On the map”This module turns the second card of the single sign-on set blue: SAML started at the identity provider. The map is in module 1.
What’s next
Section titled “What’s next”Module 3: setting Salesforce up, so both flows work.
What an architect decides here
Section titled “What an architect decides here”- Which flows to support: SP-initiated always, because people use bookmarks and links; IdP-initiated if the company uses an app launcher.
- Where an IdP-initiated login should land, if not Home (module 6).
- How long the identity provider’s session lasts, since it decides how often anyone sees a login screen at all.
Explore
Section titled “Explore”- SAML Single Sign-On Flows (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)