Ory Hydra v26.3.11 released

Ory Hydra

Choose the new secret when rotating an OAuth 2.0 client secret

POST /admin/clients/{id}/secrets/rotate now accepts an optional request body with a client_secret field. Send a value to rotate to that secret instead of a generated one:

{ "client_secret": "your-client-secret" }

The body is optional. Omit it and the endpoint behaves exactly as before, generating a random secret. The supplied secret must be at least 6 bytes. Ory generates 26-byte secrets, so a shorter supplied secret is weaker than a generated one.

Use this when the same client has to carry the same secret in more than one environment. Rotating in each environment separately produces different secrets, and setting a secret through the update or patch client APIs clears the rotated secrets, so the environments disagree about which previous secrets still work. Rotate in one environment, then rotate in the others with the value it returned: every environment ends up with the same current secret and the same grace window.

Ory does not check the supplied value against the client's current or rotated secrets. Supplying the current secret is treated as an ordinary rotation.

The error hint for too-short client secrets on the create, update, and patch client APIs now reads "at least 6 bytes long" instead of "at least 6 characters long", matching how the length is measured.

If you self-host with oauth2.hashers.algorithm set to bcrypt, client secrets longer than 72 bytes now return 400 Bad Request explaining the limit. They previously returned 500 Internal Server Error. This affects creating, updating, patching, and rotating clients. The default pbkdf2 algorithm has no length limit and is unchanged.

Breaking change in the TypeScript SDK

In @ory/client, the positional rotateOAuth2ClientSecret functions returned by OAuth2ApiFp and OAuth2ApiAxiosParamCreator take the optional request body as their second argument, before options. Callers passing Axios options as the second argument must move them to the third. The OAuth2Api class and OAuth2ApiFactory, which take a request-parameters object, are unchanged.

Device codes are now strictly single-use

A device_code can be redeemed only once. When several token requests present the same device_code at the same time, exactly one receives tokens and the others are rejected with invalid_grant.

POST /oauth2/token also reports a device_code that can no longer be redeemed more accurately. It now answers 400 Bad Request with invalid_grant, where it previously answered 500 Internal Server Error with server_error in some cases. A device that retried on 5xx was retrying a device code that could never succeed. It now receives the terminal invalid_grant that RFC 8628 defines, and should start a new device authorization request. The same request also stops answering 500 Internal Server Error when the user rejects the device request while the token request is in flight; it now answers access_denied. No configuration changes are required.

Fix missing ID token in the device authorization grant

The token endpoint did not include an id_token in its response for the OAuth 2.0 device authorization grant (RFC 8628), even when the openid scope was requested and granted. The response was otherwise successful, so the omission was easy to miss. Device flows granted the openid scope now receive a standard OpenID Connect ID token. No action is required.

Symmetric keys no longer break public JSON Web Key responses

A JSON Web Key Set containing a symmetric key, for example an imported HS256 key, caused GET /.well-known/jwks.json to fail with a 500 error when the set was listed in webfinger.jwks.broadcast_keys, and caused hydra get jwk --public to fail with an encoding error.

A symmetric key has no public representation, so these public projections now omit it instead of failing: /.well-known/jwks.json and hydra get jwk --public return the public halves of the remaining keys. For a set whose keys are all symmetric, hydra get jwk --public prints an empty key list. No action is required.

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 Polis, Ory Elements, and Ory Terraform

No significant changes in this release.