A delegated token is an access token issued to act on behalf of a signed-in user, usually for a specific app and set of permissions. For example, a mail app may use a delegated token to read the user’s inbox while the user is present. Defenders should scope tokens tightly and watch for overbroad consent and replay.
What a delegated token looks like in a real workflow
A delegated token is easiest to understand as a short-lived access credential that lets one application act for a user without taking over the user’s identity. In practice, it appears in an on-behalf-of or token-exchange flow, where the app gets a token scoped to the user, the resource, and the permissions it actually needs. The important detail is that the token carries limited delegated authority, not full account power.
A common example is a mail client or productivity app that needs to read a user’s inbox while the user is signed in. The app does not get the user’s password. Instead, it receives a delegated token that authorises only the mailbox action the user approved, and only for as long as the token remains valid. The same pattern applies to other SaaS integrations where a user grants a specific app access to a narrow slice of their data.
Delegated tokens are usually built around explicit delegation semantics, such as actor and subject context, audience restriction, and token downscoping. That matters because the token should describe who granted the access, who or what is acting, and what resource is in scope. For a practical walkthrough of those delegation mechanics, see the OAuth Token Exchange and Delegation Guide.
Why delegated tokens are safer than handing out broad credentials
The security value of a delegated token is that it turns a broad trust decision into a narrow one. A mail app can be allowed to read mail, but not change a password, access unrelated APIs, or impersonate the user elsewhere. That separation reduces blast radius if the app is buggy, abused, or compromised.
Delegated tokens also help preserve auditability. A good implementation can distinguish user-granted access from direct administrative access, which makes it easier to explain why a request succeeded and which app made it. That distinction is especially important when an integration is acting repeatedly on a user’s behalf, because the operational risk is not just the first grant, but the continued use of that grant over time.
The main design challenge is that delegation can be confused with impersonation if the token is too powerful or too loosely scoped. To see how delegation gets abused when tokens are overbroad or stolen, compare the mechanics to token theft cases such as the Salesloft OAuth token breach, where access tokens were enough to reach downstream SaaS data.
What practitioners should check before treating a delegated token as normal
Delegated tokens are only safe when their scope, audience, and lifetime match the use case. If a token can be replayed outside the intended app, reused against other resources, or kept alive far longer than the task requires, it stops behaving like delegated access and starts behaving like a reusable bearer credential. That is where practical risk begins.
Defenders should verify that the token is bound to the intended resource, that consent is narrow, and that refresh or reissuance rules do not quietly expand access over time. A useful mental model is that delegation should shrink authority, not accumulate it. RFC 8693: OAuth 2.0 Token Exchange is the clearest protocol reference for these on-behalf-of and delegation flows, and RFC 9700: Best Current Practice for OAuth 2.0 Security is useful for understanding modern token protection expectations.
Risk and Threat Considerations
Delegated tokens reduce privilege, but they also create a highly attractive replay target because they already represent approved access. If an attacker steals one, they may not need the user’s password or MFA to act within the token’s scope. Overbroad consent, weak audience restriction, and long token lifetime are the conditions that turn a harmless delegation into a durable abuse path.
Failure mechanism: The app, browser session, or integration leaks a bearer token that is still valid for the target resource, and the token can be replayed before expiry or revocation.
Impact: The attacker can perform the delegated action as if authorised by the user, which can expose inbox content, files, API data, or other scoped resources without taking over the full account.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Delegated tokens authenticate nonhuman app-to-resource access on behalf of a user. |
| IA-5 — Authenticator Management | Delegated tokens need lifecycle controls for issuance, scope, expiry, and revocation. | |
| AC-6 — Least Privilege | Delegated tokens should limit what the app can do for the user. | |
| Recommendation — Require token audience binding and service authentication for delegated access flows. Enforce short lifetimes, scoped issuance, and prompt revocation for delegated tokens. Constrain delegated tokens to the minimum permissions needed for the task. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Delegated token flows depend on correct token validation and replay resistance. |
| Recommendation — Validate delegated tokens rigorously and reject replayable or improperly scoped tokens. | ||
Practitioner Guidance
What to verify: Confirm that the token is audience-restricted, short-lived, and issued only for the exact downstream app and resource involved. If the same token can be reused across unrelated services, the delegation model is too loose.
Common mistake: Treating delegated access as inherently low risk because it is “only” user-consented. The real question is whether the consented action is still bounded after issuance, especially when the token can be replayed or refreshed silently.
Decision rule: If a delegated token can read sensitive data or invoke state-changing actions, monitor it like any other privileged bearer credential and be ready to revoke it quickly when consent scope, reuse, or compromise looks suspicious.
Practitioner takeaway: A delegated token is safe only when delegation stays narrow, explicit, and short-lived; the moment it becomes reusable outside that context, it behaves like a credential with the user’s authority attached.