chore(deps): bump @cloudflare/workers-oauth-provider from 0.10.1 to 1.2.3

[dependabot]

Bumps @cloudflare/workers-oauth-provider from 0.10.1 to 1.2.3.

Release notes

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

v1.2.3

Patch Changes

• #409 de1f0a6 Thanks @​mattzcarey! - Accept a resource indicator that names the protected resource's URL with extra query parameters. An MCP client configured with https://mcp.example.com/mcp?mode=direct sends that URL as resource; the protected route already covers it (it accepts the resource's tokens and points its 401 at the resource's metadata), but /authorize and /token rejected it with invalid_target. The value now maps to the configured resource, which stays the token audience. Path, port and the resource's own query parameters remain strict.

v1.2.2

Patch Changes

• #398 f5cc398 Thanks @​mattzcarey! - Client ID Metadata Document clients can authenticate with private_key_jwt (RFC 7523). A document that offers only private_key_jwt, which was refused before, now works. The client publishes its keys in jwks or an https: jwks_uri, and signs each token and revocation request with an RS256 or ES256 client assertion. The assertion is checked for iss, sub, aud, exp (at most an hour away) and a single-use jti. A document that offers both none and private_key_jwt, as ChatGPT's does, keeps working with none and may use either method. With CIMD enabled, the authorization server metadata advertises private_key_jwt and token_endpoint_auth_signing_alg_values_supported.

• #402 ec5ece9 Thanks @​mattzcarey! - An ID-JAG whose alg is not in the trusted issuer's algorithms now fails with invalid_alg instead of issuer_not_trusted, so onError shows the real cause. algorithms defaults to ['RS256'], so a resolver for an IdP that signs with ES256 and leaves algorithms unset rejected every assertion as issuer_not_trusted even though the issuer was trusted. The client still gets the same invalid_grant "Invalid assertion".

• #405 612c2f9 Thanks @​mattzcarey! - An empty client_id, client_secret, client_assertion or client_assertion_type at the token endpoint is treated as omitted, as RFC 6749 §3.2 requires. A public client that sends client_secret= with no value now authenticates as none instead of failing with invalid_client, and an empty form parameter next to a Basic header no longer counts as a second authentication method. A non-empty secret or Basic credential on a none client is still refused.

• #395 16572ac Thanks @​mattzcarey! - The enterprise-managed authorization JWKS fetch and the Client ID Metadata Document fetch send User-Agent: workers-oauth-provider/<version> (+https://github.com/cloudflare/workers-oauth-provider). Workers' fetch sends no User-Agent, and WAF rule sets such as AWS WAF's core rule set (NoUserAgent_HEADER) block requests without one, so an IdP behind CloudFront answered the JWKS fetch with 403 and every ID-JAG exchange from it failed with jwks_fetch_failed.

v1.2.1

Patch Changes

• #391 0f0b2cc Thanks @​mattzcarey! - A registration may list redirect URIs the redirect policy refuses, next to one it accepts. Some Cursor versions register cursor://anysphere.cursor-mcp/oauth/callback beside their https and loopback callbacks and sign in with the loopback one; 1.2.0 refused the whole registration because of the cursor:// entry, although 0.10 accepted it. Dynamic registration, createClient() and updateClient() now need at least one redirect URI that follows the policy, and still refuse any with a dangerous scheme, a fragment or userinfo. Every authorization request is still held to the full policy: parseAuthRequest() refuses a refused URI locally, and completeAuthorization() won't send a code to one.

v1.2.0

Minor Changes

• #338 b61bfc0 Thanks @​mattzcarey! - Error redirects back to the client no longer need building by hand. AuthorizationError.redirectTo is the ready-made redirect (error, error_description, state, iss), set only when a redirect is safe, i.e. when redirectUri was validated. authorizationErrorRedirect(request, code, description?) builds the same for an error the application decides on, such as a decline at a third-party provider, from a request the library validated. denyConsent() uses it.

• #339 c801878 Thanks @​mattzcarey! - OAuthHelpers.describeConsent(request) returns what a consent page must show, per the MCP authorization spec: the client's name (or ID), its verified domain for a Client ID Metadata Document client, the redirect URI's hostname, whether the redirect goes to a local app (show a warning), and the scopes. Every string may come from the client, so escape it before rendering.

• #340 b9a0307 Thanks @​mattzcarey! - Redirect URIs must use https, or http on a loopback host (localhost, 127.0.0.0/8, ::1), as MCP and OAuth 2.1 require, with no userinfo or fragment. The rule is enforced at dynamic registration, in createClient() and updateClient() (which previously validated nothing), and on every authorization request and completeAuthorization(), so clients registered before the policy are held to it: their authorizations fail with a locally rendered invalid_request, never a redirect. A Client ID Metadata Document, which every server the client uses reads, may still list other redirect URIs next to a compliant one; only a request that uses one is refused.

  Breaking: clients registered with a remote http redirect URI or a private-use scheme stop authorizing. Native apps that rely on RFC 8252 private-use schemes (com.example.app:/cb) keep working with the new allowPrivateUseRedirectUris: true; remote http is never accepted.

• #381 95924a3 Thanks @​mattzcarey! - A resource's required scopes have their own option, requiredScopes, on OAuthResourceServer and OAuthProvider: the scopes any access needs, published as the protected resource metadata's scopes_supported and named in the 401 challenge, so MCP clients request them first. It sits beside resourceMetadata instead of inside it, where it read like the authorization server's scopesSupported catalogue. It is advertised, not enforced: handlers check ctx.auth.scope, since only they know which scopes imply others. resourceMetadata.scopes_supported still works but is deprecated in favour of requiredScopes; setting both throws at construction.

• #337 9bab931 Thanks @​mattzcarey! - tokenExchangeCallback receives the request's env (TokenExchangeCallbackOptions<Env>['env']), as resolveExternalToken already does. A callback that needs secrets or bindings, such as an upstream OAuth client secret, no longer forces the provider to be rebuilt on every request to close over env.

• #383 d53af65 Thanks @​mattzcarey! - An OAuthResourceServer's validateToken can throw OAuthError to choose the response, as a tokenExchangeCallback already can. temporarily_unavailable with statusCode: 429 and Retry-After passes through; insufficient_scope becomes the MCP 403 challenge naming the new OAuthError requiredScopes option (or the resource's requiredScopes); invalid_token becomes a 401 with the Bearer challenge. Anything else thrown is still a 503. This lets one resource validate an upstream API's own credentials in validateToken before falling back to its authorization server. OAuthProvider's resolveExternalToken and ExternalTokenError are unchanged.

Patch Changes

• #385 ebb2efd Thanks @​mattzcarey! - OAuthAuthorizationServer's authorizeEndpoint and tokenEndpoint are optional and default to ${issuer}/authorize and ${issuer}/oauth/token, under the issuer's path if it has one. OAuthProvider still requires both.

  Construction also rejects any endpoint another would claim, so it could never be reached: a token, registration or authorization endpoint on the metadata path with a query (metadata is served whatever the query), an endpoint that is the token endpoint plus a query, or an authorization endpoint equal to the token or registration endpoint.

• #388 bd97dc1 Thanks @​mattzcarey! - OAuthAuthorizationServer.fetch() no longer writes env.OAUTH_PROVIDER into the caller's env when it answers a path that isn't one of its endpoints. It answers 404 directly; a dead branch meant it fell through to a placeholder handler after setting the helpers, which only the combined OAuthProvider's defaultHandler reads. Use authorizationServer.getOAuthApi(env) for the helpers, as documented.

• #361 36cb1b4 Thanks @​mattzcarey! - tokenExchangeCallback lifetimes no longer fail requests or silently remove expiry. refreshTokenTTL: undefined in a callback result now keeps the provider's lifetime; it used to make the grant never expire, which is what a callback passing through an upstream's missing refresh_expires_in did. refreshTokenTTL is validated (0, or an integer of at least 60 seconds) instead of failing the code exchange with a storage error. Each lifetime is ignored where it doesn't apply, rather than rejected after the callback ran: returning refreshTokenTTL on refresh, or refreshTokenIdleTTL at code exchange or token exchange, used to fail the request after the callback's side effects, such as rotating an upstream refresh token.

• #372 78b3c80 Thanks @​mattzcarey! - createClient() and updateClient() check grant and response types against what the server implements, as dynamic registration does, so a client can no longer be stored with, say, grantTypes: ['implicit'] and then fail every authorization. updateClient() refuses a Client ID Metadata Document client while CIMD is enabled, instead of writing a stored copy that did nothing then and would have become the client if CIMD were later turned off. deleteClient() on a CIMD client revokes its grants, as before, and is now documented as doing so.

... (truncated)

Changelog

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

1.2.3

Patch Changes

• #409 de1f0a6 Thanks @​mattzcarey! - Accept a resource indicator that names the protected resource's URL with extra query parameters. An MCP client configured with https://mcp.example.com/mcp?mode=direct sends that URL as resource; the protected route already covers it (it accepts the resource's tokens and points its 401 at the resource's metadata), but /authorize and /token rejected it with invalid_target. The value now maps to the configured resource, which stays the token audience. Path, port and the resource's own query parameters remain strict.

1.2.2

Patch Changes

• #398 f5cc398 Thanks @​mattzcarey! - Client ID Metadata Document clients can authenticate with private_key_jwt (RFC 7523). A document that offers only private_key_jwt, which was refused before, now works. The client publishes its keys in jwks or an https: jwks_uri, and signs each token and revocation request with an RS256 or ES256 client assertion. The assertion is checked for iss, sub, aud, exp (at most an hour away) and a single-use jti. A document that offers both none and private_key_jwt, as ChatGPT's does, keeps working with none and may use either method. With CIMD enabled, the authorization server metadata advertises private_key_jwt and token_endpoint_auth_signing_alg_values_supported.

• #402 ec5ece9 Thanks @​mattzcarey! - An ID-JAG whose alg is not in the trusted issuer's algorithms now fails with invalid_alg instead of issuer_not_trusted, so onError shows the real cause. algorithms defaults to ['RS256'], so a resolver for an IdP that signs with ES256 and leaves algorithms unset rejected every assertion as issuer_not_trusted even though the issuer was trusted. The client still gets the same invalid_grant "Invalid assertion".

• #405 612c2f9 Thanks @​mattzcarey! - An empty client_id, client_secret, client_assertion or client_assertion_type at the token endpoint is treated as omitted, as RFC 6749 §3.2 requires. A public client that sends client_secret= with no value now authenticates as none instead of failing with invalid_client, and an empty form parameter next to a Basic header no longer counts as a second authentication method. A non-empty secret or Basic credential on a none client is still refused.

• #395 16572ac Thanks @​mattzcarey! - The enterprise-managed authorization JWKS fetch and the Client ID Metadata Document fetch send User-Agent: workers-oauth-provider/<version> (+https://github.com/cloudflare/workers-oauth-provider). Workers' fetch sends no User-Agent, and WAF rule sets such as AWS WAF's core rule set (NoUserAgent_HEADER) block requests without one, so an IdP behind CloudFront answered the JWKS fetch with 403 and every ID-JAG exchange from it failed with jwks_fetch_failed.

1.2.1

Patch Changes

• #391 0f0b2cc Thanks @​mattzcarey! - A registration may list redirect URIs the redirect policy refuses, next to one it accepts. Some Cursor versions register cursor://anysphere.cursor-mcp/oauth/callback beside their https and loopback callbacks and sign in with the loopback one; 1.2.0 refused the whole registration because of the cursor:// entry, although 0.10 accepted it. Dynamic registration, createClient() and updateClient() now need at least one redirect URI that follows the policy, and still refuse any with a dangerous scheme, a fragment or userinfo. Every authorization request is still held to the full policy: parseAuthRequest() refuses a refused URI locally, and completeAuthorization() won't send a code to one.

1.2.0

Minor Changes

• #338 b61bfc0 Thanks @​mattzcarey! - Error redirects back to the client no longer need building by hand. AuthorizationError.redirectTo is the ready-made redirect (error, error_description, state, iss), set only when a redirect is safe, i.e. when redirectUri was validated. authorizationErrorRedirect(request, code, description?) builds the same for an error the application decides on, such as a decline at a third-party provider, from a request the library validated. denyConsent() uses it.

• #339 c801878 Thanks @​mattzcarey! - OAuthHelpers.describeConsent(request) returns what a consent page must show, per the MCP authorization spec: the client's name (or ID), its verified domain for a Client ID Metadata Document client, the redirect URI's hostname, whether the redirect goes to a local app (show a warning), and the scopes. Every string may come from the client, so escape it before rendering.

• #340 b9a0307 Thanks @​mattzcarey! - Redirect URIs must use https, or http on a loopback host (localhost, 127.0.0.0/8, ::1), as MCP and OAuth 2.1 require, with no userinfo or fragment. The rule is enforced at dynamic registration, in createClient() and updateClient() (which previously validated nothing), and on every authorization request and completeAuthorization(), so clients registered before the policy are held to it: their authorizations fail with a locally rendered invalid_request, never a redirect. A Client ID Metadata Document, which every server the client uses reads, may still list other redirect URIs next to a compliant one; only a request that uses one is refused.

  Breaking: clients registered with a remote http redirect URI or a private-use scheme stop authorizing. Native apps that rely on RFC 8252 private-use schemes (com.example.app:/cb) keep working with the new allowPrivateUseRedirectUris: true; remote http is never accepted.

• #381 95924a3 Thanks @​mattzcarey! - A resource's required scopes have their own option, requiredScopes, on OAuthResourceServer and OAuthProvider: the scopes any access needs, published as the protected resource metadata's scopes_supported and named in the 401 challenge, so MCP clients request them first. It sits beside resourceMetadata instead of inside it, where it read like the authorization server's scopesSupported catalogue. It is advertised, not enforced: handlers check ctx.auth.scope, since only they know which scopes imply others. resourceMetadata.scopes_supported still works but is deprecated in favour of requiredScopes; setting both throws at construction.

• #337 9bab931 Thanks @​mattzcarey! - tokenExchangeCallback receives the request's env (TokenExchangeCallbackOptions<Env>['env']), as resolveExternalToken already does. A callback that needs secrets or bindings, such as an upstream OAuth client secret, no longer forces the provider to be rebuilt on every request to close over env.

• #383 d53af65 Thanks @​mattzcarey! - An OAuthResourceServer's validateToken can throw OAuthError to choose the response, as a tokenExchangeCallback already can. temporarily_unavailable with statusCode: 429 and Retry-After passes through; insufficient_scope becomes the MCP 403 challenge naming the new OAuthError requiredScopes option (or the resource's requiredScopes); invalid_token becomes a 401 with the Bearer challenge. Anything else thrown is still a 503. This lets one resource validate an upstream API's own credentials in validateToken before falling back to its authorization server. OAuthProvider's resolveExternalToken and ExternalTokenError are unchanged.

Patch Changes

• #385 ebb2efd Thanks @​mattzcarey! - OAuthAuthorizationServer's authorizeEndpoint and tokenEndpoint are optional and default to ${issuer}/authorize and ${issuer}/oauth/token, under the issuer's path if it has one. OAuthProvider still requires both.

  Construction also rejects any endpoint another would claim, so it could never be reached: a token, registration or authorization endpoint on the metadata path with a query (metadata is served whatever the query), an endpoint that is the token endpoint plus a query, or an authorization endpoint equal to the token or registration endpoint.

• #388 bd97dc1 Thanks @​mattzcarey! - OAuthAuthorizationServer.fetch() no longer writes env.OAUTH_PROVIDER into the caller's env when it answers a path that isn't one of its endpoints. It answers 404 directly; a dead branch meant it fell through to a placeholder handler after setting the helpers, which only the combined OAuthProvider's defaultHandler reads. Use authorizationServer.getOAuthApi(env) for the helpers, as documented.

... (truncated)

Commits

• 602610c Version Packages (#410)
• de1f0a6 fix: accept a resource indicator that adds query parameters the resource does...
• 190a753 Version Packages (#400)
• 612c2f9 fix: treat empty client authentication parameters as omitted (#405)
• ec5ece9 fix: report a disallowed ID-JAG alg as invalid_alg, not issuer_not_trusted (#...
• 732bdec docs: the 1.x resource must match what existing grants carry (#401)
• f5cc398 feat: private_key_jwt client authentication for CIMD clients (#398)
• 16572ac fix: send a User-Agent on JWKS and client metadata fetches (#395)
• 1fafae2 Version Packages (#392)
• 0f0b2cc fix: a registration may list redirect URIs the policy refuses next to one it ...
• 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)