cloudflare/workers-oauth-provider v0.8.0

v0.8.0

Repository: cloudflare/workers-oauth-provider

Tag: v0.8.0

Published: 2026-06-12T09:32:15Z

Prerelease: no

Release notes:

Minor Changes

• #228 `d3d1c10` Thanks @mattzcarey! - Simplify clientRegistrationCallback to be an allow-or-reject policy hook. Returning undefined allows registration; returning an object rejects registration with optional code, description, and status. Metadata override behavior has been removed.

• #184 `917fe92` Thanks @Talador12! - Add clientRegistrationCallback for validating or rejecting dynamic client registrations before storage. Return undefined/nothing to allow registration, or return an object to reject it. Closes #162.
• Default rejection error follows RFC 7591 §3.2.2 (invalid_client_metadata / 400). Callbacks rejecting for non-metadata reasons (missing IAT, untrusted origin) should override code and status explicitly.
• The request passed to the callback is cloned before the library reads the body, so callbacks may consume the body (e.g. to verify a signature over the raw bytes).
• Callback exceptions are caught and surfaced as 500 server_error.
• software_statement (RFC 7591 §3.1.1) JWTs are not processed by the library; callbacks wishing to honor them must verify the JWT and apply its claims themselves.

Patch Changes

• #231 `624fc56` Thanks @william-canva! - Bound the KV page size used when revoking existing grants during authorization.

• #224 `46cf9b6` Thanks @mattzcarey! - Add Cache-Control: no-store and Pragma: no-cache to OAuth responses that carry tokens, credentials, or OAuth state, matching the response examples in RFC 6749 §5.1/§5.2: token endpoint responses (success and error), dynamic client registration responses carrying client_secret, and EMA JWT-bearer token responses.

• #207 `fd6e40b` Thanks @EfeDurmaz16! - Tighten token endpoint client authentication parsing for RFC 6749 compliance.

• #187 `a1534c4` Thanks @Talador12! - Advertise fragment in response_modes_supported when allowImplicitFlow enables the implicit token response type. RFC 8414 §2 requires authorization server metadata to list supported response modes; RFC 6749 §4.2.2 delivers implicit-flow access tokens through the redirect URI fragment.

• #188 `64aa241` Thanks @Talador12! - Verify client ownership on token revocation (RFC 7009 §2.1) and honor token_type_hint for lookup ordering. Previously any client could revoke any other client's tokens.

• #225 `601f042` Thanks @mattzcarey! - Validate the authorization code and requesting client before acting on a grant during the authorization code exchange.

The /token authorization code grant now verifies the submitted code against the stored code hash and confirms the requesting client matches the grant's client before any single-use replay handling runs. The auth code hash is retained after exchange so that a replayed code can be verified rather than acted upon based on its userId:grantId prefix alone. This ensures a code that does not match the one issued for a grant has no effect on that grant.