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

[dependabot]

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

Release notes

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

v0.8.1

Patch Changes

• #234 7b4ba3a Thanks @​threepointone! - Fix uncaught 500 when refreshing a near-expiry grant. A refresh arriving in the final <60s of a grant's life previously passed the expiry check and then crashed with "KV PUT failed: 400 Invalid expiration" because Cloudflare KV rejects absolute expirations less than 60 seconds in the future. Such grants are now treated as expired (returning invalid_grant).

  The refresh handler also re-checks expiry after the tokenExchangeCallback runs, so a slow callback (e.g. an upstream network refresh) that pushes the grant under the 60-second threshold mid-request is rejected cleanly instead of crashing when writing the rotated grant or the new access token (whose TTL is clamped to the grant's remaining lifetime). As defense-in-depth, saveGrantWithTTL also clamps the absolute expiration to KV's 60-second minimum (plus a small margin so writes stay storable under clock skew / write latency).

  The token exchange grant (RFC 8693) shared the same root cause: the issued token's TTL is clamped to the subject token's remaining lifetime, so a subject token in its final <60s (or a expires_in/accessTokenTTL below 60) produced an unstorable token. The exchange now rejects a subject token with under 60s remaining (invalid_grant) and a requested lifetime below 60s (invalid_request) instead of crashing.

  More broadly, any access token lifetime below KV's 60-second minimum is now caught instead of crashing with an opaque KV 400:

  • accessTokenTTL is validated at OAuthProvider construction (must be an integer of at least 60 seconds).
  • A tokenExchangeCallback returning an accessTokenTTL below 60 on the authorization code or refresh grant is rejected with invalid_request.
  • The enterprise-managed authorization (ID-JAG) grant rejects a mapper-supplied access token TTL below 60 (invalid_grant, "Invalid access token TTL").

v0.8.0

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.

... (truncated)

Changelog

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

0.8.1

Patch Changes

• #234 7b4ba3a Thanks @​threepointone! - Fix uncaught 500 when refreshing a near-expiry grant. A refresh arriving in the final <60s of a grant's life previously passed the expiry check and then crashed with "KV PUT failed: 400 Invalid expiration" because Cloudflare KV rejects absolute expirations less than 60 seconds in the future. Such grants are now treated as expired (returning invalid_grant).

  The refresh handler also re-checks expiry after the tokenExchangeCallback runs, so a slow callback (e.g. an upstream network refresh) that pushes the grant under the 60-second threshold mid-request is rejected cleanly instead of crashing when writing the rotated grant or the new access token (whose TTL is clamped to the grant's remaining lifetime). As defense-in-depth, saveGrantWithTTL also clamps the absolute expiration to KV's 60-second minimum (plus a small margin so writes stay storable under clock skew / write latency).

  The token exchange grant (RFC 8693) shared the same root cause: the issued token's TTL is clamped to the subject token's remaining lifetime, so a subject token in its final <60s (or a expires_in/accessTokenTTL below 60) produced an unstorable token. The exchange now rejects a subject token with under 60s remaining (invalid_grant) and a requested lifetime below 60s (invalid_request) instead of crashing.

  More broadly, any access token lifetime below KV's 60-second minimum is now caught instead of crashing with an opaque KV 400:

  • accessTokenTTL is validated at OAuthProvider construction (must be an integer of at least 60 seconds).
  • A tokenExchangeCallback returning an accessTokenTTL below 60 on the authorization code or refresh grant is rejected with invalid_request.
  • The enterprise-managed authorization (ID-JAG) grant rejects a mapper-supplied access token TTL below 60 (invalid_grant, "Invalid access token TTL").

0.8.0

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.

... (truncated)

Commits

• f8e3ddd Version Packages (#235)
• 7b4ba3a fix: never write a sub-60s expiration to KV (avoid uncaught 500s) (#234)
• e77979e Version Packages (#226)
• 624fc56 perf: bound grant pagination when revoking existing grants (#231)
• 591ba5a chore: upgrade Vitest to v4 (#229)
• 64aa241 fix: verify client ownership and honor token_type_hint in revocation (RFC 700...
• d3d1c10 fix: simplify DCR callback rejection shape (#228)
• 917fe92 feat: add clientRegistrationCallback for customizing DCR
• fd6e40b fix: validate token endpoint client authentication
• a1534c4 fix: advertise fragment response mode when implicit flow is enabled
• 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)