skip to content

Why would an OAuth 2.0 client ask for one narrow scope at first login and request more later?

level: middleimportance: should knowfreq 44%

answer

  1. ask while the user is there
  2. smaller first screen, higher acceptance
  3. widening means a new authorization request
  4. a new string means fresh approval
  5. read the granted scope again afterwards

basics

~20 s

Incremental requests keep the first consent screen to what the current feature needs. When the user reaches a feature that needs more, the client makes a fresh authorization request carrying the wider scope, and the owner consents to that ask separately.

solid answer

~50 s

A consent screen listing every permission a product might ever want is asking someone to approve things they cannot connect to anything they are doing, and the usual outcome is either a refusal or an approval nobody read. An incremental request splits the ask: the vet's application requests `hives:read hive-notes:read` at sign-in, and only when the vet first records a treatment does it start a **fresh authorization request** carrying `treatments:write` as well. Widening is not something a client can do by itself — the wider ask goes back through the resource owner, because approval is recorded against a set of scope strings and a string outside that set has never been approved. Two client-side consequences follow: read the `scope` member of the new token response rather than assume the old and new sets are merged, and hold a refusal for the session instead of re-prompting into a loop.

code

pseudocode · 8 lines
pseudocode
function record_treatment(grant, note):
    if "treatments:write" not in grant.granted_scope:
        if refused_this_session("treatments:write"):
            return FEATURE_UNAVAILABLE
        start_authorization_request(
            scope = "hives:read hive-notes:read treatments:write")
        return AWAIT_CONSENT
    return call_hive_register(grant.access_token, note)

go deeper

for a junior

Know that a client need not ask for everything at once: it can request a small scope now and start a new authorization request for more when a feature actually needs it.

for a middle

Explain the mechanics — the wider ask is an ordinary authorization request with a bigger scope value, and the client reads the granted scope from the new response instead of assuming a union.

for a senior

Cover the operational side: which features degrade on a narrow grant, how you detect that a grant no longer covers a feature, and how you re-ask without trapping the user in a prompt loop.

for a principal

Set where the permission boundaries fall across a product. One wide grant is cheap to ship and hard to defend; many narrow ones cost every team a re-consent path that has to be designed once and reused.

## The ask that is too big to read The cheapest thing to build is a single authorization request at sign-in that asks for everything the product might eventually need. It is also the ask least likely to be understood. The person approving it is trying to do one thing — look at a hive's health notes — and is being asked to approve recording treatments, reading member records and everything else on the list. What they can do about that is binary: approve the lot, or leave. An **incremental request** moves each part of the ask to the moment it means something. ## What an incremental request actually is There is no special protocol feature here, which is the part candidates most often miss. An incremental request is just **another authorization request** carrying a different `scope` value, run when the client discovers it needs more: - at sign-in, `scope=hives:read hive-notes:read`; - later, when the vet taps *record treatment* for the first time, a new authorization request with `scope=hives:read hive-notes:read treatments:write`; - the resource owner sees an ask that now obviously relates to what they just tried to do. The mechanism that makes this possible is the same one that makes a downgrade possible: the granted scope is whatever the authorization server says it is, reported in the token response, and a client is expected to work from that rather than from its own ambitions. ## Re-consent when the client widens Approval is recorded against a **set of scope strings** for that client. A repeat of a set already approved can usually be answered from that record without disturbing the user; a string outside it has never been approved by anybody, so the wider ask has to be put to them. It is the **widening** that triggers a fresh prompt, not the second visit. This is server policy rather than a protocol mandate — RFC 6749 does not dictate when a consent screen appears — but the shape is near-universal, and designing a client that assumes silent widening produces a product that works only against a server that never checks. ## What the client has to keep track of 1. **The granted scope of the token it currently holds**, taken from the response, not from the request. 2. **Which features each string unlocks**, so a missing string disables a button rather than producing a failed call. 3. **Whether the wider ask has already been refused this session**, so the user is not bounced back to a consent screen they just declined. 4. **What the newest response granted**, because a wider request does not guarantee a union with the older grant; that is the server's policy, and the response says what actually happened. ## When asking up front is still the right call | situation | ask up front | ask incrementally | |---|---|---| | the feature is the entire product | yes — a narrow first grant buys nothing | no | | a rarely used, higher-risk action | no | yes — most users never grant it at all | | the user is mid-task and cannot be interrupted | pre-empt it before the task starts | interrupting here loses the task | | an unattended integration with no person present | the whole set is agreed once, out of band | there is nobody to prompt | ## The failure mode The bad version of incremental asking is the client that re-prompts on every call after a refusal. The user declines, the next screen sends them straight back to the consent screen, and the only escape is to abandon the product. Treat a refusal as information: record it, show the feature as unavailable, and offer a deliberate way to ask again. The protocol gives you the narrow grant; not trapping the person who gave it to you is your side of the bargain.

  • Does the second authorization request return a token that also covers the first scope?
    Only if the server grants the union, which is its policy rather than a guarantee. Ask for every string you still need in the wider request, and read the `scope` member of the response to see what the new token really covers. Treating the earlier grant as automatically folded in is how a client ends up calling an API it no longer has access to.
  • Why does asking for one extra scope string usually show the consent screen again?
    Because approval is recorded against a set of scope strings. A repeat of an already-approved set can be answered from that record; a string outside it has never been approved, so the wider ask is put to the resource owner. The widening triggers the prompt, not the fact that this is a second visit.
  • What should a client do when the wider ask is refused?
    Record the refusal for the session, present the feature as unavailable rather than broken, and keep working with the scope you still hold. Re-prompting immediately turns a considered no into a loop the user can only escape by leaving, and it teaches them to distrust the next screen.

saying these in an interview costs you the question

  • Thinks a client can widen its grant without the resource owner
  • Assumes a consent screen must list every future permission
  • Expects the second token to inherit the first token's scopes
  • Treats re-consent as a server bug rather than a widened ask
  • Asks for write access at sign-in for a read-only feature