Study guide
Study guide for chapter 9 of the Securing Salesforce: Identity and Access course. Read the five 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, both in its Salesforce as an Identity Provider section, 17% of the exam: choosing the OAuth flow (the web server, user-agent and device flows are named in it) and OAuth’s working parts. The exam guide aligns to Summer ‘23, before PKCE became required and before the user-agent flow’s retirement, so check its current version before you book.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The web server flow (supports IDP-1)
- I can say why an app shouldn’t take a person’s password, or act as one integration user for everyone. (Two answers that don’t work)
- I can walk the web server flow in five steps and three moves. (Five steps, three moves)
- I know the front channel carries only a short-lived code, and the tokens travel on the back channel. (Two channels)
- I know why the app’s client secret matters in the swap. (The business license)
On the wire (supports IDP-3)
- I can read the authorize request:
response_type=code,client_id,redirect_uri,scope,state. (1. The authorize request) - I know the callback URL must match the app’s, and the code lasts 15 minutes. (2. The callback)
- I can read the token request,
grant_type=authorization_code, and its answer, with heridand a refresh token. (3. The token request; The answer) - I know the scope in the authorize request is a subset of the app’s. (1. The authorize request)
PKCE (supports IDP-1, IDP-3)
- I can explain the weakness PKCE closes: a code caught in the browser. (The weakness)
- I know
code_challengegoes in the authorize request andcode_verifierin the token request, and the challenge is the verifier’s SHA-256 hash. (On the wire) - I know PKCE is required for new apps since July 2026 and for ISV apps, and how an org can require it. (Not optional any more)
OpenID Connect (supports IDP-1, IDP-3)
- I know OpenID Connect is the web server flow plus the
openidscope, and adds an ID token. (The same flow, plus openid) - I know what the ID token is (a signed JWT about who signed in and which app asked) and what the UserInfo endpoint returns. (The ID token)
- I know OpenID Connect needs no Enable Identity Provider. (Salesforce as the login for another app)
The derivatives (supports IDP-1)
- I can walk the device flow: the device’s two requests, the user code, the device code, polling, and both codes lasting 10 minutes. (The TV)
- I know the device flow is limited to local external client apps with a localhost callback from November 2026. (The TV)
- I know why the user-agent flow is retiring (the token in the browser) and the date, February 20, 2027. (The token in the browser)
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.
- The person signs in only at Salesforce, never in the app.
- Exact callback URLs, only the ones each app needs.
- PKCE on every app, with the change done in order: the app’s code, then the app, then the org.
- Check the ID token’s signature, and use a
nonce. - Find every app still on the user-agent flow, your own and the ones you install, before February 20, 2027.
- Move device apps to local external client apps with a localhost callback.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Web server flow | The authorization code flow: a code through the browser, swapped for tokens server to server |
| Authorization code | The short-lived claim ticket the browser carries; 15 minutes |
| Authorize endpoint | /services/oauth2/authorize, where the person signs in and approves |
Callback URL (redirect_uri) | Where Salesforce sends the person back; must match the app’s |
state | A value the app makes up and checks on the way back |
| Front channel | The browser, a little less secure |
| Back channel | Server to server, where the tokens travel |
| PKCE | Proof Key for Code Exchange: the pickup word that locks the code to the app |
code_verifier | The pickup word, sent in the token request |
code_challenge | Its fingerprint, a SHA-256 hash, sent in the authorize request |
| OpenID Connect | A layer on OAuth that says who signed in |
| ID token | A signed JWT about who signed in and which app asked |
nonce | A value in the authorize request that helps detect replays |
| UserInfo endpoint | Returns the current user’s basic information |
| Device flow | A code shown on one screen, approved on another, the device polling |
| User code and device code | The code the person types, and the one the device keeps |
| User-agent flow | The implicit grant: the token in the browser; retiring 2027-02-20 |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A web app wants each customer to see their own Salesforce data, and proposes one integration user for all of them. What's wrong?
Every customer would see what the integration user sees, and every change would show the integration user. Use the web server flow, so the app acts as each person, with her own access. Reread Two answers that don’t work.
2. After setting up the web server flow, every approval fails. The client ID is right. Where do you look first?
At the callback URL. The redirect_uri must match one of the app’s callback URLs exactly, or the approval fails. Reread When it goes wrong.
3. A security review asks what stops someone who catches the authorization code in the browser from using it. What do you answer?
PKCE. The app sent only the fingerprint, the code_challenge, with the request; the swap needs the pickup word, the code_verifier, which never left the app. A stolen code alone gets nothing. Reread The pickup word.
4. An admin turns on Require PKCE for the whole org, and two apps stop working. What went wrong?
The order. The apps’ code had to send the challenge and verifier first, then each app in Salesforce, and only then the org setting: it “requires a coordinated change on both the server and clients”. Reread Not optional any more.
5. A web app wants to show "Hello, Priya" after she logs in with Salesforce, and to trust that it's really her. What does it add to the web server flow?
The openid scope. The answer then includes an ID token, signed by Salesforce, saying who signed in and which app asked; the app checks the signature with Salesforce’s keys. Reread The ID token.
6. A team's warehouse scanner uses the device flow through a connected app. What happens on November 30, 2026, and what's the fix?
The device flow is blocked for apps that aren’t local external client apps with a localhost callback URL. Move the scanner to a compliant local external client app. Reread The TV.
7. A mobile app's login puts the access token after a # in the callback address. What is it, and what should it move to?
The user-agent flow, which retires on February 20, 2027, because it exposes the token to the browser. Move it to the web server flow with PKCE. Reread The token in the browser.
Explore
Section titled “Explore”- OAuth 2.0 Web Server Flow for Web App Integration (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.