Ory Hydra, Ory Polis v26.3.12 released

Ory Hydra

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.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Polis

Return the SCIM manager attribute in its complex form

The SCIM endpoint returned the enterprise extension's manager attribute exactly as the identity provider sent it. Microsoft Entra ID sends the manager's user id as a bare string, so a user with a manager assigned came back as:

"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
  "manager": "61bb1e4c-a894-4899-be23-6de941710dbf"
}

RFC 7643 section 4.3 defines manager as a complex attribute, and the Entra ID provisioning client refuses to read that response back. Every user who had a manager assigned failed to provision with SystemForCrossDomainIdentityManagementServiceIncompatible, while users without a manager synced normally.

SCIM responses now return manager as a complex attribute:

"manager": { "value": "61bb1e4c-a894-4899-be23-6de941710dbf" }

Affected users provision on the next sync cycle with no reconfiguration, including users already stored before this release.

Only the SCIM response is normalized. The stored user attributes, the raw attributes on user.created, user.updated and user.deleted webhook events, and the directory sync API all keep the shape the identity provider sent, so no change is needed in your application.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Network, Ory Kratos, Ory Keto, Ory Oathkeeper, Ory Elements, and Ory Terraform

No significant changes in this release.