Skip to content
SteveTechArcSteveTechArc Courses

Single Sign-On: The Browser Is the Broker

Chapter 4 of Securing Salesforce: Identity and Access, Part 1: Who Are You? New to the course? Start with chapter 1.

Here’s the question for this chapter. Priya uses three systems at work, with three usernames and three passwords. Why would her company put one system in charge of all her logins, and how does that system get her into Salesforce if the two of them never talk to each other?

Chapter 2 was the front door: how Salesforce checks who you are. Chapter 3 was trust: keys, certificates and signatures. This chapter puts them together. Single sign-on moves the front door to one place, the identity provider, and uses a certificate so that Salesforce can believe what it says. And it all happens through one actor you might not expect: the browser.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Every system has its own guard. For each system there are two servers: the login server, which checks who you are and gives you a session, and the resource, which only checks the session.
  • One place to prove who you are. With single sign-on, people sign in once, at the identity provider, and every service provider trusts it. Fewer passwords, so they can be stronger; one place for the rules, the MFA and the reset; one switch when someone leaves.
  • One front door matters more. If the identity provider is down or fooled, every system behind it is too.
  • Know the cast. The browser, the identity provider, the identity store behind it, and the service provider with its own two servers. Active Directory is an identity store, not an identity provider.
  • Whichever system shows the login screen is the identity provider. There should be only one.
  • The browser is the broker. Every step of single sign-on is a redirect: the server answers the browser, and the browser makes the next call. The identity provider doesn’t get Priya into Salesforce; Salesforce’s own login server does.
  • Draw it as a swim lane. One lane per actor, time running down the page, each call with its answer.
  • There’s no arrow between them. Salesforce trusts the identity provider through a certificate an admin installed once, and checks every signed SAML response on the spot. An arrow between the identity provider and Salesforce on a login diagram is wrong.
  • Certificates expire, so trust does too. Replacing the identity provider’s certificate is a job for both sides at once.
  • Keep a back door. A few admins keep a direct login with phishing-resistant MFA, because when single sign-on breaks, someone has to get in to fix it.
  • SAML is what the browser carries. The service provider writes the request; the identity provider answers with a signed response, and the assertion inside says who Priya is, who it’s for, and when it’s valid.
  • Five questions before Priya gets in. Is the signature valid, did it come from our identity provider, is it for us, is it within the time window, and who am I logging in? Salesforce adds a sixth, have we seen it before, and each no has its own name in Login History.

The picture

Section titled “The picture”

Here’s the picture the chapter turns on: one login, hop by hop, as a swim lane. Count the calls between the identity provider and Salesforce. There are none.

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

Every call starts at Priya’s browser, and every answer comes straight back to it. When you see a system landscape with an arrow between the identity provider and Salesforce, that’s not correct. There’s an installed certificate, but no call. That one idea settles more single sign-on arguments than any setting.

The path through this chapter

Section titled “The path through this chapter”

Six modules, each standing on its own.

  1. One Person, Many Logins. Every system has its own guard; Priya’s three names; what too many passwords cost, and the keyboard I turned over; the identity provider and the service provider; why companies do it, and the catch.

  2. The Actors. The browser, the identity provider, the identity store, and the service provider with its two servers; how many directories you have; counting the services behind one login; the login screen test; and Salesforce in either part.

  3. The Browser Is the Broker. The flicker and the redirects; the tennis match and the swim lane; one login, hop by hop; how the SAML request and response travel; the callback URLs; and the second login, the “single” in single sign-on.

  4. No Arrow Between Them. Who trusts whom; a certificate, installed once; every login checked on the spot; trust in the other direction; the wrong diagram and the trouble it causes; provisioning, the only direct line; and when the certificate changes.

  5. Keep a Back Door. The day it breaks, including the clocks; who must have a local login; the switch and who it leaves out; three more ways the door can close; protecting the back door; testing with a user, not an admin; and the checklist.

  6. What the Browser Carries. What SAML is; who writes the request; the response as a sealed letter in an envelope, and the assertion inside; five questions before Priya gets in, and Salesforce’s name for each failure; why the times are there; what a response is worth by itself; and the auto mechanic.

The order is the order a login happens in. Why one door, who the players are, how the browser carries Priya between them, why Salesforce believes the answer, what to do on the day it doesn’t work, and what’s inside the message the browser carries.

Then build it yourself. The practice has you set up two free Salesforce orgs, one as the identity provider and one as the service provider, ready to connect in chapter 7. And check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • Which systems go behind the identity provider, and which can’t, and why.
  • Who owns the identity provider: an owner, a support plan and its own security review.
  • The identity provider and the identity store, named on every diagram, and how many directories sit behind them.
  • Which part Salesforce plays: service provider, identity provider, or both.
  • Every address in the relationship: where each side sends the browser, and where each receives it.
  • What users see first: Salesforce’s login page with a button, or straight to the identity provider.
  • Every certificate: whose it is, where it’s installed, who renews it and when.
  • Whether Salesforce signs its requests, and whether the identity provider encrypts its assertions.
  • Who keeps the back door, how it’s protected and watched, and how it’s tested.
  • Which values each side expects in the SAML messages, what gets signed and how, and where to look first when a login fails.

Beyond the exam: what AI changes. Single sign-on is built for a person in a browser: a login screen to type at, and redirects to follow. An agent has neither. When an agent acts for Priya, it doesn’t flicker through the identity provider’s login page; it needs a different mechanism, built on tokens, and chapter 5 starts choosing between them. What carries over is this chapter’s question: who proves who this is, and who trusts that proof, and why? Chapter 17 asks it for agents.

Explore

Section titled “Explore”

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Next: SSO or OAuth? Choosing the Mechanism

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.