DATE:
AUTHOR:
Ory Team
Ory Network Ory Hydra Ory Kratos Ory Polis Ory Enterprise License

Ory Network, Ory Hydra, Ory Kratos, Ory Polis v26.3.14 released

DATE:
AUTHOR: Ory Team

Ory Network

Custom domains with a timed-out or expired certificate validate again

A custom domain whose certificate validation timed out, or whose certificate expired, stayed in that state until you removed the domain and added it again. Select Refresh on the domain in the Console, or call POST /projects/{project_id}/cname/{cname_id}/revalidate, and Ory asks Cloudflare for a new validation round. If your DNS record points at Ory, the certificate is issued within minutes. Domains that already work are not affected. The action needs the permission to change custom domains.


This is now available on Ory Network.


Ory Hydra

Do not skip this release when upgrading without downtime

This release prepares an optimization to the OAuth 2.0 Device Authorization Grant. A later release completes it.

Deploy this release before that later one. If you run several Ory Hydra instances and upgrade them one at a time, skipping this release can leave a device that finishes signing in mid-upgrade with an access token but no ID token, and no error to explain it.

No action is needed if you run a single instance, or if you accept downtime during upgrades.


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


Ory Kratos

One-time code sessions report the delivery channel

Sessions created with a one-time code now record whether the code was sent by email or SMS. The code entry in authentication_methods carries a channel field set to email or sms, wherever the session is returned: /sessions/whoami, the admin session endpoints, and webhook payloads.

No other authentication method sets the field, so responses for password, social sign-in, and second-factor methods are unchanged.

Set the size limit for Jsonnet mapper input

Ory Identities renders Jsonnet mappers — OIDC claims mappers, webhook bodies, courier templates — in a sandboxed worker process, and the input it sends that worker is limited to 1 MiB. A sign-in carrying a large context can exceed that limit, most often an OAuth2 or OIDC sign-in with many headers, many cookies, or a long return_to URL. That evaluation fails, and nothing else is affected.

The limit is now configurable. Set jsonnet.max_input_size to a byte count:

jsonnet:
  max_input_size: 4194304

or set the JSONNET_MAX_INPUT_SIZE environment variable to the same value. The default is unchanged at 1 MiB, so a deployment that sets nothing behaves as before. The largest accepted value is 4 MiB, which is the size the worker reads with.

Raise it only as far as you need. One worker serves every evaluation in the process and keeps enough memory to hold the largest input it has read.


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

Directory Sync applies SCIM replace and clear operations on group members

SCIM PATCH operations that replace a group's full membership (op: replace with path members, or a pathless replace whose value carries a members list) and operations that clear the membership (op: remove on members without a value) are now applied. Previously these operations returned 200 but were ignored, so group membership in Directory Sync could silently drift from the identity provider. Membership changes applied this way emit the usual group.user_added and group.user_removed webhook events, only for members that actually change. The current membership is processed page by page, so replacing the membership of a group larger than DSYNC_MAX_INLINE_GROUP_MEMBERS works even though inline reads of it do not. On the Redis store, indexed reads are now ordered by creation time so that paging through them is stable.

Attribute paths in group PATCH operations (members, displayName, and the members[value eq "..."] filter form) are matched case-insensitively, as RFC 7643 requires.

A PATCH remove operation without a path is now rejected with 400 noTarget, as required by RFC 7644, instead of being misapplied as an attribute update. A members operation whose value is not a list of member references is rejected with 400 instead of being silently ignored.

SCIM discovery endpoints for Directory Sync

Each directory's SCIM endpoint now serves the SCIM 2.0 discovery endpoints defined in RFC 7644: ServiceProviderConfig, Schemas, and ResourceTypes. Identity providers and SCIM clients can use them to validate the connection and discover which protocol features are supported. The endpoints require the directory's bearer token, the same credential used for the Users and Groups endpoints. No action is required for existing directories.

SCIM error responses now include the status and scimType fields

Error responses from the Polis SCIM endpoints now carry the status attribute required by RFC 7644 and, where the specification defines a keyword for the condition, a scimType attribute. A duplicate user or group returns "scimType": "uniqueness" on its 409.

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
  "status": "409",
  "scimType": "uniqueness",
  "detail": "User already exists"
}

Identity provider integrations that read these machine-readable fields can now tell a permanent uniqueness conflict apart from other failures, instead of matching on the free-text detail. The change is additive: HTTP status codes and successful responses are unchanged, so existing integrations keep working without any action.

Send the SSO connection client secret as a header when deleting a connection

DELETE /api/v1/sso now accepts the connection's client secret in the x-polis-client-secret header. Use it instead of the clientSecret query parameter, which is deprecated but still works.

A secret in a query string ends up in browser history, proxy access logs, and tracing spans. Sending it as a header keeps it out of the URL and reduces that exposure.

To migrate, move the value from the query string to the header:

DELETE /api/v1/sso?clientID=<client-id>
x-polis-client-secret: <client-secret>

If both are sent, the header takes precedence. Deleting by tenant and product is unchanged.

The setup link endpoint DELETE /api/setup/{token}/sso-connection no longer needs a clientSecret query parameter at all — pass only clientID. A secret sent by an older client is ignored. The endpoint now returns 404 instead of 500 when the clientID does not exist.

The admin portal endpoint DELETE /api/admin/connections takes only clientID for the same reason, and now answers 404 for a clientID that does not exist, where it previously reported success.

Store SCIM PATCH values addressed by path inside their schema extension

A SCIM PATCH can address an attribute inside a schema extension in two ways. It can name the extension and pass an object of attributes:

{ "op": "replace",
  "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",
  "value": { "manager": { "value": "61bb1e4c" } } }

Or it can put the attribute in the path and pass its value directly:

{ "op": "replace",
  "path": "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager",
  "value": { "value": "61bb1e4c" } }

Directory sync told the two apart by the type of the value, so the second form was mistaken for the first whenever its value was an object or an array. The attribute was stored as a literal top-level attribute named urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager, beside the extension rather than inside it, where nothing could read it: absent from SCIM responses, unusable in webhook payloads, and untouched by a later remove operation on the same path.

The two forms are now told apart by whether the attribute arrived in the operation's path, so a value is stored inside its extension whether it is a string, an object or an array, and for every schema rather than only the ones this service defines. A SCIM filter in a path, such as roles[value eq "admin"].display, updates the matching entry inside the extension instead of being stored as a literal attribute name.

Every write now also folds attributes left beside an extension by an earlier release back into it, so affected users are repaired as their identity provider next updates them. An attribute already present in the extension is kept in preference to the stray one.


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


Ory Keto, Ory Oathkeeper, Ory Elements, and Ory Terraform

No significant changes in this release.

Powered by LaunchNotes