v26.3.12

v26.3.12

Validate OAuth 2.0 client grant types on creation and update

Ory Hydra now validates the grant_types field when you create or update an OAuth 2.0 client. Adding a grant type the server does not implement — for example a typo like authorize_code — is rejected with an invalid_client_metadata error instead of silently creating a client that cannot complete any flow. This applies to the admin API and to dynamic client registration. Matching folds case, mirroring how the token endpoint matches a client's grant types.

Existing clients keep their grant types and stay fully maintainable through the API: updates, patches, lifespan changes, and secret rotation continue to work for clients that already carry an unrecognized grant type. Only newly added values are validated.

The OpenID Connect discovery document now also advertises the JWT bearer grant (urn:ietf:params:oauth:grant-type:jwt-bearer) in grant_types_supported, matching what the server implements.

If you embed Hydra as a Go library and wire extra grant handlers through driver.WithExtraFositeFactories, also register their grant types with driver.WithExtraGrantTypes; otherwise new clients can no longer be registered with those grant types.

Device authorization grant returns access_denied when the user denies the request

When a user denied a device authorization request (RFC 8628) at the login or consent screen, the device polling the token endpoint never learned about the denial and kept receiving authorization_pending. The poll now returns access_denied as soon as the user denies the request, so devices fail fast instead of appearing to hang. A denied user code can't be used again; the device has to start a new flow.

Thanks to Pete Bacon Darwin for reporting the issue and contributing the consent-denial fix.