Skip to main content

v26.3.9

v26.3.9​

Limit request bodies to 10 MB​

Ory Hydra now rejects requests whose body is larger than 10 MB, on both the public and the admin API. Most endpoints respond with 400 Bad Request; endpoints that read the access token or client credentials from the request body, such as /userinfo, respond with 401 Unauthorized instead.

Most endpoints were already bounded at the same magnitude, because Go's HTTP server caps form-encoded bodies at 10 MB. This change makes the limit explicit and closes the remaining gaps: multipart form data and JSON documents on the admin API were previously unbounded.

OAuth 2.0 and OpenID Connect requests are a few kilobytes at most, and so are the documents the admin API accepts, so this does not affect normal traffic. The largest payloads you are likely to send are a private_key_jwt client assertion, a signed request object, or an OAuth 2.0 client with an embedded JSON Web Key Set — all far below the limit.

Requests that exceed the limit now report the size as the reason. Previously an oversized form body was reported as an empty body, which pointed at the wrong cause.

Breaking changes​

Integrations that send request bodies larger than 10 MB must reduce the body size before upgrading.

Expired JWT bearer grants no longer issue access tokens​

The token endpoint no longer accepts urn:ietf:params:oauth:grant-type:jwt-bearer assertions for a trusted issuer grant whose expires_at has passed. Previously, such assertions could still be accepted after the grant expired.

If an integration still exchanges assertions against an expired grant, those token requests now fail with invalid_grant. Re-establish the trust relationship with a future expires_at to restore access. Deleted grants and unexpired grants behave as before.

Self-hosted Ory Hydra and Ory Enterprise License users should upgrade to a version containing this fix and can revoke a trusted issuer immediately by deleting the grant. The fix is deployed across the Ory Network, and Ory Network users do not need to take action.

Reject browser-executable URL schemes on OAuth2 clients​

Creating or updating an OAuth2 client now rejects redirect_uris, post_logout_redirect_uris, and frontchannel_logout_uri values whose scheme a browser executes as script (javascript:, data:, vbscript:). Custom native-app schemes such as com.example.app:/callback keep working.

Requests with such values now fail with 400 Bad Request, on the admin client APIs and on OpenID Connect dynamic client registration. A rejected redirect_uris value returns an invalid_redirect_uri error; post_logout_redirect_uris and frontchannel_logout_uri return invalid_client_metadata. These values never worked as OAuth2 endpoints, so no functioning integration is affected.