Delegated access

What it means

Delegated access means one party acts on behalf of another, within limits the second party agreed to. A user lets a calendar app read their events. A manager lets an assistant approve expenses. The helper never receives the user's password, only a limited permission that the user can later withdraw.

OAuth 2.0 is the standard way to do this between applications, and most people have clicked through its consent screen without reading it. RFC 6749 describes it as letting a third-party application obtain limited access to a service, either on behalf of the owner or on its own behalf.

Why it matters

The risk is that the permission is wider or longer-lived than anyone intended. A connected app asked for full account access when it needed to read one folder, and now a breach at that app becomes a breach of your customer's data. Nobody reviewed the grant because it was one click.

For your own product, delegation is a feature customers ask for and an easy place for privilege escalation. If the delegate can do more than the person who delegated, the feature has become a way around your rules, and support staff acting as a customer are the usual example.

How it shows up

You meet it in OAuth consent screens, personal access tokens, "share with" settings, support staff acting on a customer's account, and admin "view as" features. Each has the same questions: what exactly was granted, for how long, and who can take it back.

Common mistakes include scopes that are too broad, tokens that never expire, no screen where the person can see and revoke what they gave, and a delegate able to exceed the delegator's own permissions. Check also that actions taken by a delegate are recorded with both identities in the audit log.