The Front Door: Logging In to Salesforce

Dette innholdet er ikke tilgjengelig på ditt språk.

Chapter 2 of Securing Salesforce: Sharing and Visibility, Part 1: The Front Door and the Offices. It’s a shared chapter, also part of the Identity and Access course. New to the course? Start with chapter 1.

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. But 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.

In chapter 1, the front door was the first of the building’s three sets of controls: who are you? This chapter answers that question in full. Who you are and how you prove it, from where, when, for how long, and for which kind of user. Then where all those settings live, and how you know the door is still set well next month.

It stays with a person, or a program, logging in. Single sign-on setup, OAuth flows, connected and external client apps, and agent identity belong to the Identity and Access course; this chapter shows where each one meets the door.

The ideas in this chapter

An org has many doors. The login page, sites, web forms, inbound email, APIs and events. Some need a login; some don’t.
One security guard. Every door that needs a login sends you to the same authentication server, even with single sign-on.
The wristband is a token. After you log in, you show a token instead of a password. While it’s valid, the token is the access, so a stolen one skips the guard.
Authentication ends at a valid session. Everything after that is authorization: the offices and the file cabinets.
A password alone no longer opens the door. MFA is required for every employee login, and privileged users need proof that can’t be phished.
Not every second factor is equal. A text-message code can be phished, intercepted, or moved to a new SIM.
Where, when and how long. Login IP ranges block, trusted IP ranges only skip the challenge, login hours close the door at night, and sessions end.
Different users, different doors. Staff, admins, integration users and external users each get their own profile and their own rules. One integration, one identity.
Login flows are a lobby. An extra check after the login, per profile, tested on a test user first.
The profile keeps the door; permission sets carry the keys. Many of something goes on a permission set; only one of something stays on the profile.
Check the door, don’t just set it. Health Check, Login History and, for many orgs, Security Center.

The door

Here’s the picture the whole chapter is built on. A person in a browser doesn’t go straight to their records. They stop at the guard first, prove who they are, and get a session. Then they show that session on every page.

Click to enlarge

Think of a food festival. You show who you are and pay at the entrance, and you get a wristband. Then every food stall serves you because of the wristband, never your ID. That’s a token. It’s why the guard matters so much, and why a stolen token is so dangerous: the stall doesn’t check your face.

The path through this chapter

Five modules, each standing on its own.

The Doors Into Salesforce. How many ways there are into an org, which ones need a login, the security guard every login goes through, the wristband, and where authentication ends.
Proving Who You Are: Passwords and MFA. The three kinds of proof; password policies; MFA for every employee login; phishing-resistant MFA and passkeys for privileged users; why a text message isn’t enough; single sign-on and the proof it must send; session levels and step-up; and backing up your authenticator.
Where, When and How Long: IP Ranges, Login Hours and Sessions. Login IP ranges, and how wide to make them for a company with many offices; trusted IP ranges, good to a point; login hours in the org’s time zone; session timeouts and locking a session to its IP address; and anonymizing networks.
Different Users, Different Doors. Staff, admins, integration users and external users; the integration user that locked itself out; a way back in for admins; and login flows as a lobby before the building.
Checking the Door: What Stays on the Profile, Health Check and Security Center. Where the door’s settings live; Health Check and its weekly notifications; Login History; Security Center for many orgs; and the 2025–2026 changes at the door, dated.

The door has changed more in the last year than in the five before it. Module 5 gathers every change, dated, and each module covers its own.

Click to enlarge

Then check what stuck with the study guide.

What an architect decides here

Which doors the org actually has open, and for every door with no login, what someone can do through it, and whether that’s on purpose.
Which users count as privileged, and that each of them has phishing-resistant MFA, with a backup method.
For single sign-on users, whether the identity provider sends the proof Salesforce needs.
Which profiles need login IP ranges and login hours, wide enough to cover every office, and no wider.
How long a session lasts, shorter for the most privileged users.
That every integration has its own integration user, locked to where it connects from.
How admins get back in if a door setting goes wrong, before anything is tightened.
Which profiles need a login flow, and who tests it first.
Which baseline Health Check measures against, and who reads the weekly notifications.
How the team hears about the next change at the door before it’s enforced.

Beyond the exam: what AI changes. AI shows up first at the front door. It writes better phishing, it hunts for stolen tokens, and it tries from wherever it can hide, around the clock. Salesforce’s answer is stronger proof, asked for more often, where the stakes are highest. And the programs coming through the door now include agents: each one should log in as its own identity, with only the access its job needs. Part 3 of this course and the Identity and Access course go further.

Explore

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

Salesforce Well-Architected: Trust (opens in a new tab), Salesforce Architects (checked 2026-11-01)
Security-Related Product Updates to the Salesforce Platform (opens in a new tab), Salesforce Help (checked 2026-11-01)

Next: Profiles, Permission Sets and Permission Set Groups