Study guide
Study guide for chapter 5 of the Securing Salesforce: Identity and Access course. Read the seven modules first; this page helps you check what stuck.
About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.
This chapter carries two of the Identity and Access Management Architect exam’s objectives. Describing common authentication patterns and how they differ is in its Identity Management Concepts section, 17% of the exam. Choosing the right OAuth flow is in its Salesforce as an Identity Provider section, also 17%. Chapters 8 to 11 take each flow step by step. The exam guide aligns to Summer ‘23, so check its current version before you book; it still lists the user-agent flow, which Salesforce is retiring.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The two questions (supports IDC-1)
- I can ask the two questions that choose the door: who starts it (a person, a process or a device), and what it reaches (Salesforce’s own pages, or its data through the API). (Question one, question two)
- I know that, with no person there, a third question decides the flow: an integration user, or a chosen person. (The third question)
- I know both roads end in a session: a browser session for the pages, an access token for the API. (Both roads lead to the same place)
A person in a browser (supports IDC-1)
- I know a person in a browser on Salesforce’s own pages logs in or uses single sign-on, and never needs OAuth. (Why there’s no OAuth in this row)
- I can use the test: if every arrow starts at the browser, it’s single sign-on. (Only arrows from the browser)
A person through an app (supports IDP-1)
- I know the moment one system calls another for the person, it needs OAuth. (The little line)
- I know why an app should never be given a password, and what a token gives instead. (Why not just give it her password?)
- I know the web server flow with PKCE is the flow for a mobile app and for a third-party web server acting for a person, and what PKCE adds. (The flow for both rows)
- I know the user-agent flow exposes the token to the browser and is retiring on 2027-02-20. (If you learned it another way)
- I know what a refresh token is for. (So she isn’t asked every time)
No person there (supports IDP-1)
- I know to ask first whether one integration user is enough, and that it uses the client credentials flow, with the app’s consumer key and secret. (First ask)
- I know what an integration user does to Last Modified By and record access, and that Salesforce recommends one user per integration. (First ask)
- I know the username-password flow is blocked by default in new orgs and retiring for connected apps on 2027-02-20. (First ask)
- I know the JWT bearer flow acts as a chosen person, signed with a certificate, with the app approved in advance, and why it takes so much trust. (JWT bearer: the golden pass)
- I know the SAML bearer assertion flow acts as a person with an assertion from an identity provider you already trust, and that the SAML assertion flow is a different thing. (The SAML bearer assertion)
Devices and things (supports IDP-1)
- I know the device flow starts with a device with little or no keyboard, and a person approves it with a code on another screen. (The smart TV)
- I know the device flow works only for local External Client Apps with a localhost callback from 2026-11-30. (The device flow has been tightened)
- I know the asset token flow is for connected things linked to asset records. (Connected things)
The whole map (supports IDC-1, IDP-1)
- I can place any way into the org in the decision table, and name its door. (The table)
- I can name the retiring mechanisms and what replaces each. (What’s leaving)
Beyond the Exam
Section titled “Beyond the Exam”The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.
- List every way into the org before you design any of them: every group of people, every app, every integration, every device.
- Choose the door from the situation, not from the flow the team already knows.
- When someone says “OAuth for our users” and means people in a browser, they mean single sign-on.
- Ask “should we just use the integration user?” first, and give each integration its own.
- When a requirement says “a specific user”, ask why. If it’s true, choose JWT bearer or the SAML bearer assertion on purpose, and limit who can be named.
- Find every username and password in an integration and move it before the date finds you.
- Approve only a device code you started yourself.
- Keep the master grid beside you. Every chapter from here on fills in a row.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| OAuth | An open standard for giving an app limited access through a token, without handing it a password |
| OAuth flow | One recipe for getting a token: who asks, what they present, what they get back |
| Access token | What an app presents to the API; a session by another name |
| Refresh token | Lets an app get a new access token without asking the person again |
| Web server flow | The person logs in at Salesforce, and the app exchanges a short-lived code for the token |
| PKCE | A one-time secret the app makes for each login, so a stolen code is no use to anyone else |
| User-agent flow | An older flow that returns the token to the browser; retiring 2027-02-20 |
| Integration user | A Salesforce user set up for one integration, not for a person |
| Client credentials flow | An app exchanges its own consumer key and secret for a token, as the integration user |
| Username-password flow | An app sends a username and password for a token; retiring for connected apps 2027-02-20 |
| JWT bearer flow | An app sends a signed message naming the user, checked against an installed certificate |
| SAML bearer assertion flow | An app presents a signed SAML assertion naming the user, for a token |
| SAML assertion flow | For orgs already on SAML single sign-on, reaching the API the same way |
| Token exchange flow | Exchanges a token from a central identity provider for a Salesforce token |
| Device flow | A device shows a code; a person approves it on another screen |
| Asset token flow | A token for a connected thing, linked to an asset record |
| External Client App | Where an app that uses OAuth is registered in Salesforce today |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A project plan says "set up OAuth so the sales team can log in to Salesforce with their company login." What's wrong?
Nothing reaches the API here. The sales team are people in a browser on Salesforce’s own pages, so they need single sign-on through the company’s identity provider, not OAuth. Reread Why there’s no OAuth in this row.
2. On a login diagram, every arrow starts at the browser. Then someone adds a line from the expense app straight to Salesforce. What changed?
The expense app now calls Salesforce’s API itself: one system calling another. That line needs OAuth. With the person there, it’s the web server flow with PKCE. Reread The little line.
3. A vendor's mobile app asks each user for their Salesforce username and password and stores them. What do you recommend?
Stop it. The app effectively impersonates the user, and the only way to stop trusting it is to change the password. Use the web server flow with PKCE, so the user logs in at Salesforce and the app gets a revocable token. Reread Why not just give it her password?
4. A nightly job loads orders from the warehouse system. Who should it run as, and which flow?
First ask whether one integration user is enough. Usually it is: a dedicated integration user for this job, with only the access it needs, on the client credentials flow. Every change will say it was made by that user. Reread First ask.
5. Two integrations share one integration user to save effort. What's the risk?
You can’t tell which integration did what, and both run with the access either one needs, on one secret. If it’s compromised, both are. Salesforce recommends one user per integration. Reread First ask.
6. A requirement says each update from the middleware must show the person it was for, but no one is at the keyboard. What are your options?
A flow that acts as a chosen person: JWT bearer, with a certificate and the app approved in advance for only the users who can be named; or, if that’s too much trust for the security team, the SAML bearer assertion with an identity provider both sides already trust. But first ask whether the requirement is real. Reread The question to ask.
7. An older integration uses the user-agent flow. What happens, and when?
Salesforce retires the user-agent and hybrid user-agent flows on 2027-02-20, and they’re already blocked in orgs created in Winter ‘27. Move it to the web server flow with PKCE. Reread What’s leaving.
8. A warehouse scanner with no keyboard needs to sign in to Salesforce as the worker using it. Which flow?
The device flow: the scanner shows a code, the worker approves it on a phone or computer, and the scanner gets the token. From 2026-11-30, it must be a local External Client App with a localhost callback. Reread The smart TV.
Watch it on video
Section titled “Watch it on video”My 2024 exam preparation video, part 1, walks the exam guide across this part of the course. The note under the video says what’s still right and what’s changed since.
Explore
Section titled “Explore”- OAuth Authorization Flows (opens in a new tab), Salesforce Help (Winter ‘27; checked 2026-11-07)
- Salesforce Certified Platform Identity and Access Management Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-07)
The official list of objectives and their weights. Always check the current version before you book an exam.