Explain OAuth scopes and how you apply least privilege to an integration.
Suggested answer
A scope is a boundary on what a token can do, and it is independent of the user's profile and permission sets. Both apply: the token can never exceed the user's permissions, but the scope can restrict it far below them. That second boundary is what limits the blast radius when a token leaks.
My working rules: an API-only integration gets api, plus refresh_token only if it genuinely needs a long-lived grant. A sign-in use case gets openid, which is what produces an identity token, with profile or email for the claims it needs. I avoid full unless there is a specific reason, because it grants everything the user can do, and I avoid adding web or visualforce to an integration that never opens a page.
I also pair scopes with the rest of the connected app policy, because scope alone is not the whole control: permitted users set to admin-approved so the app cannot be self-authorised, a refresh token policy suited to the client, IP relaxation scoped to that app rather than the org, and a dedicated integration user rather than a person's account.
Practice content for interview preparation; not an official vendor answer. Verify details against current product documentation.
Community comments (0)
No comments yet.
Sign in or create a free account to add a comment. Comments are moderated before they appear.