What the Wristband Lets You Do
Module 4 of 6 in the chapter OAuth: The Base Pattern, chapter 8 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: If the token gets you in, what decides what you can do once you’re in?
Not every wristband opens every stall
Section titled “Not every wristband opens every stall”At a food festival, some wristbands get you food, some get you food and drinks, and the one for the staff gets you behind the stalls. The entrance doesn’t just say “you’re in”. It says what you’re in for.
In OAuth, that’s the scope. “Scopes further define the type of protected resources that the client can access” (S2). The access token carries them, and the stall checks them.
When I set up an app in class, this is where I slow down: you need to say what kind of powers you’ll allow coming through. That’s the scope, and it’s on the test.
Where scopes are set
Section titled “Where scopes are set”Scopes are set on the app, when you build it, and “they’re included with the OAuth tokens during the authorization flow” (S2). The caller doesn’t choose them. For client credentials, Salesforce says it outright: “you can’t include scopes in the request. Instead, assign scopes to your external client app” (S1).
So the app is where you make the decision. And it’s an important one: you can have one app that’s limited and a different app that’s more powerful, each for its own job. One app per purpose, each with only the scopes that purpose needs.
A few scopes, in plain words
Section titled “A few scopes, in plain words”Salesforce has a long list (S2). Here are the ones you’ll use and see most:
| Scope | What it allows |
|---|---|
api | “access to the current, logged-in user’s account by using APIs, such as REST API and Bulk API 2.0” |
id | The identity URL service: who the user is (profile, email, address and phone mean the same) |
refresh_token | A re-entry pass, when the flow can give one (module 5); the same as offline_access |
openid | The user’s unique identifier for OpenID Connect, and an ID token (chapter 9) |
web | Use of the token on the web, Visualforce pages included |
full | “all data accessible by the logged-in user, and encompasses all other scopes” |
Look at full. That’s like giving an app the keys to the whole farm. Every other scope, in one. When I set up an app in a demo, I don’t choose full; I choose the one or two the app needs. And even full has a gap people don’t expect: it “doesn’t return a refresh token. You must explicitly request the refresh_token scope to get a refresh token” (S2).
What client credentials can’t get
Section titled “What client credentials can’t get”Here’s the fact that surprises people. A client credentials app can’t have full at all. “Because the client credentials flow doesn’t support UI sessions and doesn’t issue a refresh token, Salesforce automatically filters out these scopes”: full, web, and refresh_token (S1).
So you can’t hand a client credentials app the keys to the whole farm even if you try. For a program with no person there, the scopes that matter are the API ones: api, id, and the product scopes for what it calls.
Test knowledge. In my experience, know where scopes are set (on the app, not in the request), what
fullcovers, and thatfulldoesn’t bring a refresh token. And know that client credentials filters outfull,webandrefresh_token.
Two checks at the stall
Section titled “Two checks at the stall”Now the part an architect has to be clear about. A scope limits the kind of access. It doesn’t decide what data. Look again at Salesforce’s words for api: access to “the current, logged-in user’s account”. The user’s own permissions still apply.
So every call to the stall passes two checks:
- The scope. Is this kind of access on the wristband? A token with only
idcan ask who the user is, and can’t query records; the practice shows it. - The user. May this user see this data? The token acts as its user, with that user’s profile, permission sets and sharing. A scope can’t give more than the user has.
That’s why the integration user matters so much. Give a client credentials app the api scope and an integration user who can see everything, and the program can see everything, through every API. Think about a trading app where every customer’s program runs as one shared user: would you want one customer to see another customer’s money? You would not. The scope keeps the app to the API; the user keeps it to the data. You need both set narrowly (chapter 5, module 4; Integration Architect chapter 13, module 4).
One app, one user, one set of scopes
Section titled “One app, one user, one set of scopes”Salesforce also gives each app its own tokens: “Salesforce grants unique access tokens for each connected app (client) and user combination” (S2). That’s another reason for one app per purpose. Each app’s tokens can be seen, limited and taken back on their own, without breaking the others.
Put it together and you get the pattern I recommend for every integration:
- One app per integration, with only the scopes it needs.
- One user per integration, with only the access it needs.
- Never
fullunless a person really needs a full session, and then not for a program.
What’s next
Section titled “What’s next”Module 5: the re-entry pass, the refresh token.
What an architect decides here
Section titled “What an architect decides here”- The scopes on each app, one or two, never more than the job needs.
- Which user each app runs as, because that decides the data.
- Whether two jobs share an app, or each gets its own.
Explore
Section titled “Explore”- OAuth Tokens and Scopes (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- OAuth 2.0 Client Credentials Flow for Server-to-Server Integration (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)