Read a Swim Lane

Module 3 of 4 in the chapter Thinking Like an Identity Architect, chapter 1 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: What’s the identity architect’s main diagram, and how do you read one?

Every domain has its diagram

If we were in an integration class, we’d be talking about system landscapes: the systems, and the lines between them. If we were in a data class, we’d be talking about data models: the objects, and how they relate. Each architect domain has a main diagram, the one you draw first.

In identity, because of all the back-and-forth, our main diagram is the swim lane. Honestly, it’s the only way to keep track of what’s happening. And it’s the diagram I want every identity architect to reach for first.

The tennis match

Here’s why a landscape doesn’t work. 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.

Now try to draw that with boxes and arrows. Three boxes: the coach and the two players. Then the arrows: coach to player one, back, coach to player two, back, again and again. Within a minute you have a mess of lines going both ways between the same boxes. Where does step one go? Where does step two go? You can’t tell the order, and the order is the whole story.

Logins are like that. The same few parties hit the ball back and forth, many times, in a strict order. So we switch to a different kind of diagram.

The parts of a swim lane

A swim lane has only three parts.

Lanes. Each party gets a lane: a column running down the page, like the lanes in a swimming pool. A person’s browser, a login server, an org. Each lane is labelled at the top.
Time runs down the page. The first thing that happens is at the top, the last at the bottom. You never have to guess the order: you read it.
Arrows are calls, and each call has its answer. An arrow goes from the lane that asks to the lane that’s asked. Underneath it, an arrow comes back, labelled with what comes back. In this course, every call is drawn with its answer, so you can always see what each party got.

That’s all. The skill is in what you put in the lanes and the labels, and in reading it one row at a time.

What a redirect is

Before we read a login, you need the one idea that all of identity runs on: the redirect.

When your browser asks a server for a page, the server’s answer starts with a status code, a three-digit number that says how it went. The 200s mean “here it is.” The 400s and 500s mean something went wrong. And the 300s mean “not here: go there instead.” That’s a redirect. The one you’ll see most often is 302. With it, the server sends a header called Location, which holds the address to go to next.

Then your browser does something quietly important: it goes there by itself. The web’s own standard says that when a Location is given, the browser “MAY automatically redirect its request” to that address (RFC 9110, section 15.4 (opens in a new tab)). Every browser does. You don’t click anything. At most, you see the address bar change.

If you’ve taken the Integration course, a redirect can look like an odd thing to build on. In calls between systems, you rarely see one: an integration calls an API and expects the data back, not “go somewhere else.” The Integration course says so in The REST Request, Taken Apart. In identity, it’s the opposite. Redirects are everywhere, because they’re how one server hands you to another without the two of them ever talking. Every status code is in the HTTP Status Codes reference; in identity, the 300s are the ones to know.

Two kinds of redirect

You’ll meet redirects in two ways in this course.

Automatic. The server answers with a code in the 300s, and the browser follows it at once. Nobody decides anything; the browser just goes. Most of a login is a chain of these: the instance sends you to the login server, and the login server sends you back.
“Manual”: the client acts on it. In OAuth, the last redirect sends your browser back to the app, the client, with a short-lived code in the address. The browser delivers the code, but the app’s own server is the one that reads it and decides what happens next: it takes the code to Salesforce itself, server to server, and asks for a token. The OAuth standard describes the same two steps: the authorization server “redirects the user-agent back to the client”, and then “the client requests an access token” with that code (RFC 6749, section 4.1 (opens in a new tab)). Chapter 9 walks through it, hop by hop, at the Burger House.

So for every redirect in a swim lane, ask: does the browser simply follow it, or does it carry something to a client that then makes a call of its own? One more variation you’ll meet: some steps use a page that sends a form by itself, instead of a code in the 300s. Chapter 4 shows it, for SAML.

Here’s the first swim lane I draw in class: you logging in to Salesforce, with nothing else involved. Three lanes: your browser, Salesforce’s login server, and Salesforce’s instance, the server your org actually runs on. Chapter 2, the front door, introduces those two servers; here we only watch the ball.

Click to enlarge

Read it one row at a time.

Your browser asks for a page, say a link to a record. The instance sees you have no session yet, so it answers with a redirect: “not here; go and log in first.”
Your browser goes where it was sent. The login server answers with the login screen.
You type your username and password, and the browser sends them. The login server checks them and, if they’re right, answers with another redirect, this time carrying a session: proof that you’ve logged in.
Your browser asks the instance again, for the same link, with the session. Now the instance answers with the record.

Four rows, four calls, four answers. And you can see the order at a glance, which no landscape could show you.

The browser is the broker

Now look at what’s not in that picture. There’s no arrow between the instance and the login server. In row 1, the instance didn’t call the login server. It answered your browser, and your browser made the next call.

That’s the most important thing a swim lane shows you, and people get it wrong all the time. The servers don’t talk to each other during a login. They redirect the browser, and the browser goes from place to place. In this example every call begins at the browser and every answer ends there. The browser is the broker. Chapter 4 is built on that one idea, when a second login server, the identity provider, joins the match.

One more thing to look for in every swim lane: which lane shows the login screen? I tell people, whichever one presents the login screen, the credentials, that’s your identity provider. It’s providing the login screen, and every other system is providing a service.

In the picture above, there’s only one login screen, and it’s Salesforce’s, so Salesforce decides who you are. In chapter 4, the login screen moves to a different lane, and that changes everything about who trusts whom. Circle that lane every time you draw one. There should be only one.

How to read any swim lane

When you meet a swim lane in this course, or draw one on a project, ask the same questions:

Who are the lanes? Name every party. A login that seems to involve two systems often involves four or five.
What starts it? The top row: who makes the first call, and what are they asking for?
What comes back? Read the label under each answer: a page, a redirect, a session, a token. The answer is often more important than the call.
Who shows the login screen? That’s your identity provider.
Where’s the arrow that isn’t there? If two servers seem to talk directly, check. Sometimes they do, and the diagram should say why. Often they don’t, and the browser carries the message.

Later chapters add lanes: an identity provider, an app, a program with no person at all. The questions stay the same.

What’s next

Module 4: why none of this stays set. Security keeps changing, and identity changes with it.

What an architect takes from this

Draw identity as a swim lane. One lane per party, time running down the page.
Draw every call with its answer, labelled with what comes back.
Know the two kinds of redirect: the ones the browser simply follows, and the ones that carry something to a client that then makes its own call.
Circle the lane that shows the login screen. That’s the identity provider, and there should be only one.
Look for the missing arrow. During a login, the servers usually don’t call each other: the browser carries everything.

Explore

RFC 9110: HTTP Semantics (opens in a new tab), section 15.4, Redirection 3xx (IETF, 2022; checked 2026-11-07): the web’s own definition of a redirect, and the Location header the browser follows.
RFC 6749: The OAuth 2.0 Authorization Framework (opens in a new tab), section 4.1, Authorization Code Grant (IETF, 2012; checked 2026-11-07): the redirect back to the client, and the client’s own call for the token.