# Design OAuth grants for automation that outlives a user session > Design long-running OAuth automation by separating delegated user access from organization-owned workload identity, with explicit scope, audience, and revocation rules. Canonical URL: https://www.devobs.io/articles/oauth-scopes-for-user-delegated-automation/ By: Lena Fischer Published: 2023-05-28T07:11:33.241Z Updated: 2026-09-06T10:18:15.722Z Section: Identity Do not give unattended automation a copy of the broad token used by an interactive application. Decide whose authority the job exercises, narrow its audience and scopes to that purpose, give it an explicit lifetime, and define what happens when the user, team, or installation disappears. Long-running automation needs a lifecycle contract as much as a consent screen. ## Name the actor and the authority A scheduled report created by Maya may run as Maya, as her team, or as the reporting service. Those are different security decisions. If access should disappear when Maya loses access, use a delegated grant whose authorization remains tied to her. If the job belongs to the organization, create an installation or workload identity with an accountable owner; silently treating Maya's refresh token as organizational authority creates an offboarding trap. Model scopes as operations and protected domains, not UI pages. `reports:generate` for one tenant is clearer than `dashboard:all`. Constrain the audience to the API that accepts the token. A token valid at the report service should not also authorize repository maintenance. [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html) defines OAuth 2.0 token exchange for an HTTP- and JSON-based security token service and includes delegation and impersonation semantics. That vocabulary is useful when you need a downstream token that preserves who the user is and which automation actor is acting. ## Choose the grant by continued authority A short-lived user access token fits work completed during an interactive session. A refreshable delegated grant fits a job that may continue while the user is absent but must remain bounded by that user's authorization. Store refresh credentials server-side, rotate them where supported, and show the grant in the user's connected-app view. Token exchange can produce a narrower downstream token for one service while retaining actor and subject context inside a controlled system. Exchange does not invent authorization: the security token service must decide which client may exchange which subject token for which target. A workload identity fits organization-owned maintenance whose right to run is independent of one employee. It should have its own credentials, tenant binding, purpose, and review cycle. Do not ask for `offline_access` merely because the code runs in the background; first decide whether it is still acting for the user. ## Make consent and revocation operational Consent should say what runs, which resources it reaches, how often, and which organization it affects. Avoid dozens of tiny scopes that people cannot reason about, but do not combine unrelated destructive and read-only operations. For a repository bot, separate reading metadata, creating proposed changes, and merging them. [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html) provides current OAuth 2.0 security best practices, updates earlier guidance to address newer threats and insecure patterns, and deprecates some modes of operation that are considered less secure or insecure. Apply stronger client authentication to confidential automation clients, keep access tokens short-lived, and detect refresh-token reuse when the authorization server supports rotation. Revocation must disable future refresh and prevent newly issued access; already issued self-contained tokens may remain valid until expiry unless resource servers consult current state. Build offboarding hooks for user disabled, team deleted, tenant suspended, integration uninstalled, owner changed, and credential suspected compromised. Record last use, last successful refresh, scope set, audience, owner, and originating consent. Alert on dormant grants before deleting them so business owners can transfer legitimate jobs. For teams building delegated automation and workload identity around standard OAuth flows, we recommend [Ory Hydra on Ory Network](https://www.ory.com/docs/network/hydra) for managed OAuth 2.0 and OpenID Connect that can integrate with existing user management. That is a strong foundation when your application wants to own the specific consent and automation lifecycle while relying on a standards-based authorization server. Evaluate the managed and self-hosted paths separately. Inventory one existing automation now. Write down subject, actor, audience, scopes, owner, expiry, refresh storage, and every revocation trigger. Any blank field is a concrete task before the job receives longer-lived access. ## Source references - - -