Changelog for Ory Polis OEL
v26.3.13
Identity Federation user identifiers are now unique per upstream connection
The sub claim an OpenID Connect Identity Federation app returns, and the id field its /oauth/userinfo endpoint returns, are
now derived from the upstream connection that authenticated the person as well as from the identifier that connection asserted.
Until now the app passed the upstream identifier through unchanged, so two connections behind one app could return the same
identifier for two different people.
Every identifier an Identity Federation app returns is different after this upgrade. Directly configured SSO connections are unaffected: their identifiers do not change.
The ID token and the /oauth/userinfo response both carry two further claims:
upstream_subholds the identifier the upstream provider asserted. It is permanent, and SAML single logout needs it.legacy_subholds the identifier the app returned before this change, for as long asOPENID_IDFED_LEGACY_SUBJECTistrue. It is there so you can move your existing accounts across.
Moving your accounts across
On each sign-in, look the account up by sub. If you find it, there is nothing more to do. If you do not, look it up by
legacy_sub, and save sub in place of the old identifier.
Key your accounts on sub and on nothing else. Neither legacy_sub nor upstream_sub is unique across the connections behind an
app, so neither can identify an account on its own.
That is about which value identifies an account, not about what you may keep alongside it. If you send SAML single logout requests
you do need to store upstream_sub as well, as a property of the account rather than as its key. See below. legacy_sub is
migration data only: use it to find the account, save sub, and keep nothing. Set OPENID_IDFED_LEGACY_SUBJECT=false once your
applications have finished re-keying; that claim will be removed in a later release.
Single logout
If you send SAML single logout requests, pass upstream_sub as the nameId rather than id. The upstream provider knows the
person by that value; the id an Identity Federation app now returns is scoped to the app, and the provider will not recognise
it.
If you set OPENID_SUBJECT_PREFIX
That prefix, which is off unless you turned it on, no longer applies to Identity Federation apps; the tenant and product of an app
never distinguished one of its upstream connections from another. legacy_sub still reproduces the prefixed identifier your
integration stored, so the lookup above works either way.
If two people shared an identifier
They now receive different ones. The account you already hold follows whichever of them signs in first, and the other is provisioned as a new account, so review those by hand.
Breaking changes
Applications that store the sub or userinfo id of an Identity Federation app stop matching their existing accounts at this
upgrade. Re-key them through legacy_sub as described above before setting OPENID_IDFED_LEGACY_SUBJECT=false. Without that,
everyone signing in through an Identity Federation app appears as a new person.
Applications that send SAML single logout requests with the identifier they stored must switch to upstream_sub. Requests
carrying the new id will not identify the person to the upstream provider.
v26.3.12
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.
26.3.11
This version contains only minor changes and improvements such as dependency updates.
26.3.10
This version contains only minor changes and improvements such as dependency updates.
26.3.9
This version contains only minor changes and improvements such as dependency updates.
26.3.8
This version contains only minor changes and improvements such as dependency updates.
v26.3.7
Require client authentication when exchanging IdP-initiated authorization codes
Polis now requires client authentication on the OAuth token endpoint for authorization codes issued by IdP-initiated SSO flows. A
token request must supply a valid client_secret. Requests that omit all credentials are rejected with
401 Please specify client_secret or code_verifier.
Previously, authorization codes from IdP-initiated flows had no associated session, and every client-authentication branch on the
token endpoint was guarded by that session. A token request that omitted client_id and client_secret skipped all checks and
was issued an access token. Anyone who intercepted such a code could exchange it without knowing the application's client secret.
SP-initiated flows were not affected. Integrations that already send client credentials continue to work unchanged.
Breaking change. Any integration that exchanges an IdP-initiated authorization code without a client_secret (relying on
the previous behavior) now receives 401. To restore access, send client_secret on the token request. If you do not use
per-connection secrets, send the deployment's CLIENT_SECRET_VERIFIER value (which defaults to dummy when unset).
Bind Google Directory Sync OAuth callback to a single-use state
The Google Directory Sync OAuth flow now uses an unguessable, single-use state handle that is stored server-side and bound to
the directory the flow was started for. The callback resolves the directory from that stored record and deletes it on use, instead
of trusting a directoryId supplied in the state query parameter.
Previously the state carried the directoryId with no binding, so a crafted or replayed callback could install one tenant's
Google Workspace tokens onto another tenant's directory (CWE-352). Callbacks with a missing, unknown, or already-used state are
now rejected. Any authorization flow started before the upgrade must be restarted from the directory's authorization URL.
Clean up partially initialized controllers when startup fails
If constructing the Polis controllers fails after the database has been created -- for example when a later initialization step
throws -- controllers() now closes the database and stops the background workers it already started before rethrowing, instead
of leaving their timers and connection pools on the event loop with no close() for the caller to invoke. The database wrapper's
close() now also always clears its stats-reporting interval, even if the underlying driver close rejects.
This affects self-hosted Polis.
Fix SCIM authentication bypass on non-SCIM directories
Public SCIM endpoints now reject requests to directories that do not use SCIM (such as Google), and reject any request that presents an empty or missing bearer token. Previously, directory types that store an empty SCIM secret were authenticated by a request that also carried no token, because a constant-time comparison of two empty values returns true. An attacker who knew a directory id could read and write the tenant's SCIM users and groups without credentials. This affected the self-hosted and OEL distributions; the endpoint is not exposed on the Ory Network.
Fixed a security issue
This release includes a fix for a security issue. Additional details will be shared with customers directly.
Release background timers on shutdown and await webhook batch processing
Embedding Polis and calling the controllers' close() now stops every background timer it started, so the host process can shut
down cleanly. Previously close() left the SSO traces daily cleanup timer and the in-memory store's TTL cleanup timer running,
which kept the Node.js event loop alive after shutdown and forced callers to terminate the process explicitly.
The webhook batch processor now waits for a batch to finish before it returns. EventProcessor.process() previously started
processing without awaiting it, so its error handling never ran and the "already running" guard could clear before a batch
completed, allowing overlapping runs. It now awaits the batch, logs any failure through the configured logger, and holds the run
guard for the full duration.
This affects self-hosted Polis.
SAML IdP Single Logout (SLO) for Identity Federation
Polis can now act as a SAML IdP for Single Logout. When a Service Provider sends a SAML LogoutRequest, Polis initiates an OIDC RP-Initiated Logout against the upstream OIDC provider and returns a signed SAML LogoutResponse to the SP. This mirrors the existing login flow.
SAML responses are protected against assertion replay
Jackson now rejects a SAML response whose assertion has already been used. Each consumed assertion is recorded until it expires, so a captured response can no longer be submitted more than once to obtain a fresh login.
This closes a gap in the IdP-initiated flow. Those responses carry no in-flight request to consume, so previously the same signed response could be replayed within its validity window to mint a new authorization code for the victim on each submission. Service-provider-initiated flows were already protected because their one-time request state is consumed on success.
The anti-replay binding (InResponseTo) is now read only from the signed part of the assertion, so it can no longer be bypassed
by editing the unsigned response wrapper.
Single Logout responses now verify the Identity Provider signature before acting on the response status or request ID, so an unsigned or tampered logout response is rejected outright.
Setup links are now scoped to their service
A setup link is now rejected with 403 when it is used for a service it was not issued for. A Single Sign-On setup link can only
manage SSO connections, and a Directory Sync setup link can only manage directories.
Before, the service on a setup link was not checked at the setup routes, so the holder of a Directory Sync link could create SSO connections for the tenant (and the reverse), which is an authorization bypass. The SSO connection route also no longer accepts the tenant, product, or redirect URLs from the request body; it takes them only from the setup link.
v26.3.6
Harden OIDC discovery URL fetching against SSRF
Creating or updating an OIDC SSO connection with an oidcDiscoveryUrl now validates the fetch target, and the value is
re-validated whenever it is fetched during an authorize or callback flow.
Previously the discovery URL was stored verbatim with no scheme, host or address validation and fetched on every authorize and callback. A caller with an SSO setup link or the deployment API key could point it at an internal address — such as the cloud instance metadata service or an in-cluster service — and read a reachability and response oracle from the resulting SSO trace and error redirect.
The discovery URL now must be an HTTPS URL that does not resolve to a non-public address (loopback, link-local, carrier-grade NAT, private, unique-local, reserved and unspecified ranges for both IPv4 and IPv6, and IPv4-mapped IPv6 literals). Every outbound OIDC request — discovery, token, userinfo and JWKS — is validated at connection time, so a hostname that resolves to an internal address, or one that changes its answer between validation and the request (DNS rebinding), is blocked.
The localhost hostname is now blocked by default, so a connection owner cannot reach services on the loopback interface of the
host or pod. Local development against an IdP on localhost is enabled automatically in a Node development environment, or
explicitly by setting POLIS_ALLOW_LOCALHOST_OUTBOUND=true.
The in-cluster federation tunnel — which rewrites a <slug>.projects.oryapis:8080 discovery URL to the internal hydra-public
service — keeps working unchanged; its rewrite target is a fixed, code-controlled in-cluster service, never taken from the
request. A self-hosted deployment that does not use Ory federation can turn the tunnel off with
POLIS_DISABLE_INTERNAL_ORY_FEDERATION=true, after which a *.projects.oryapis discovery URL is validated like any other host.
Upgrade impact
Because the discovery URL is re-validated on every authorize and callback, an existing OIDC connection whose discovery, token,
userinfo or JWKS endpoint is plain HTTP, localhost, or a private, loopback, link-local or other non-public address will start
failing those flows immediately after upgrading. On Ory Network this is not expected — providers are public HTTPS hosts.
Self-hosted (OEL/OSS) deployments should audit existing OIDC connections before upgrading and re-point any such connection at a
public HTTPS endpoint.
For a self-hosted deployment whose identity provider legitimately runs on an internal network, set
POLIS_ALLOW_PRIVATE_IP_OUTBOUND=true to allow HTTPS fetches to RFC1918 and IPv6 unique-local addresses. The opt-in is narrow:
HTTPS is still required, and link-local (including the cloud metadata address), loopback, carrier-grade NAT and reserved ranges
stay blocked. An IdP on the loopback interface uses POLIS_ALLOW_LOCALHOST_OUTBOUND=true instead.
This path is not exposed through the Ory Network gateway.
Harden SAML metadata URL fetching against SSRF
Creating or updating a SAML SSO connection with a metadataUrl now validates the fetch target against a strict allow list before
and during the request.
The previous check only rejected RFC1918 private IPv4 literals and IPv6 unique-local literals. It let through loopback, link-local
(including the cloud metadata address 169.254.169.254), carrier-grade NAT, reserved and unspecified addresses, every IPv6
literal, and every DNS hostname, and the fetch followed HTTP redirects without re-validating the target. A caller with an SSO
setup link or the SSO API key could use this to read internal endpoints such as the cloud instance metadata service.
The fetch now requires an HTTPS URL, resolves the hostname and rejects any address that is not a public unicast address (covering loopback, link-local, carrier-grade NAT, private, unique-local, reserved and unspecified ranges for both IPv4 and IPv6, and IPv4-mapped IPv6 literals). Resolution happens at connection time, so a hostname that resolves to an internal address — or one that changes its answer between validation and the request (DNS rebinding) — is blocked. Redirects are no longer followed, so a public host cannot redirect the request into an internal address. Unparseable input fails closed.
The localhost hostname is blocked by default so a connection owner cannot reach services on the loopback interface of the host
or pod. Local development against an IdP on localhost is enabled automatically in a Node development environment, or
explicitly by setting POLIS_ALLOW_LOCALHOST_OUTBOUND=true.
Upgrade impact
The previous check allowed localhost and every non-RFC1918 address, so a SAML connection configured with a metadataUrl over
plain HTTP, on localhost, or on a private, loopback or link-local address may now be rejected when its metadata is fetched or
refreshed. On Ory Network this is not expected. Self- hosted (OEL/OSS) deployments should audit existing SAML connections before
upgrading and re-point any such metadataUrl at a public HTTPS endpoint.
For a self-hosted identity provider on an internal network, set POLIS_ALLOW_PRIVATE_IP_OUTBOUND=true to allow HTTPS fetches to
RFC1918 and IPv6 unique-local addresses; HTTPS is still required and link-local (including the cloud metadata address), loopback,
carrier-grade NAT and reserved ranges stay blocked. An IdP on the loopback interface uses POLIS_ALLOW_LOCALHOST_OUTBOUND=true
instead.
This path is not exposed through the Ory Network gateway.
Add YugabyteDB support to Ory Polis
Ory Polis can now use YugabyteDB as its backing database. YugabyteDB is PostgreSQL wire-compatible, so it reuses the existing PostgreSQL driver and needs no additional dependencies. This gives self-hosted and enterprise deployments a distributed, horizontally scalable storage option alongside the existing engines (PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, SQLite, CockroachDB, MongoDB, Redis, PlanetScale, and DynamoDB).
Configuration
Select YugabyteDB by setting the SQL engine and the yugabytedb type, then point the connection URL at your YugabyteDB YSQL
endpoint (default port 5433):
DB_ENGINE=sql
DB_TYPE=yugabytedb
DB_URL=postgresql://yugabyte@localhost:5433/yugabyte
Fix cross-tenant admin takeover through SAML admin-portal login
The Polis Admin Portal SAML login now accepts a login only when it went through the Admin Portal's own SSO connection. Previously
both the IdP-initiated (boxyhq-saml-idplogin) and SP-initiated (boxyhq-saml) flows trusted a login completed against any
tenant's SSO connection in the deployment. An attacker could complete a SAML login against a connection they control and receive
an Admin Portal session with read and write access to every tenant's SSO connections and secrets.
The fix pins the resolved connection's tenant and product to the Admin Portal defaults (_jackson_boxyhq /
_jackson_admin_portal) and rejects anything else — in the IdP-initiated provider's authorize() and in the sign-in callback for
the SP-initiated provider.
This affects self-hosted Polis (OSS) and the polis-oel chart. It is not reachable on the Ory Network, where the gateway does not
route /api/auth/** to Polis.
Fix cross-tenant data leak in concurrent SCIM directory-sync requests
SCIM directory-sync requests could leak users and groups across tenants when two requests for different directories were processed at the same time.
The request handler bound the directory's tenant and product onto a single, process-wide store instance that every request shared.
Because that binding was read again at each database call after intervening awaits, a second request for a different directory
could overwrite it mid-flight. A user or group created for directory A could then be written into directory B's namespace:
directory B's directory-sync APIs would return directory A's data, while directory A's own read returned nothing even though it
received 201 Created.
The handler now binds a request-scoped copy of the store per request, so concurrent requests can never observe one another's
tenant and product. The directory-sync admin and management API routes (/api/v1/dsync/*, /api/admin/directory-sync/*) were
bound the same way and are migrated too, which closes a related window where a concurrent read could redirect a "delete all
webhook events" request to another tenant's namespace. This affects self-hosted Polis; SCIM is not routed through the Ory Network
gateway.
Reject SAML responses that declare a DTD and stop leaking parser errors
The SAML assertion consumer service (POST /api/oauth/saml) parsed the base64-decoded SAMLResponse with document type
definition (DTD) processing enabled. Because a SAML response never legitimately contains a DTD, this exposed the XML parser to
XXE-class attacks: a crafted DOCTYPE with a SYSTEM entity produced different parser errors depending on whether a referenced
path existed, giving an unauthenticated caller a file-existence oracle. Internal parser error text was also returned to the caller
through the polis_error cookie, which made the differential observable.
Polis now rejects any SAML response that declares a DOCTYPE/DTD before it reaches the parser, and returns a generic error to the
client. Internal error detail is logged server-side only and is no longer disclosed to the caller: the polis_error cookie
returns a generic message for server errors, and the OAuth error_description returned on the redirect no longer includes raw
parser or exception text. Standard OAuth error codes and OIDC provider error descriptions are still forwarded.
Reject invalid magic-link tokens in the Polis admin portal
The admin-portal magic-link (email) sign-in accepted any token value. The next-auth adapter looked up the stored verification
token by email but returned the record without checking that the presented token matched it. Because next-auth treats any non-null
adapter result as valid and the portal grants the admin role to every address, an unauthenticated attacker could complete the
email callback for any address — including an administrator's — with an arbitrary token and receive an authenticated admin
session. This required magic-link login to be enabled (NEXTAUTH_ACL set together with an SMTP host); a default install with
NEXTAUTH_ACL unset was not affected.
Polis now returns the verification token only when the presented value matches the stored one, and consumes it on that single successful use. Non-matching or missing tokens are rejected, closing the bypass (GHSA-j4rr-hrm4-hx4j).
Validate SAML SingleLogout URLs to prevent stored XSS and open redirect
SAML connection metadata is now scheme-checked on its SingleLogout (SLO) bindings, not just its login (SSO) bindings. Previously,
the SingleLogoutService Location from an identity provider's metadata was stored without validation and later written into the
auto-submitting form and redirect served by the unauthenticated /api/logout endpoint. A javascript: URL placed in that field
executed in the browser of anyone who opened the tenant's logout link (stored cross-site scripting), and a crafted redirect
binding could send that visitor to an arbitrary host (open redirect).
Creating or updating a SAML connection now rejects any SLO Location that does not use an http or https scheme, matching the
check already applied to SSO bindings. The localhost allowance in that check now also requires an http/https scheme:
previously it inspected only the host, so a javascript://localhost/... URL parsed with hostname localhost and slipped through.
As defense in depth, the logout request builder re-checks the SLO scheme at the point of use, so a connection that already carries
a malicious SLO URL can never emit it into the /api/logout form or redirect. Existing connections that carry a malicious SLO URL
should still be recreated or updated so the stored value is revalidated.
Validate the post-logout redirect URL in SAML Single Logout
The unauthenticated GET /api/logout endpoint accepted a redirectUrl query parameter and, after the identity provider completed
Single Logout, redirected the browser to it without checking it against the connection's configured redirect URL allow-list. An
attacker could send a victim a logout link with an arbitrary redirectUrl and have Polis redirect them to an external origin
(open redirect, CWE-601).
Polis now validates redirectUrl against the connection's allow-list when the logout request is created and rejects a disallowed
or malformed value with 403 Redirect URL is not allowed. — the same check the OAuth authorize flow applies to redirect_uri. If
a stored value no longer matches the connection resolved from the logout response, the callback falls back to the connection's
defaultRedirectUrl.
This affects self-hosted Polis (OSS and OEL). The Ory Network gateway does not expose /saml/api/logout and is not affected.
26.3.5
This version contains only minor changes and improvements such as dependency updates.
26.3.4
This version contains only minor changes and improvements such as dependency updates.
26.3.3
This version contains only minor changes and improvements such as dependency updates.
26.3.2
This version contains only minor changes and improvements such as dependency updates.
v26.3.1
Serve Polis over HTTPS with a built-in TLS sidecar
The Polis Helm chart can now terminate TLS in front of Polis without an external ingress. Set tlsSidecar.enabled: true and point
tlsSidecar.tls.secretName at an existing Secret that holds tls.crt and tls.key (managed by you or cert-manager):
tlsSidecar:
enabled: true
tls:
secretName: polis-tls
The chart then runs an nginx sidecar that terminates HTTPS and proxies to Polis in the same pod. The Service keeps the same port
and name; when the sidecar is enabled the Service routes to it (HTTPS) instead of the plain-HTTP Polis listener, so plain HTTP is
no longer served. The sidecar image defaults to docker.io/nginxinc/nginx-unprivileged:stable and is overridable via
tlsSidecar.image.
The feature is off by default, so existing deployments are unchanged and continue to serve plain HTTP.
For advanced cases, the chart also exposes deployment.extraContainers, deployment.extraVolumes,
deployment.extraVolumeMounts, and deployment.extraEnvs to add arbitrary sidecars or volumes.
26.3.0
This version contains only minor changes and improvements such as dependency updates.
v26.2.22
Fix cross-tenant identity provider selection via idp_hint in Polis
The idp_hint parameter on the SAML Identity Federation and SSO endpoints selected an upstream identity provider connection by id
without checking that the connection belonged to the requesting tenant and product. On a multi-tenant deployment, a co-tenant
could supply the id of a connection in their own tenant as idp_hint for another tenant's federation app, routing the login to an
identity provider they control and obtaining a Polis-signed assertion audienced to the victim's downstream service provider.
Polis now scopes the hinted connection to the requesting flow. A hint is accepted only when the connection belongs to the
requested tenant and product, to one of a multi-tenant federation app's tenants, or — for IdP-initiated SSO — to the identity
provider that issued the response. Out-of-scope hints are rejected with 403. The upstream-response callback re-checks that the
selected connection is within the session's tenant scope.
In-scope use of idp_hint, including for multi-tenant federation apps, is unchanged.
26.2.21
This version contains only minor changes and improvements such as dependency updates.
26.2.20
This version contains only minor changes and improvements such as dependency updates.
v26.2.19
Optionally return group members in the SCIM Groups API
The SCIM Groups API can now return a group's members. Reading a group with GET /api/scim/v2.0/{directoryId}/Groups/{groupId} or
listing groups with GET /api/scim/v2.0/{directoryId}/Groups returns an empty members list by default. Add
includeMembers=true to the request to include the current members instead.
Members stay omitted by default to avoid loading very large memberships into a single response. When includeMembers=true is set
and a group has more than 500 members, the request returns a 400 error and directs you to the paginated group members endpoint,
rather than returning a partial or oversized response.
The 500-member limit is configurable. Set the DSYNC_MAX_INLINE_GROUP_MEMBERS environment variable (or the
dsync.maxInlineGroupMembers option when embedding the library) to raise or lower it.
v26.2.18
Configurable retention for SCIM webhook event logs
You can now set how long SCIM (directory sync) webhook event logs are kept, using the DSYNC_WEBHOOK_LOGS_TTL environment
variable. Set it to a duration such as 720h or 30d.
If you leave the variable unset, logs keep the existing 7-day retention. Set it to an empty string to keep logs indefinitely. An unrecognized value falls back to the 7-day default and logs a warning, so a typo never disables retention.
26.2.17
This version contains only minor changes and improvements such as dependency updates.
26.2.16
This version contains only minor changes and improvements such as dependency updates.
26.2.15
This version contains only minor changes and improvements such as dependency updates.
26.2.14
This version contains only minor changes and improvements such as dependency updates.
26.2.13
This version contains only minor changes and improvements such as dependency updates.
26.2.12
This version contains only minor changes and improvements such as dependency updates.
26.2.11
This version contains only minor changes and improvements such as dependency updates.
26.2.10
This version contains only minor changes and improvements such as dependency updates.
v26.2.9
Patch security vulnerabilities in dependencies
Bump several dependencies to patched versions to address security advisories reported by Dependabot.
Notable updates:
github.com/jackc/pgx/v5tov5.9.2across all Go modules (SQL injection via placeholder confusion in dollar-quoted string literals).github.com/moby/spdystreamtov0.5.1(denial of service on container runtime interface).go.opentelemetry.io/oteltov1.41.0(remote DoS amplification via multi-value baggage header).postcssto>=8.5.10(XSS via unescaped</style>in CSS stringify output).uuidto>=14.0.0(missing buffer bounds check in v3/v5/v6 generators).@xmldom/xmldomto>=0.8.13(XML node injection and uncontrolled recursion).axios,follow-redirects,lodash,picomatch,brace-expansion,serialize-javascript,yaml,file-type,i18next-fs-backend,@nestjs/coreto their respective patched versions.
26.2.8
This version contains only minor changes and improvements such as dependency updates.
26.2.7
This version contains only minor changes and improvements such as dependency updates.
26.2.6
This version contains only minor changes and improvements such as dependency updates.
26.2.5
This version contains only minor changes and improvements such as dependency updates.
26.2.4
This version contains only minor changes and improvements such as dependency updates.
26.2.3
This version contains only minor changes and improvements such as dependency updates.
26.2.2
This version contains only minor changes and improvements such as dependency updates.
26.2.1
This version contains only minor changes and improvements such as dependency updates.
26.2.0
This version contains only minor changes and improvements such as dependency updates.
v26.1.18
Fixed a security issue
This release includes a fix for a security issue. Additional details will be shared with customers directly.
26.1.17
This version contains only minor changes and improvements such as dependency updates.
26.1.16
This version contains only minor changes and improvements such as dependency updates.
26.1.15
This version contains only minor changes and improvements such as dependency updates.
26.1.14
This version contains only minor changes and improvements such as dependency updates.
26.1.13
This version contains only minor changes and improvements such as dependency updates.
26.1.12
This version contains only minor changes and improvements such as dependency updates.
26.1.11
This version contains only minor changes and improvements such as dependency updates.
26.1.10
This version contains only minor changes and improvements such as dependency updates.
26.1.9
This version contains only minor changes and improvements such as dependency updates.
26.1.8
This version contains only minor changes and improvements such as dependency updates.
v26.1.7
Switched to better-sqlite3
We have replaced the unmaintained sqlite3 dependency with better-sqlite3 to ensure ongoing maintenance and stability.
Breaking changes
Turso is no longer supported due to the removal of the sqlite3 library.
Identity Federation: Support for including OIDC tokens in SAML responses
When creating an Identity Federation app, you can now include OIDC tokens in the SAML Response by setting the
includeOidcTokensInAssertion attribute. This allows downstream applications to access the original OIDC tokens issued by the
provider when using SAML federation.
26.1.6
This version contains only minor changes and improvements such as dependency updates.
26.1.5
This version contains only minor changes and improvements such as dependency updates.
26.1.4
This version contains only minor changes and improvements such as dependency updates.
26.1.3
This version contains only minor changes and improvements such as dependency updates.
v26.1.2
Identity Federation: SAML Response expiry is now configurable
When creating an Identity Federation app, you can now control how long a SAML Response remains valid by setting the ttlInMinutes attribute. The default expiry remains 10 minutes.
26.1.1
This version contains only minor changes and improvements such as dependency updates.
26.1.0
This version contains only minor changes and improvements such as dependency updates.
25.4.12
This version contains only minor changes and improvements such as dependency updates.
25.4.11
This version contains only minor changes and improvements such as dependency updates.
25.4.10
This version contains only minor changes and improvements such as dependency updates.
25.4.9
This version contains only minor changes and improvements such as dependency updates.
25.4.8
This version contains only minor changes and improvements such as dependency updates.
25.4.7
This version contains only minor changes and improvements such as dependency updates.
25.4.6
This version contains only minor changes and improvements such as dependency updates.
25.4.5
This version contains only minor changes and improvements such as dependency updates.
25.4.4
This version contains only minor changes and improvements such as dependency updates.
25.4.3
This version contains only minor changes and improvements such as dependency updates.
25.4.2
This version contains only minor changes and improvements such as dependency updates.
25.4.1
This version contains only minor changes and improvements such as dependency updates.
25.4.0
This version contains only minor changes and improvements such as dependency updates.
25.3.9
This version contains only minor changes and improvements such as dependency updates.
25.3.8
This version contains only minor changes and improvements such as dependency updates.
25.3.7
This version contains only minor changes and improvements such as dependency updates.
25.3.6
This version contains only minor changes and improvements such as dependency updates.
25.3.5
This version contains only minor changes and improvements such as dependency updates.
25.3.4
This version contains only minor changes and improvements such as dependency updates.
25.3.3
This version contains only minor changes and improvements such as dependency updates.
2025-07-28
Tag: c2370d3c35c060459b46f1c77b2241a23a1b04eb
No specific upgrade steps are required for this release. The Ory Polis OEL image is now available in the Ory Enterprise Docker Registry.