v0.3.0

Minor Changes

• #158 b26f7ff Thanks @mattzcarey! - Add clientIdMetadataDocumentEnabled option to make CIMD (Client ID Metadata Document) support explicitly opt-in. Previously, CIMD auto-enabled when the global_fetch_strictly_public compatibility flag was present, which could cause crashes for servers where URL-shaped client_ids hit bot-protected endpoints. When not enabled (the default), URL-formatted client_ids now fall through to standard KV lookup instead of throwing.

• #144 49a1d24 Thanks @mattzcarey! - Add revokeExistingGrants option to completeAuthorization() that revokes existing grants for the same user+client after creating a new one. Defaults to true, fixing infinite re-auth loops when props change between authorizations (issue #34). Set to false to allow multiple concurrent grants per user+client.

  Revoke tokens and grant when an authorization code is reused, per RFC 6749 §10.5. This prevents authorization code replay attacks by invalidating all tokens issued from the first exchange.

  Breaking behavior change: Previously, re-authorizing the same user+client created an additional grant, leaving old tokens valid. Now, old grants are revoked by default. If your application relies on multiple concurrent grants per user+client, set revokeExistingGrants: false to preserve the old behavior.

Patch Changes

• #164 4b640a3 Thanks @pnguyen-atlassian! - Include client_secret_expires_at and client_secret_issued_at in dynamic client registration responses when a client_secret is issued, per RFC 7591 §3.2.1.

• #165 9cce070 Thanks @mattzcarey! - Use Promise.allSettled instead of Promise.all for best-effort grant revocation in completeAuthorization(), ensuring all grants are attempted even if one fails.

v0.2.4

Patch Changes

• #136 a8c5936 Thanks @mattzcarey! - Add /.well-known/oauth-protected-resource endpoint (RFC 9728) for OAuth 2.0 Protected Resource Metadata discovery, as required by the MCP authorization specification. The endpoint is always served with sensible defaults (request origin as resource and authorization server), and can be customized via the new resourceMetadata option.

• #151 dbb150e Thanks @mattzcarey! - Add allowPlainPKCE option to enforce S256-only PKCE as recommended by OAuth 2.1. When set to false, the plain PKCE method is rejected and only S256 is accepted. Defaults to true for backward compatibility.

• #140 65d5cfa Thanks @mattzcarey! - Fix apiHandler route matching when set to '/' to use exact match instead of prefix match, preventing it from matching all routes and breaking OAuth endpoints

• #150 734738c Thanks @mattzcarey! - Fix TypeScript types by making OAuthProviderOptions generic over Env, eliminating the need for @ts-expect-error workarounds when using typed environments

• #145 6ce5c10 Thanks @mattzcarey! - Add RFC 8252 Section 7.3 compliance: allow any port for loopback redirect URIs (127.x.x.x, ::1) to support native apps that use ephemeral ports

• #143 8909060 Thanks @mattzcarey! - Include resource_metadata URL in WWW-Authenticate headers on 401 responses per RFC 9728 §5.1, enabling clients to discover the protected resource metadata endpoint directly from authentication challenges.

v0.2.3

Patch Changes

• #117 b2c5877 Thanks @DeanMauro! - Add getOAuthApi helper function to access OAuthHelpers outside of the fetch method. This enables OAuth functionality in worker RPC methods and other entry points.

• #109 9f118f3 Thanks @bokhi! - fix: path-aware audience validation for RFC 8707 resource indicators. Include request pathname in resourceServer computation for both internal and external token validation. Replace strict equality in audienceMatches() with origin + path-prefix matching on path boundaries. Origin-only audiences (e.g. https://example.com) still match any path (backward compatible). Path-aware audiences (e.g. https://example.com/api) match the exact path and sub-paths (/api/users) but not partial matches (/api-v2).

• #120 155c410 Thanks @DeanMauro! - Add OAuth 2.0 Token Exchange (RFC 8693) support. Clients can exchange an existing access token for a new one with narrowed scopes, a different audience, or a shorter TTL — without requiring the user to re-authorize. Gated behind the allowTokenExchangeGrant option (default false). Also adds scope downscoping (RFC 6749 Section 3.3) to authorization code and refresh token flows.

v0.2.2

Patch Changes

• #129 1e14e05 Thanks @threepointone! - feat: add Client ID Metadata Document (CIMD) support

  (by @mattzcarey in #112)

  CIMD support allows clients to use HTTPS URLs as client_id values that
  point to metadata documents.

  When a client_id is an HTTPS URL with a non-root path, the provider
  fetches and validates the metadata document instead of looking up in KV
  storage. Added validation to ensure client_id in the document matches
  the URL and redirect_uris are present.

  matches the new authorization spec for MCP

  https://modelcontextprotocol.io/specification/draft/basic/authorization

v0.1.0

Minor Changes

• #103 818a557 Thanks @mattzcarey! - feat: add audience validation for OAuth tokens per RFC 7519

v0.0.13

Patch Changes

• #98 0982a1c Thanks @threepointone! - Enhance redirect URI scheme validation for security

  Added a robust helper to validate redirect URI schemes, preventing dangerous pseudo-schemes (e.g., javascript:, data:, vbscript:) with normalization and case-insensitive checks. Expanded test coverage to include bypass attempts using mixed case, whitespace, control characters, and edge cases to ensure comprehensive protection against XSS and related attacks.

v0.0.12

Patch Changes

• #92 5a59d78 Thanks @roerohan! - fix: open redirect vulnerability in completeAuthorization

v0.0.11

Patch Changes

• #78 32560d1 Thanks @rc4! - Use rejection sampling to avoid bias in generateRandomString()

v0.0.10

Patch Changes

• #87 1804446 Thanks @threepointone! - explicitly block javascript: (and other suspicious protocols) in redirect uris

  In #80, we blocked redirects that didn't start with http:// or https:// to prevent xss attacks with javascript: URIs. However this blocked redirects to custom apps like cursor:// et al. This patch now explicitly blocks javascript: (and other suspicious protocols) in redirect uris.

v0.0.9

Patch Changes

• #81 d18b865 Thanks @deathbyknowledge! - Add resolveExternalToken to support external token auth flows

  Adds resolveExternalToken to support auth for external tokens. The callback only runs IF internal auth check fails. E.g. a canonical OAuth server is used by multiple services, allowing server-server communication with the same token.