CONCEPT Cited by 4 sources

OAuth token lifecycle

The OAuth token lifecycle encompasses the issuance, refresh, introspection, and revocation of access and refresh tokens in an OAuth 2.0 system.

Key Phases

1. Authorization & consent: User grants scoped access to a client application. The user may grant a narrower set than the client requested — an authorization server can issue fewer scopes than asked for. Cloudflare exposes this at the consent UI via optional scopes, letting the user deselect scopes the client marked optional (Source: sources/2026-08-20-cloudflare-from-all-or-nothing-to-task-based-oauth-consent).
2. Token issuance: Authorization server issues an access token (short-lived) and optionally a refresh token (long-lived).
3. Token use: Client presents the access token to resource servers.
4. Token refresh: When the access token expires, the client uses the refresh token to obtain a new pair.
5. Revocation: User or admin revokes tokens, invalidating all associated access.
6. Introspection: Resource servers verify token validity with the authorization server.

Operational Implications

• Expiry tuning as operational lever: Before a database migration, Cloudflare increased token expiry to multiple hours, reducing the number of refresh requests (and therefore database writes) during the upgrade window (Source: sources/2026-06-24-cloudflare-oauth-for-all).
• Refresh token reuse detection: Strict servers (e.g., Ory Hydra 1.x) invalidate the entire token chain if a refresh token is reused, requiring refresh-token-coalescing at the proxy layer.
• Consent-time scope narrowing: When a user deselects optional scopes at consent, the issued access token contains only the consented scopes. Clients must inspect the granted scope set after the code exchange rather than assuming the requested set — see partial-grant-handling (Source: sources/2026-08-20-cloudflare-from-all-or-nothing-to-task-based-oauth-consent).

Seen In

• sources/2026-06-24-cloudflare-oauth-for-all
• sources/2026-08-20-cloudflare-from-all-or-nothing-to-task-based-oauth-consent — consent-time scope narrowing via optional scopes; partial-grant handling
• sources/2026-09-08-databricks-build-durable-agents-with-temporal-and-lakebase — credential-expiry-driven connection-pool refresh in a long-running Worker. The Lakebase client uses OAuth machine-to-machine (M2M) auth; Databricks OAuth tokens and the generated database credentials expire, so the client refreshes its SQLAlchemy connection pool before the one-hour DB credential expires. Without this rotation, a long-running Temporal Worker would hit database failures on a predictable hourly schedule — a concrete operational instance of token-expiry as a first-class lifecycle event that stateful clients must proactively handle (connections use TLS).
• sources/2026-09-24-zalando-agentic-platform-open-sourcing-the-agentic-identity-broker — RFC 8693 Token Exchange as the runtime primitive of an agent identity broker, plus an asymmetric-revocation caveat. Zalando's Agentic Identity Broker exchanges an agent's user-agent token for a target provider's access token per tool call (RFC 8693), refreshing if needed, so the agent never holds a provider token. The post also fast-tracks the broader OAuth lifecycle vocabulary that MCP pressure accelerated: RFC 9728 (Protected Resource Metadata) for discovery and Cross-App Access (XAA) for cross-vendor consent. Sharpest lifecycle caveat on the wiki for the exchange/revocation phases: "a revoked or expired grant blocks future exchanges, but it cannot revoke a provider token that has already been issued" — revocation acts on the grant (future issuance), not on already-minted downstream tokens, so short token lifetimes are the only backstop.

Merged aliases

• refresh-token-invalidation