Study guide
Study guide for chapter 8 of the Securing Salesforce: Identity and Access course. Read the six 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 four of the Identity and Access Management Architect exam’s objectives. Choosing a flow, an app’s scopes and configuration, and OAuth’s working parts (scopes, secrets, tokens, refresh, expiry and revocation) are in its Salesforce as an Identity Provider section, 17% of the exam. App configuration settings are in its Access Management Best Practices section, 15%. The exam guide aligns to Summer ‘23, so check its current version before you book; it still says “connected app” where Salesforce now builds external client apps.
For the Exam
Section titled “For the Exam”Tick them off as you go. Each one links to where it’s taught.
The base pattern (supports IDP-1, IDP-3)
- I can name the four roles: resource owner, client, authorization server, resource server. (The four roles)
- I know how these flows differ from single sign-on: no browser carrying messages; the client calls the entrance itself. (No browser carrying messages)
- I know the two steps, and that every single-step flow posts to
/services/oauth2/token. (Two steps) - I know the access token is shown as a Bearer token, and lives minutes or hours. (Why bother with an entrance?)
The username-password flow (supports IDP-1)
- I know what it sends (
grant_type=password, the user’s password, and the security token from an untrusted network) and why Salesforce recommends avoiding it. (What the client sends; What’s wrong with it) - I know its tokens can’t be introspected, and it supports no scopes and no refresh tokens. (What’s wrong with it)
- I know it’s off in orgs created from Summer ‘26 and retires on February 20, 2027, and what replaces it. (When it ends; What to use instead)
Client credentials (supports IDP-1, IDP-3, AMB-4)
- I can read a client credentials request:
grant_type=client_credentials, the client ID and secret, on My Domain only. (The request) - I can read its answer:
access_token,instance_url,id,token_type,scope,issued_at,signature. (The answer) - I know it gives no refresh token, and runs as the execution user you set in the app’s policies. (The answer; Who it runs as)
- I know whoever has the client ID and secret can get a token, and how the secret is protected. (The secret is the entrance)
Scopes (supports IDP-2, IDP-3, AMB-4)
- I know scopes are set on the app, and can’t be asked for in a client credentials request. (Where scopes are set)
- I can say what
api,id,refresh_token,openid,webandfullallow, and thatfulldoesn’t bring a refresh token. (A few scopes, in plain words) - I know client credentials filters out
full,webandrefresh_token. (What client credentials can’t get) - I know the two checks at every call: the scope, then the user’s own access. (Two checks at the stall)
The refresh token (supports IDP-3)
- I can read a refresh request:
grant_type=refresh_token, the refresh token, the client ID and secret. (The same request, a different pass) - I know which flows give one (the web server and user-agent flows, with the
refresh_tokenscope) and which don’t. (Which flows give one) - I know what refresh token rotation does. (Why the pass needs care)
- I know how to revoke a token, and that revoking a refresh token revokes its access tokens; and how an app introspects its own tokens. (Taking it back)
The family (supports IDP-1)
- I can say what each single-step flow presents at the entrance, and why the web server flow is different. (Passing something different; The one that’s different)
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.
- Find every integration still on the username-password flow, and block the flow before February 20, 2027 does it for you.
- One app per job, one user per app, each with only what it needs.
- Never
fullfor a program, and only the scopes the job needs for anything else. - Keep client secrets in a secret store, never in code, a chat or an AI tool, and change them on a schedule.
- Send every token request to your My Domain, and every secret in the body or a header, never the URL.
- Turn on refresh token rotation for every app that gets a refresh token, and save each new one.
- Know how you’d take a token back before the day you need to.
Words to Know
Section titled “Words to Know”| Term | In one line |
|---|---|
| Resource owner | Who owns the data and set the ground rules |
| Client | The software that wants the data: an app, a server, an integration, an agent |
| Authorization server | The entrance: Salesforce’s token endpoint, which checks what’s presented and gives out tokens |
| Resource server | The stall: the API that holds the data |
| Token endpoint | /services/oauth2/token on your My Domain |
grant_type | The part of the request that names the flow: password, client_credentials, refresh_token |
| Access token | The wristband: shown as a Bearer token on every call, short-lived |
| Bearer token | A token whoever holds it can use |
| Client ID and secret | The app’s consumer key and consumer secret; for client credentials, the proof itself |
| Execution user | The user a client credentials app runs as |
| Scope | What kinds of access a token carries, set on the app |
full | Every other scope in one: the keys to the whole farm |
| Refresh token | The re-entry pass: swapped for a new access token, never used as one |
| Refresh token rotation | A new refresh token with every refresh, the old one invalidated |
| Revocation | Taking a token back at /services/oauth2/revoke |
| Introspection | Asking the entrance whether a token is still good, at /services/oauth2/introspect |
| Security token | A key added to the end of a password from an untrusted network |
Check Yourself
Section titled “Check Yourself”Short scenarios in the style of the course. Decide your answer before you open it.
1. A developer's script sends a client credentials request to login.salesforce.com, and it fails. The ID and secret are right. What's wrong?
The address. Client credentials doesn’t support login.salesforce.com or test.salesforce.com: send it to your My Domain. Reread The request.
2. A team wants its nightly integration to "ask for the api scope" in the token request. How do you answer?
It can’t ask: scopes aren’t supported in the request. Set the scopes on the external client app, and every token it gets carries them. Reread Where scopes are set.
3. A client credentials app has the api scope, and its Account query works, but its Opportunity query is refused. Why?
The scope is only the first check. The token acts as the execution user, and that user can’t see Opportunities. A scope can’t give more than the user has. Reread Two checks at the stall.
4. An admin adds the refresh_token scope to a client credentials app and expects a refresh token. Will one come back?
No. Client credentials doesn’t support refresh tokens, and Salesforce filters that scope out of this flow. The program goes back to the entrance with its ID and secret when its token runs out. Reread What client credentials can’t get.
5. An old integration signs in with a user's password plus a security token. What do you tell its owner?
It’s the username-password flow: off in orgs created from Summer ‘26 and retiring on February 20, 2027. Move it to client credentials, with its own integration user, and block the old flow. Reread When it ends.
6. A phone app's refresh token may have been copied. What do you do, and what does it take back?
Revoke the refresh token: Salesforce revokes it and every access token it gave out. With rotation on, a copied pass works once at most anyway. Reread Taking it back.
7. Someone says there are a dozen OAuth flows to learn. What's the shortcut?
Most are the same two steps at the same token endpoint, with something different presented: a key and secret, a refresh token, a signed JWT, an assertion, a device code. Learn the pattern, then what each presents. The web server flow is the one that isn’t single-step. Reread Passing something different.
Explore
Section titled “Explore”- OAuth Tokens and Scopes (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.