Ory Hydra, Ory Kratos, Ory Oathkeeper, Ory Polis, Ory Elements v26.4.10 released

Ory Hydra

JSON Web Keys must follow stricter rules

Ory Hydra Authorization and Ory Kratos Identities now reject a JSON Web Key that breaks one of these rules:

• An RSA key is at most 4096 bits long.

• Base64url-encoded key values, such as n, e, d, x, and k, have no padding, as RFC 7518 requires. A value that ends in = is invalid.

• In an Ed25519 key, x is 32 bytes long and is not a low-order point. In an Ed25519 private key, d is the 32-byte seed, and x is the public key that belongs to it.

Ory Hydra Authorization applies these rules to keys sent to the JSON Web Key API, to the jwks and jwks_uri of OAuth 2.0 clients, and to the keys of trust relationships for the JWT bearer grant. It also requires an HMAC key ("kty": "oct") that signs or verifies a token to be at least 32 bytes long for HS256, 48 bytes for HS384, and 64 bytes for HS512. Ory Kratos Identities applies the rules to the key sets of session tokenizer templates.

Breaking changes

A request that sends a key that breaks one of these rules fails. One such key makes its whole key set invalid: an OAuth 2.0 client whose jwks_uri serves one can't authenticate with private_key_jwt, and a session tokenizer template whose key set contains one fails with 400 Bad Request.

The rules also apply to keys you imported before this release. Ory Hydra Authorization can't load an OAuth 2.0 client, trust relationship, or JSON Web Key set that stores an RSA key longer than 4096 bits or an Ed25519 key that breaks the rules above. If such a key is in hydra.openid.id-token, hydra.jwt.access-token, or a key set listed in webfinger.jwks.broadcast_keys, /.well-known/jwks.json fails with 500 Internal Server Error. If it is in hydra.openid.id-token or hydra.jwt.access-token, issuing ID tokens or JSON Web Token access tokens fails as well. Keys that Ory generates follow every rule.

Replace these keys with keys that follow the rules, for example an RSA key of 4096 bits or less, or an ES256 key. You can delete or overwrite a key that breaks the rules through the JSON Web Key API.

JSON Web Keys must follow stricter rules

Ory Hydra Authorization, Ory Kratos Identities, and Ory Oathkeeper IAM Proxy now reject a JSON Web Key that breaks one of these rules:

• An RSA key is at most 4096 bits long.

• Base64url-encoded key values, such as n, e, d, x, and k, have no padding, as RFC 7518 requires. A value that ends in = is invalid.

• In an Ed25519 key, x is 32 bytes long and is not a low-order point. In an Ed25519 private key, d is the 32-byte seed, and x is the public key that belongs to it.

Ory Hydra applies these rules to keys sent to the JSON Web Key API, to the jwks and jwks_uri of OAuth 2.0 clients, and to the keys of trust relationships for the JWT bearer grant. It also requires an HMAC key ("kty": "oct") that signs or verifies a token to be at least 32 bytes long for HS256, 48 bytes for HS384, and 64 bytes for HS512. Ory Kratos applies the rules to the key sets of session tokenizer templates, whether they are inline, file://, or https:// sources. Ory Oathkeeper applies them to the key sets of the jwt authenticator and the id_token mutator, and oathkeeper credentials generate no longer creates RSA keys longer than 4096 bits.

Breaking changes

A request that sends a key that breaks one of these rules fails, and one such key makes its whole key set invalid.

This includes keys that are already stored. Ory Hydra can't load an OAuth 2.0 client, trust relationship, or JSON Web Key set that stores an RSA key longer than 4096 bits or an Ed25519 key that breaks the rules above. If such a key is in hydra.openid.id-token, hydra.jwt.access-token, or a key set listed in webfinger.jwks.broadcast_keys, /.well-known/jwks.json fails with 500 Internal Server Error. If it is in hydra.openid.id-token or hydra.jwt.access-token, issuing ID tokens or JSON Web Token access tokens fails as well.

Keys that Ory Hydra generates follow every rule, so only imported keys are affected. Stored keys also follow the encoding rule already, because Ory Hydra stores keys without padding.

Before you upgrade, replace these stored keys and any key set file or URL that serves a key breaking one of the rules, for example with an RSA key of 4096 bits or less, or an ES256 key. Ory Hydra can still delete or overwrite a stored key that breaks the rules after the upgrade, through the JSON Web Key API or hydra delete jwks.

Tokens signed before a key rotation stay valid

After you rotated the ID token or JWT access token keys, for example with ory create jwk, Ory Hydra Authorization rejected tokens signed with the previous key, even though the key set still held that key. Introspection reported such JWT access tokens as inactive, the userinfo endpoint rejected them, and the authorization and logout endpoints rejected such an ID token in id_token_hint.

Ory Hydra now checks each token with the key that its kid header names, so these tokens stay valid until they expire or you delete their key. Tokens signed with an EdDSA key now pass these checks as well.

Writing a key that a key set already holds, with PUT /admin/keys/{set} or PUT /admin/keys/{set}/{kid}, no longer makes that key the signing key again. Before, writing back a key set as you read it made its oldest key sign. To make an older key sign again, replace the newer keys with their public halves. hydra import jwk now imports several key files in the order you give them, so the private key of the last file signs, unless the key set already holds its key ID. On MySQL, keys added within the same second have no defined order.

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

Ory Kratos

JSON Web Keys must follow stricter rules

Ory Hydra Authorization and Ory Kratos Identities now reject a JSON Web Key that breaks one of these rules:

• An RSA key is at most 4096 bits long.

• Base64url-encoded key values, such as n, e, d, x, and k, have no padding, as RFC 7518 requires. A value that ends in = is invalid.

• In an Ed25519 key, x is 32 bytes long and is not a low-order point. In an Ed25519 private key, d is the 32-byte seed, and x is the public key that belongs to it.

Ory Hydra Authorization applies these rules to keys sent to the JSON Web Key API, to the jwks and jwks_uri of OAuth 2.0 clients, and to the keys of trust relationships for the JWT bearer grant. It also requires an HMAC key ("kty": "oct") that signs or verifies a token to be at least 32 bytes long for HS256, 48 bytes for HS384, and 64 bytes for HS512. Ory Kratos Identities applies the rules to the key sets of session tokenizer templates.

Breaking changes

A request that sends a key that breaks one of these rules fails. One such key makes its whole key set invalid: an OAuth 2.0 client whose jwks_uri serves one can't authenticate with private_key_jwt, and a session tokenizer template whose key set contains one fails with 400 Bad Request.

The rules also apply to keys you imported before this release. Ory Hydra Authorization can't load an OAuth 2.0 client, trust relationship, or JSON Web Key set that stores an RSA key longer than 4096 bits or an Ed25519 key that breaks the rules above. If such a key is in hydra.openid.id-token, hydra.jwt.access-token, or a key set listed in webfinger.jwks.broadcast_keys, /.well-known/jwks.json fails with 500 Internal Server Error. If it is in hydra.openid.id-token or hydra.jwt.access-token, issuing ID tokens or JSON Web Token access tokens fails as well. Keys that Ory generates follow every rule.

Replace these keys with keys that follow the rules, for example an RSA key of 4096 bits or less, or an ES256 key. You can delete or overwrite a key that breaks the rules through the JSON Web Key API.

JSON Web Keys must follow stricter rules

Ory Hydra Authorization, Ory Kratos Identities, and Ory Oathkeeper IAM Proxy now reject a JSON Web Key that breaks one of these rules:

• An RSA key is at most 4096 bits long.

• Base64url-encoded key values, such as n, e, d, x, and k, have no padding, as RFC 7518 requires. A value that ends in = is invalid.

• In an Ed25519 key, x is 32 bytes long and is not a low-order point. In an Ed25519 private key, d is the 32-byte seed, and x is the public key that belongs to it.

Ory Hydra applies these rules to keys sent to the JSON Web Key API, to the jwks and jwks_uri of OAuth 2.0 clients, and to the keys of trust relationships for the JWT bearer grant. It also requires an HMAC key ("kty": "oct") that signs or verifies a token to be at least 32 bytes long for HS256, 48 bytes for HS384, and 64 bytes for HS512. Ory Kratos applies the rules to the key sets of session tokenizer templates, whether they are inline, file://, or https:// sources. Ory Oathkeeper applies them to the key sets of the jwt authenticator and the id_token mutator, and oathkeeper credentials generate no longer creates RSA keys longer than 4096 bits.

Breaking changes

A request that sends a key that breaks one of these rules fails, and one such key makes its whole key set invalid.

This includes keys that are already stored. Ory Hydra can't load an OAuth 2.0 client, trust relationship, or JSON Web Key set that stores an RSA key longer than 4096 bits or an Ed25519 key that breaks the rules above. If such a key is in hydra.openid.id-token, hydra.jwt.access-token, or a key set listed in webfinger.jwks.broadcast_keys, /.well-known/jwks.json fails with 500 Internal Server Error. If it is in hydra.openid.id-token or hydra.jwt.access-token, issuing ID tokens or JSON Web Token access tokens fails as well.

Keys that Ory Hydra generates follow every rule, so only imported keys are affected. Stored keys also follow the encoding rule already, because Ory Hydra stores keys without padding.

Before you upgrade, replace these stored keys and any key set file or URL that serves a key breaking one of the rules, for example with an RSA key of 4096 bits or less, or an ES256 key. Ory Hydra can still delete or overwrite a stored key that breaks the rules after the upgrade, through the JSON Web Key API or hydra delete jwks.

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

Ory Oathkeeper

JSON Web Keys must follow stricter rules

Ory Hydra Authorization, Ory Kratos Identities, and Ory Oathkeeper IAM Proxy now reject a JSON Web Key that breaks one of these rules:

• An RSA key is at most 4096 bits long.

• Base64url-encoded key values, such as n, e, d, x, and k, have no padding, as RFC 7518 requires. A value that ends in = is invalid.

• In an Ed25519 key, x is 32 bytes long and is not a low-order point. In an Ed25519 private key, d is the 32-byte seed, and x is the public key that belongs to it.

Ory Hydra applies these rules to keys sent to the JSON Web Key API, to the jwks and jwks_uri of OAuth 2.0 clients, and to the keys of trust relationships for the JWT bearer grant. It also requires an HMAC key ("kty": "oct") that signs or verifies a token to be at least 32 bytes long for HS256, 48 bytes for HS384, and 64 bytes for HS512. Ory Kratos applies the rules to the key sets of session tokenizer templates, whether they are inline, file://, or https:// sources. Ory Oathkeeper applies them to the key sets of the jwt authenticator and the id_token mutator, and oathkeeper credentials generate no longer creates RSA keys longer than 4096 bits.

Breaking changes

A request that sends a key that breaks one of these rules fails, and one such key makes its whole key set invalid.

This includes keys that are already stored. Ory Hydra can't load an OAuth 2.0 client, trust relationship, or JSON Web Key set that stores an RSA key longer than 4096 bits or an Ed25519 key that breaks the rules above. If such a key is in hydra.openid.id-token, hydra.jwt.access-token, or a key set listed in webfinger.jwks.broadcast_keys, /.well-known/jwks.json fails with 500 Internal Server Error. If it is in hydra.openid.id-token or hydra.jwt.access-token, issuing ID tokens or JSON Web Token access tokens fails as well.

Keys that Ory Hydra generates follow every rule, so only imported keys are affected. Stored keys also follow the encoding rule already, because Ory Hydra stores keys without padding.

Before you upgrade, replace these stored keys and any key set file or URL that serves a key breaking one of the rules, for example with an RSA key of 4096 bits or less, or an ES256 key. Ory Hydra can still delete or overwrite a stored key that breaks the rules after the upgrade, through the JSON Web Key API or hydra delete jwks.

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

Ory Polis

SCIM group reads report the group's membership

A GET on /Groups/{id} now reports the group's current membership in members. Until now it answered with an empty members list unless the request carried the Polis-specific includeMembers=true parameter, so a standard SCIM client saw every group as empty and could not tell an empty group from one whose members were not reported.

A group listing still reports members only when includeMembers=true is set, because it resolves one membership for every group on the page. Without the parameter the attribute is left out of each listed group rather than returned empty.

A group with more members than DSYNC_MAX_INLINE_GROUP_MEMBERS (500 by default) leaves members out of a read as well, so the group stays readable; includeMembers=true still answers 400 for such a group. Read large memberships through the paginated GET /api/v1/dsync/groups/{groupId}/members endpoint.

A failure reading the membership store is now reported as an error. Until now a failed read ended the membership walk, so the response could report fewer members than the group has, or none, with status 200.

Breaking changes

members is no longer always present on a group response. It is absent on a listed group unless includeMembers=true is set, on a group past the inline limit, and on the response to a create, replace or patch, which report the group rather than its membership. A client that reads members without checking for it first, for example response.members.length, must guard against its absence.

Identity federation apps only accept their own registered redirect URLs

An OIDC identity federation app now accepts a redirect_uri only when it is registered on that app. Before, Polis also accepted a redirect_uri that was registered on the upstream SSO connection the user signed in through, so an endpoint registered to a different relying party could receive the federation app's authorization code.

If a client of a federation app uses a redirect URL that is registered only on an SSO connection, add that URL to the federation app's redirect URLs. Clients that connect to an SSO connection directly are not affected.

SCIM group PATCH applies operations it used to drop, and no longer clears membership by accident

A PATCH on /Groups/{id} whose operation carries no path and an op of add now applies it: members in the value object are added to the group, and a displayName renames it. Until now only a pathless replace was applied, while a pathless add was answered 200 and dropped, so an identity provider recorded a membership change the group never received. An add with a path of displayName renames the group too, as replace with that path already did.

A replace aimed at any other attribute no longer touches the membership. Until now a value carrying members was applied whatever the path named, so a request such as {"op":"replace","path":"externalId","value":{"members":[]}} cleared the group's entire membership and answered 200.

Attribute names in a pathless value are matched case-insensitively, so Members or DisplayName is applied too. As with every other member list, one that is not a list of objects with a string value is rejected with 400 and the scimType invalidValue before any operation in the request is applied, and so is a displayName that is not a string, with or without a path.

Unsupported SCIM list filters return 400

Listing users or groups with a filter that is not a single eq comparison now answers 400 with the scimType invalidFilter. Until now the value was read by splitting the filter on eq, which failed two ways: co, sw, gt and pr raised a server error, while an and, or or not composition succeeded with 200 and a value taken from the middle of the expression, so it answered a filter nobody had asked for. Requests of the second kind now return 400 instead of an empty or wrong list.

Filters of the form <attribute> eq "<value>" are unchanged. The operator is matched case insensitively, and a double-quoted value is decoded as a JSON string, so \" matches a quotation mark, as RFC 7644 requires.

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

Ory Elements

Use Ory Elements in React Router applications with @ory/react-router

The new @ory/react-router package adds Ory Elements login, registration, recovery, verification, and settings pages to React Router 7.9 and later applications in framework mode. This includes Remix v2 applications that upgraded to React Router. Its loader helpers fetch each flow and start a new one when needed. A proxy route serves Ory on your application's domain during local development and on preview deployments. To get started, follow the React Router quickstart.

Use Ory Elements in TanStack Start applications with @ory/tanstack-start

The new @ory/tanstack-start package adds Ory Elements login, registration, recovery, verification, and settings pages to TanStack Start applications. Its server function helpers fetch each flow with the browser's Ory cookies and start a new one when needed. A request middleware serves Ory on your application's domain during local development and on preview deployments. To get started, follow the TanStack Start quickstart.

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

No significant changes in this release.