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.