The Doors Into Salesforce

Module 1 of 5 in the shared chapter The Front Door: Logging In to Salesforce, chapter 2 of Securing Salesforce: Sharing and Visibility and part of the Identity and Access course. Each module stands on its own.

The question this module answers: How many ways are there into a Salesforce org, which ones need a login, and where does logging in end?

Let me start with a question I ask every class. How many ways are there into your Salesforce org?

Most people say one: the login page. You type your username and password, and you’re in. But that’s only the door you use every day. A Salesforce org has a lot of doors, and some of them don’t ask anyone to log in at all. Before you can secure the front door, you need to know how many doors the building has.

Two words, again

Everything in this chapter is about the first of two words. Authentication is someone, or some process, coming up to Salesforce and asking to be let in. It’s how we decide whether we should or shouldn’t let them in, by verifying who they are. Authorization is what comes after: now that we know who you are, what can you do?

I picture it as a control panel and a ring of keys. On one side is the panel at the door: passwords, codes, fingerprints, everything that proves who you are. On the other side are millions of keys. Once we know who you are, we hand you a few of them and say, these are the doors you can open. Chapter 1 of this course was about the whole building. This chapter is about the panel at the door.

The doors into the building

If Salesforce were a building, here are its doors. I’ll take them one visitor at a time. The browser and the login page. A person in a browser goes first to the login page, which is served by Salesforce’s authentication server. That’s where you prove who you are. Only then are you sent on to the instance’s web server, which builds the pages of your org. Every page after that requires you to be authenticated.

Click to enlarge

Experience Cloud sites. Over the years they’ve been called customer portals, partner portals, communities and digital experiences. Whatever you know them as, a site can allow some anonymous access, meaning people who never log in, and require authentication for the rest. That authentication can be Salesforce’s own login, or a social sign-on such as a login with another provider.

Public sites. The older Salesforce Sites feature is still around, and its pages can be public. Visitors never stop at the authentication server.

Web-to-lead and web-to-case. These are forms on your own website that send leads and cases straight into your org. They don’t require anyone to log in.

Incoming email. Email-to-case and email services let messages come into the org through Salesforce’s email servers, not through a browser at all.

Click to enlarge

Client applications and integrations. On the other side of the building are programs, not people: a server-to-server integration, a desktop or mobile app, a middleware platform. They authenticate too, at the same authentication server, usually with OAuth, which hands the program a token instead of a person typing a password. Then they reach the APIs: Salesforce’s own versioned APIs, which get a new version every release; the custom web services your team builds in Apex, which aren’t versioned the same way; and the event bus, where programs publish and subscribe to platform events.

Click to enlarge

Look at that list again and notice how many doors have no lock at all. A public site page, a web-to-case form and an inbound email address don’t ask who you are. That doesn’t make them wrong. A customer submitting a case shouldn’t need an account. But every one of those doors is a decision: what can someone do through it, without ever proving who they are? In chapter 1, I called the doors nobody knew were unlocked the invisible bleed, and said AI can now find them. This is the list to check first.

The security guard

Here’s the part I want you to remember. Every door that does require a login sends you to the same place first: the authentication server. I think of it as the security guard at the front of the building. The browser stops there. The integration stops there. Even when a company uses single sign-on, and the person really logs in at the company’s own identity provider, the trip ends back at Salesforce’s authentication server, and that’s the server that lets them in.

That’s why the front door matters so much. There aren’t a hundred separate front doors to guard. There’s one guard, and a set of rules you give it about who gets past.

The wristband

Once you’re let in, you don’t want to prove who you are on every single click. So Salesforce gives you something to show instead.

Think of a food festival. There are dozens of food stalls, and the people cooking don’t have time to check who you are or whether you paid. That’s done at the entrance. You show who you are, you pay, and you get a wristband. Then you go to any stall, show the wristband, and they serve you. The stall never sees your ID. It just checks the wristband.

That wristband is a token. In a browser, it’s the session token your browser holds after you log in. For a client application, it’s the access token it got from the guard. Either way, it’s shown on every request instead of a password, and it’s given out for a short time. When it expires, you go back to the entrance and prove who you are again. Some applications also hold a refresh token, which lets them get a new wristband without going back through the entrance.

Here’s the part to be careful with. While it’s valid, the wristband is the access. The stall doesn’t check your face; it checks the wristband. So whoever holds a valid token gets served, whether or not it’s the person it was given to. A stolen token skips the guard completely, and that’s exactly why attackers, and the AI tools they now use, go looking for tokens. Salesforce says it plainly: “Threat actors can use stolen OAuth tokens to get access to your Salesforce data.” That’s why it now expires refresh tokens that haven’t been used for 30 days, a change it says “limits the window of opportunity to use a stolen or leaked token.” It’s enforced in production orgs on a rolling basis from 4 November 2026 (Refresh Token Idle TTL Is Limited to 30 Days (opens in a new tab), Salesforce Winter ‘27 release notes, checked 2026-11-01).

So treat a token like the access it grants. Keep it short-lived. Keep it where it belongs, and never paste one into an email, a chat or an AI tool. And know how you’d take it back. How long a session lasts, and what else it’s tied to, are decisions you make, and module 3 covers them. Refresh tokens, rotation and the rest of a token’s life are in the Identity and Access course.

Where authentication ends

So where does logging in stop and everything else begin? I put the line here: authentication ends when the user has a valid session token and can start making requests. They’ve come through a door, they’ve passed the guard, and they’re wearing the wristband.

From that moment on, every question is authorization. Which apps, tabs, objects and fields can they see? Those are the offices. Which records? Those are the file cabinets. That’s the rest of this course.

The controls at the door

Where do you set the rules for the guard? In Setup, the controls for getting in are spread across several places. Here’s the tour, and where each one is taught:

• Profiles: password policies, session settings, login hours and login IP ranges. These stay on the profile, and modules 2 to 5 of this chapter cover them.
• Session settings and identity verification in Setup: MFA, session security levels and timeouts. Modules 2 and 3.
• Login flows: a lobby where you can hold people after they log in, before they reach the org. Module 4.
• Single sign-on settings and auth providers: letting another system vouch for who someone is. The Identity and Access course.
• App Manager, connected apps and External Client Apps: the registrations that let client applications in. Since Spring ‘26, new connected apps can’t be created without a request to Salesforce Support; External Client Apps are the replacement, and existing connected apps keep working (New Connected Apps Can No Longer Be Created in Spring ‘26 (opens in a new tab), Salesforce Help, checked 2026-11-01). The Identity and Access and Integration Architect courses go deep on these.
• Sites and Experience Cloud settings: who can reach each site, and what guests can see. Chapter 14 of this course.
• Email settings: which inbound addresses exist and what they create.
• Event Relay: which platform events leave the org for Amazon EventBridge (Event Relay (opens in a new tab), Salesforce Help, checked 2026-11-01).

You don’t need to master all of them in this chapter. You need to know they exist, and that every one is a door somebody can walk through.

What an architect decides here

• Which doors this org actually has open: the login page, sites, public pages, web forms, inbound email, APIs and events.
• For every door with no login, what someone can do through it without proving who they are, and whether that’s on purpose.
• Which kinds of users and programs come in through which door.
• Who owns the settings for each door, so a change to one isn’t made without anyone noticing.

Beyond the exam: what AI changes. The visitors at the client door aren’t only integrations anymore. Agents and other AI clients come in through the same APIs, and they authenticate at the same guard. Who they log in as, and what they’re allowed to do once they’re in, is a question for the Identity and Access course and for Part 3 of this one. At this door, the rule is the same: nothing gets past the guard without proving who it is.

Explore

• Refresh Token Idle TTL Is Limited to 30 Days (opens in a new tab), Salesforce Winter ‘27 release notes (checked 2026-11-01)
• New Connected Apps Can No Longer Be Created in Spring ‘26 (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Event Relay (opens in a new tab), Salesforce Help (checked 2026-11-01)