Skip to content
SteveTechArcSteveTechArc Courses

The Browser Is the Broker

Module 3 of 6 in the chapter Single Sign-On: The Browser Is the Broker, chapter 4 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: If the identity provider and Salesforce never talk to each other, how does Priya get from one to the other?

The flicker

Section titled “The flicker”

You’ve seen single sign-on happen, even if you’ve never set it up. You click a link at work, the screen flickers, the address bar changes two or three times, and you land on the page you wanted. When I demo it in class, I tell everyone: let’s watch the flicker.

That flicker is a series of redirects. A redirect is a server’s way of answering “not here, go there instead.” On the web, it’s a status code in the 300s, most often 302. The web’s own standard defines it as a response meaning “further action needs to be taken by the user agent”, and the user agent is your browser.

Here’s the important part. When Salesforce redirects you to another server, Salesforce isn’t calling that server. It answers your browser, and your browser makes the next call. So every step of single sign-on is the browser going somewhere, being sent somewhere else, and going there. You have to get used to these redirects, because they’re the heart of single sign-on.

The tennis match

Section titled “The tennis match”

I once watched a tennis coach working with two players. The coach stood on one side of the court and hit a ball to the first player, then to the second, then back to the first, then to the second again. Try to draw that with boxes and arrows and it becomes a mess almost at once. Where does step one go? Where does step two go?

Single sign-on is the same back-and-forth. So identity architects use a different picture: the swim lane. Each actor gets a lane, a column running down the page, and time runs from top to bottom. Every arrow is one call, from one lane to another, in order. It’s the diagram I want every identity architect to reach for first, the way an integration architect reaches for the system landscape and a data architect for the data model.

One login, hop by hop

Section titled “One login, hop by hop”

Here’s Priya’s first login of the day, in a swim lane. The lanes are the cast from module 2: her browser, the identity provider, and Salesforce’s two servers, the login server and the instance. Because Priya starts at Salesforce, the service provider, this is called a service-provider-initiated login.

The browser is the broker A swim lane with four lanes, left to right: Priya's browser, the identity provider, Salesforce's login server and Salesforce's instance; time runs down the page in five steps, each a call from the browser and an answer straight back to it. 1: the browser asks the instance for a Salesforce record; the instance has no session yet and answers with a redirect to the login server. 2: the browser follows the redirect to the login server, which knows the org uses an identity provider and answers with a redirect there, with a SAML request. 3: the browser takes the SAML request to the identity provider, which shows the login screen; Priya signs in with MFA, and the identity provider answers with a signed SAML response, in a form. 4: the browser posts the SAML response to Salesforce's login server, which checks the signature with the identity provider's certificate, issues the session, and answers with a redirect and the session. 5: the browser asks for the record again, with the session; the instance checks it and answers with the record. Footnote: each step is a call from the browser and an answer back to it; the identity provider and Salesforce never call each other. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-03", "id": "DGM-IAM-SSO-03", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA'S BROWSER THE IDENTITY PROVIDER SALESFORCE'S LOGIN SERVER SALESFORCE'S INSTANCE 1. Opens a link to a Salesforce record No session yet redirects the browser to the login server 2. Goes to the login server redirected by the instance Uses an identity provider redirects the browser there, with a SAML request 3. Goes to the identity provider redirected, with the SAML request The login screen Priya signs in, with MFA; sends back a signed SAML response, in a form 4. Hands over the response posts the form by itself Checks the signature with the identity provider's certificate; issues the session; redirects back to the record 5. Back to the record redirected, with the session The record checks the session; Priya is in asks for the record redirect: go to the login server follows the redirect redirect to the IdP + SAML request SAML request SAML response posts the SAML response redirect + session asks again, with the session the record Each step is a call from the browser and an answer back to it: a redirect, a SAML request or response, a session. The identity provider and Salesforce never call each other. HOW TO READ IT the identity provider: the one login screen the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  1. Priya opens a link to a Salesforce record. Salesforce’s instance sees that she has no session, no wristband, so it redirects her browser to Salesforce’s login server.
  2. The login server sends her on. This org uses an identity provider, so the login server redirects her browser there, carrying a SAML request: in effect, “please tell me who this is.” (If the org offers more than one way to log in, Priya first sees Salesforce’s login page with a button for the identity provider. If single sign-on is the only way, Salesforce sends her straight there.)
  3. The identity provider shows the login screen. That’s module 2’s test: the system with the login screen is the identity provider. Priya signs in, with her password and her second factor. The identity provider then sends her browser back to Salesforce with a SAML response: a signed statement that says, in effect, “this is Priya, and here’s how she proved it.”
  4. Salesforce’s login server checks it. It checks the signature with the identity provider’s certificate, which it was given in advance (module 4). If the check passes, the login server gives Priya her session. This is the step people miss: the identity provider doesn’t get Priya into Salesforce. It gets her to Salesforce’s login server, and the login server gets her into Salesforce.
  5. Back to where she started. One last redirect takes her to the record she asked for in step 1. The link she first clicked travels along with her through every hop, so she lands on that record, not on a home page. (Chapter 6 shows how, with a value called the relay state.)

Count the calls between the identity provider and Salesforce in that picture. There are none. Every call starts at Priya’s browser, and every answer comes straight back to it. The browser is the broker.

How the messages travel

Section titled “How the messages travel”

So how does a SAML request ride along on a redirect? The simple version is that it’s added to the web address, as a URL parameter. And as I always say, URLs have a limited length. The SAML standard itself says the permitted length is “theoretically infinite, but unpredictably limited in practice.”

So the two messages travel a little differently. The SAML request is small, so it’s compressed and added to the URL. The SAML response is much bigger, because it carries the signed statement about Priya, so the identity provider usually sends it as a small web form, and Priya’s browser submits that form to Salesforce by itself, in a moment. Either way, the browser carries it. Chapter 6 opens both messages and reads them line by line.

Each side needs the other’s addresses

Section titled “Each side needs the other’s addresses”

For any of this to work, each side has to know where to send the browser. Salesforce needs the address of the identity provider’s login page. The identity provider needs the address on Salesforce’s side where SAML responses are received. These are often called callback URLs: where to send the browser back to.

Those addresses, plus a certificate, are most of what single sign-on setup really is. And every one of those hops runs over TLS, the safe road from chapter 3, module 5.

The second login: the “single” in single sign-on

Section titled “The second login: the “single” in single sign-on”

So far, that’s just sign-on. Where’s the single?

Ten minutes later, Priya clicks a link into the HR system. The HR system is a second service provider, and it has never seen her today. So it does exactly what Salesforce did: it redirects her browser to the identity provider, with its own SAML request.

But this time, something different happens. The identity provider already has a session with Priya from her first login. It knows she’s been here today. So it doesn’t show her a login screen at all. It answers straight away with a SAML response for the HR system: “Hey, Priya, I know you’ve been here today. Here you go, get back to work.” One more flicker, and she’s in.

That’s the single in single sign-on. The second, third and fourth systems each still go to the identity provider. But only the first one costs Priya a login.

Try it

Section titled “Try it”

You can watch all of this yourself. Open a private browser window, so you have no sessions. Open your browser’s developer tools, and choose the Network tab. Then paste in a link to a record in a Salesforce org, and watch the list. You’ll see the 302 redirects go by: to the login page, and, if the org uses single sign-on, to the identity provider and back.

What’s next

Section titled “What’s next”

Look at the swim lane once more, for what isn’t there. There’s no arrow between the identity provider and Salesforce. So how does Salesforce know it can trust a SAML response that arrives in Priya’s browser? Module 4.

What an architect decides here

Section titled “What an architect decides here”
  • Draw single sign-on as a swim lane. One lane per actor, every arrow through the browser. Not a landscape with an arrow between the identity provider and the service provider.
  • Know every address. Where each side sends the browser, and where each one receives it. They’re the first thing to check when a login fails.
  • Decide what users see first: Salesforce’s own login page with a button for the identity provider, or straight to the identity provider. Module 5 comes back to that choice.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.