v26.2.17

v26.2.17

Make passkey authenticator, attestation, and timeout options configurable

The passkey strategy now exposes advanced configuration under selfservice.methods.passkey.config that was previously hardcoded:

• authenticator_selection.attachment, resident_key, and user_verification control which authenticators are eligible and whether biometrics or a PIN are required. attachment now defaults to no constraint, so by default users can register either platform or cross-platform authenticators. Set attachment: "platform" to restore the previous behavior of accepting only built-in authenticators.
• attestation.preference sets the attestation conveyance preference sent to the authenticator.
• timeouts.registration and timeouts.login set how long the WebAuthn ceremonies stay valid.

All options are optional. Defaults match the previous behavior, so existing deployments do not need to change anything. See the passkey documentation for a full reference and examples.

Reject DeviceAuthn enrollments using a revoked Android attestation CA

Kratos now periodically fetches Google's Android attestation revocation list and rejects DeviceAuthn enrollments whose certificate chain contains a revoked CA.

The Android root CAs and the background goroutine that refreshes the revocation list are initialized lazily, on the first DeviceAuthn call and only when DeviceAuthn is enabled. Deployments that do not use DeviceAuthn pay no startup cost and emit no related logs.

Note: toggling selfservice.methods.deviceauthn.enabled from true to false at runtime does not stop the background goroutine; restart the process to fully disable it.

SCIM data mapper can read the existing identity

The SCIM provisioning data mapper now receives the existing identity through a new identity external variable, alongside the existing scim variable. The variable exposes traits, metadata_public, and metadata_admin, each defaulting to an empty object when unset.

This lets a mapper preserve or merge attributes that SCIM does not manage. For example, an identity first created by a SAML or OIDC login may store fields such as an object ID in metadata_public. Because SCIM provisioning replaces metadata_public with the mapper output, those fields were previously overwritten. A mapper can now merge them back in:

local scim = std.extVar('scim');
local identity = std.extVar('identity');
local existingPublic = std.get(identity, 'metadata_public', {});

{
  identity: {
    metadata_public: existingPublic + {
      // SCIM-managed fields. These win on key conflicts.
    },
  },
}

SCIM keeps full-replace semantics: the mapper output still replaces metadata_public unless the mapper deliberately merges the existing values back in. Mappers that do not reference the identity variable are unaffected.

SCIM enterprise user extension

You can now provision enterprise user attributes through SCIM. Ory Network's SCIM endpoints support the urn:ietf:params:scim:schemas:extension:enterprise:2.0:User schema from RFC 7643 §4.3, including employeeNumber, costCenter, organization, division, department, and manager. Clients can read and write these attributes via POST, PUT, PATCH, and GET. PATCH paths and filter expressions accept the URN-prefixed form, so common provisioning flows (such as Okta's incremental manager updates) work without configuration changes. Filtering by employeeNumber is supported for indexed lookups.

A new /scim/{client}/v2/ResourceTypes discovery endpoint advertises the extension to clients that look at it.

The Jsonnet mapper for SCIM-to-identity transformation now sees the enterprise object under the URN key on the scim input, so customers can map enterprise attributes into identity traits or metadata.

SCIM provisioning links existing users by verified email domain

SCIM provisioning now links an existing user into an organization when the user is not yet assigned to one and holds a verified email address whose domain matches one of the organization's configured domains. Previously, provisioning such a user returned a conflict.

When a SCIM client creates a user that already exists as an unclaimed identity, Ory checks the existing identity's verified email addresses against the SCIM client organization's domains. On a match, the existing identity is linked into the organization instead of failing with a conflict.

To protect against unauthorized access, Ory does not link a user when:

• the matching email address is not verified,
• the email domain does not match any of the organization's domains, or
• the user already belongs to a different organization.