The direct answer
Define connector disconnect as separate local-work and remote-credential decisions. Block new admissions under the disabled grant, reject stale worker or refresh completions, and report remote revocation coverage and already-admitted effects according to the evidence actually available.
Make the disconnect contract explicit
A user disconnects a connector while a delegated summary job is waiting. The application removes its enabled flag, but an old worker still holds a credential reference and a refresh request is already in progress. “Disconnected” can hide several unfinished state changes.
Separate local work admission, remote credential/grant lifecycle and resource-server validity information. RFC 9700 says authorization servers may revoke refresh tokens after security events such as logout at that authorization server. That does not establish that a local application's disconnect button automatically performs every remote action.
The example below uses fictional grant G-17 and inert status metadata. No tokens, OAuth flows, jobs, accounts, refresh requests, revocations or model calls were created or exercised. All proposed checks are unrun.
Understand what a token-revocation response means
RFC 7009 specifies token revocation and returns HTTP 200 both when the token was revoked and when an invalid token was submitted. The client must stop using that token after the response. The response is not an inventory proving that every related credential or grant was removed.
The RFC distinguishes support and policy for access-token and refresh-token revocation, including related-token invalidation. It also recognizes a possible propagation delay between servers. Record the documented behavior of the actual authorization server rather than translating a successful response into universal immediate invalidity.
For a timeout or unavailable response, preserve the unresolved remote outcome while keeping the local connector disabled. Never restore ordinary work just because cleanup failed. Conversely, do not describe an acknowledged revocation as merely a failed request: keep the particular response and the unresolved related-token coverage distinct.
Keep a three-part disconnect record
The synthetic application assigns each connection a generation. G-17 generation 8 was enabled when job J-1 was enqueued. At T0, disconnect commits generation 9 as disabled. This generation is trusted application state, not a field the model can choose.
{
"grant_reference": "G-17",
"local_generation": 9,
"local_status": "disabled",
"queued_job_generation": 8,
"remote_revocation": "pending",
"related_token_coverage": "unknown",
"cached_active_observation": "true before T0"
}This is a state card, not an OAuth token or proof of provider behavior. Keep identifiers for affected jobs and credential versions without putting reusable credentials into the record. Track local admission state, remote cleanup disposition and validity-observation time separately.
A narrowly authorized cleanup task may still need to perform revocation after normal connector work is disabled. Give it that limited purpose explicitly; it must not become a general refresh or data-access path. Removing a UI integration and remotely revoking a grant are different operations.
Coordinate generations with work and refresh completion
Coordinate the current enabled generation and the last local admission before dispatch using a supported atomic or fenced operation. A separate check followed by later admission can race disconnect. Define the cutoff precisely: work admitted before T0 may still be in flight or reach the external system later. This design does not promise zero network traffic or instant cancellation after the acknowledgement.
| Proposed event | Expected local decision | Evidence boundary |
|---|---|---|
| Generation-8 job wakes after generation 9 is disabled | Deny admission | No new work authorized by the old grant |
| Worker cached enabled state before T0 | Use coordinated current admission gate | A cached flag is insufficient |
| Refresh started before T0 returns afterwards | Reject installation into the disabled generation | Handle returned credentials under restricted cleanup policy |
| Cached introspection says active | Keep local work denied | Remote validity is not local permission |
| Revocation response is unavailable | Keep disabled; remote cleanup unresolved | No automatic reconnect |
| Token revocation is acknowledged | Stop its use; retain coverage details | No blanket claim about all related tokens |
| User later creates a new connection generation | Require its own authority and job policy | Do not silently rebind old jobs |
| A separately authorized service job exists | Evaluate its explicit service authority | Never substitute it for the disconnected user grant |
Protect refresh-result installation with the same generation coordination. A late success must not overwrite the disabled record. Reconnecting should create an explicit new lifecycle decision rather than undoing disconnect because an asynchronous operation completed.
Do not let cached validity reopen the connection
RFC 7662 defines token introspection and discusses caching its responses. A longer cache duration can leave a resource server using stale information after revocation; a response containing an expiration must not be cached beyond that time.
An active result describes the token according to that introspection context. It is not permission for this application to ignore a locally disabled connection. Likewise, a current local denial is not proof that every external resource server has observed revocation. Avoid collapsing these two statements into one green status.
Record which layer produced the evidence and when. Do not use production tokens to probe remote services merely to fill a confirmation column. Actual authorized integration verification needs its own scope and must not reuse a token after acknowledged revocation.
Report local completion and remaining work separately
A useful status could say that new local admissions are blocked, remote revocation is pending, and one earlier operation has an unresolved outcome. A later response can update the appropriate field without claiming recall of a completed external effect or deletion of already obtained data.
A proposed offline recorder could exercise the matrix, including disconnect racing admission and a late refresh completion. Include a permitted new-generation job as a positive control. This remains unrun and would establish only local state behavior, not a provider's token lifecycle.
Boundary's planned request router does not implement this disconnect coordinator or authorization server. Its separate eight mock policy checks do not validate remote revocation. Keep the eventual release claim limited to the connection paths and lifecycle evidence actually verified.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.