Reauthorize background jobs when permissions change mid-run

A background job should not inherit unlimited authority from the moment it was queued. Decide authority per operation: snapshot authority for immutable, approved work; reauthorization before sensitive side effects; or a narrow delegated job identity for work meant to outlive the caller’s session.

Reviewed: 2026-09-06

Separate intent from current permission

The queue message should capture who requested the job, which tenant and resources it targets, the approved operation, and an immutable input reference. It should not contain a reusable browser token. A stolen queue message must not become a general API credential.

The NIST least-privilege definition says a security architecture should grant each entity only the minimum resources and authorizations needed for its function. Applied to long-running jobs, minimize both scope and duration of any delegated authority. “Export these 37 invoices” is safer than “read all billing data,” and short-lived authority is safer than authority that remains valid indefinitely.

Authentication also has a different lifetime from business intent. A user can log out while an approved monthly report should still finish; an administrator can suspend that user while an unstarted bulk deletion should stop.

Choose one of three contracts

Snapshot authority means authorization is evaluated once, and the approved job continues against a frozen resource set. This fits an export whose contents must reflect the instant the user requested it. Store the selected record IDs or a database snapshot boundary. Do not rerun a broad query later under stale assumptions.

Continuous reauthorization checks current policy before each meaningful side effect or bounded batch. It fits imports, bulk edits, and destructive workflows. If the user loses permission after row 400, stop before row 401, record partial completion, and make retries aware of what already happened. Checking only at worker startup leaves a long vulnerability window.

Delegated authority gives the job its own narrowly scoped identity. RFC 8693 OAuth 2.0 Token Exchange defines a protocol for requesting and obtaining security tokens from an authorization server, including tokens employing delegation or impersonation semantics. The RFC also notes that token syntax, semantics, and security characteristics are deployment-specific. Whether or not you use token exchange, design delegated job credentials to record the initiating subject, acting job identity, intended audience, permitted actions, and expiry. A scheduled report may run as “report scheduler for tenant 17,” with permission to read a named dataset and write one artifact, independent of the employee’s browser session.

Apply the contract to common jobs

For exports, snapshot the allowed row set, recheck access before delivering the artifact, and expire the download. This prevents a completed archive from bypassing a later revocation.

For batch edits, reauthorize per batch and use idempotency keys. Cancellation should prevent new writes while allowing the worker to finish or roll back the current transaction.

For scheduled reports, use a service or delegated identity owned by the tenant, not the person who originally clicked “schedule.” Revalidate the schedule configuration when recipients or data scope changes.

For approval workflows, the approval is a durable business fact, but each executing step still needs authority. Record the approver, policy version, approved payload hash, and executor. If the payload changes, invalidate the approval.

Define failure and audit semantics

Permission denial is a terminal security outcome, not a transient worker error to retry forever. Mark the job “stopped: authority changed,” retain completed-step evidence, and notify an appropriate owner without exposing protected data. Infrastructure timeouts may retry; explicit denial should not.

Audit records need requester, acting identity, authority mode, resource scope, authorization decision time, policy version, completed effects, and cancellation reason. They should let an investigator distinguish “the user was allowed at enqueue” from “the job was allowed at execution.”

Review every job type and label each side effect snapshot, rechecked, or delegated. Then add a test that revokes permission between two batches and verifies the second batch never commits.