Request offline access

Request offline access only when a backend must continue acting for a User after the original browser session ends. The principal remains the User; offline access does not turn the client into an autonomous Application or Service Account.

Prerequisites

• An Application OAuth client configured to allow offline access and its maximum lifetime.
• Authorization Code with S256 PKCE for the exact gateway Resource.
• Secure server-side storage for refresh tokens. A browser-only client should normally use session authority.

Request and redeem

Add offline_access alongside the operation scopes needed by the workload:

auth.startAuthorization(resource, {
  scopes: ["mcp:invoke", "offline_access"],
  allowedConnectors: ["internal-tickets"],
});

Complete login, Connection setup, and consent, then redeem the code with the same redirect URI, Resource, and PKCE verifier. An accepted offline authorization creates or reuses an offline GrantBundle and creates a Refresh Family during code redemption. A session root never has a Refresh Family.

Store the returned refresh token as a secret. On refresh, send grant_type=refresh_token, the exact gateway Resource, and the client authentication required by the registered client. Replace the stored refresh token atomically with every successful response: only one generation is active at a time.

Verify

Read the current GrantBundle and confirm root_mode is offline, the intended independent Grants are active, and the operation scope ceiling is no broader than requested. A refreshed gateway bearer remains audience-bound to the same Resource and subject to live Grant, Connection, attachment, and credential checks.

Revocation and replay

Revoking the root or its final active Grant terminates the active Refresh Family. Reusing a consumed refresh generation marks the family compromised and revokes the GrantBundle, so concurrent refreshers must coordinate storage updates. A changed client profile, workload identity, root mode, or gateway Resource replaces incompatible root authority rather than widening it.

For short-lived browser work, omit offline_access. For User-independent gateway work, use autonomous Application authority.