deps: bump @cloudflare/workers-oauth-provider from 0.3.0 to 0.5.0

[dependabot]

Bumps @cloudflare/workers-oauth-provider from 0.3.0 to 0.5.0.

Release notes

Sourced from @​cloudflare/workers-oauth-provider's releases.

v0.5.0

Minor Changes

• #182 251d641 Thanks @​threepointone! - Prevent unbounded KV namespace growth with TTL defaults, cascade deletes, and garbage collection.

  Default TTLs to prevent unbounded storage growth:

  • refreshTokenTTL now defaults to 30 days (previously infinite). Grants auto-expire via KV TTL. Set to undefined explicitly to restore the previous behavior of never expiring.
  • clientRegistrationTTL (new option) defaults to 90 days. Dynamically registered clients (DCR) auto-expire. Clients created via OAuthHelpers.createClient() are not affected. Set to undefined for clients that never expire.

  deleteClient() now cascades to grants and tokens:

  Previously, deleting a client only removed the client:{id} record, leaving all associated grants and tokens orphaned in KV. Now deleteClient() scans all grants, revokes those belonging to the deleted client (which also deletes their tokens), and then deletes the client record.

  New purgeExpiredData() method for scheduled garbage collection:

  Defense-in-depth cleanup method designed to be called from a Cron Trigger. Processes records in configurable batches (default: 50) to stay within Cloudflare's subrequest limits. Performs two sweep phases: (1) grant sweep removes orphaned grants (client deleted) and expired grants, (2) token sweep removes orphaned tokens (grant deleted). Safe for CIMD clients — grants with URL-based client IDs are never incorrectly treated as orphaned. Available on both OAuthHelpers (via env.OAUTH_PROVIDER.purgeExpiredData()) and directly on OAuthProvider (via oauthProvider.purgeExpiredData(env)) for use in scheduled handlers without a request context.

  New exports: PurgeOptions, PurgeResult

v0.4.0

Minor Changes

• #179 57cdbe9 Thanks @​mattzcarey! - Path-aware resource URIs (RFC 9728):
  • Support path-suffixed well-known URLs for OAuth Protected Resource Metadata (RFC 9728 §3.1). Resources with path components (e.g. https://example.com/mcp) now correctly serve metadata at /.well-known/oauth-protected-resource/mcp and return the derived resource identifier in the resource field.
  • Include the request path in the resource_metadata URL within WWW-Authenticate headers (RFC 9728 §5.1). API endpoints with path components now advertise the correct path-suffixed metadata URL so clients can discover the resource-specific metadata.
  • Add resourceMatchOriginOnly option for seamless migration. When enabled, resource downscoping validation compares only the origin (scheme + host + port) instead of exact URI matching, allowing grants issued before v0.4.0 (with origin-only resources) to work with path-aware resource requests without invalidating existing refresh tokens.

v0.3.3

Patch Changes

• #176 38d1e6b Thanks @​threepointone! - Reverting 0.3.2

v0.3.2

Patch Changes

• #173 1fe656e Thanks @​mattzcarey! - Support path-suffixed well-known URLs for OAuth Protected Resource Metadata (RFC 9728 §3.1). Resources with path components (e.g. https://example.com/mcp) now correctly serve metadata at /.well-known/oauth-protected-resource/mcp and return the derived resource identifier in the resource field.

• #174 ac120ff Thanks @​mattzcarey! - Include the request path in the resource_metadata URL within WWW-Authenticate headers (RFC 9728 §5.1). API endpoints with path components (e.g. /mcp) now advertise the correct path-suffixed metadata URL so clients can discover the resource-specific metadata.

v0.3.1

Patch Changes

• #169 46629cc Thanks @​rlucioni! - Allow any port for localhost redirect URIs to support native apps that use localhost with ephemeral ports like Claude Code

Changelog

Sourced from @​cloudflare/workers-oauth-provider's changelog.

0.5.0

Minor Changes

• #182 251d641 Thanks @​threepointone! - Prevent unbounded KV namespace growth with TTL defaults, cascade deletes, and garbage collection.

  Default TTLs to prevent unbounded storage growth:

  • refreshTokenTTL now defaults to 30 days (previously infinite). Grants auto-expire via KV TTL. Set to undefined explicitly to restore the previous behavior of never expiring.
  • clientRegistrationTTL (new option) defaults to 90 days. Dynamically registered clients (DCR) auto-expire. Clients created via OAuthHelpers.createClient() are not affected. Set to undefined for clients that never expire.

  deleteClient() now cascades to grants and tokens:

  Previously, deleting a client only removed the client:{id} record, leaving all associated grants and tokens orphaned in KV. Now deleteClient() scans all grants, revokes those belonging to the deleted client (which also deletes their tokens), and then deletes the client record.

  New purgeExpiredData() method for scheduled garbage collection:

  Defense-in-depth cleanup method designed to be called from a Cron Trigger. Processes records in configurable batches (default: 50) to stay within Cloudflare's subrequest limits. Performs two sweep phases: (1) grant sweep removes orphaned grants (client deleted) and expired grants, (2) token sweep removes orphaned tokens (grant deleted). Safe for CIMD clients — grants with URL-based client IDs are never incorrectly treated as orphaned. Available on both OAuthHelpers (via env.OAUTH_PROVIDER.purgeExpiredData()) and directly on OAuthProvider (via oauthProvider.purgeExpiredData(env)) for use in scheduled handlers without a request context.

  New exports: PurgeOptions, PurgeResult

0.4.0

Minor Changes

• #179 57cdbe9 Thanks @​mattzcarey! - Path-aware resource URIs (RFC 9728):
  • Support path-suffixed well-known URLs for OAuth Protected Resource Metadata (RFC 9728 §3.1). Resources with path components (e.g. https://example.com/mcp) now correctly serve metadata at /.well-known/oauth-protected-resource/mcp and return the derived resource identifier in the resource field.
  • Include the request path in the resource_metadata URL within WWW-Authenticate headers (RFC 9728 §5.1). API endpoints with path components now advertise the correct path-suffixed metadata URL so clients can discover the resource-specific metadata.
  • Add resourceMatchOriginOnly option for seamless migration. When enabled, resource downscoping validation compares only the origin (scheme + host + port) instead of exact URI matching, allowing grants issued before v0.4.0 (with origin-only resources) to work with path-aware resource requests without invalidating existing refresh tokens.

0.3.3

Patch Changes

• #176 38d1e6b Thanks @​threepointone! - Reverting 0.3.2

0.3.2

Patch Changes

• #173 1fe656e Thanks @​mattzcarey! - Support path-suffixed well-known URLs for OAuth Protected Resource Metadata (RFC 9728 §3.1). Resources with path components (e.g. https://example.com/mcp) now correctly serve metadata at /.well-known/oauth-protected-resource/mcp and return the derived resource identifier in the resource field.

• #174 ac120ff Thanks @​mattzcarey! - Include the request path in the resource_metadata URL within WWW-Authenticate headers (RFC 9728 §5.1). API endpoints with path components (e.g. /mcp) now advertise the correct path-suffixed metadata URL so clients can discover the resource-specific metadata.

0.3.1

Patch Changes

• #169 46629cc Thanks @​rlucioni! - Allow any port for localhost redirect URIs to support native apps that use localhost with ephemeral ports like Claude Code

Commits

• b4bc502 Version Packages (#195)
• 251d641 Prevent unbounded KV namespace growth with TTL defaults, cascade deletes, and...
• 439848c Version Packages (#180)
• 57cdbe9 feat: path-aware resource URIs (RFC 9728) + resourceMatchOriginOnly migration...
• dc350f3 Version Packages (#177)
• 67363f0 revert 0.3.2 due to breaking changes (#178)
• 38d1e6b Add changeset: fix OAuth resource metadata (#176)
• 77bfbf3 Version Packages (#175)
• ac120ff fix: include request path in WWW-Authenticate resource_metadata URL (RFC 9728...
• 1fe656e fix: support path-suffixed well-known URLs for protected resource metadata (R...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #31.