Ory Network, Ory Hydra, Ory Kratos v26.3.3 released

DATE: July 28, 2026

AUTHOR: Ory Team

Ory Network

Configurable legal footer links in Account Experience

Account Experience now shows configurable Terms of Service, Privacy Policy, and Contact links in the footer. Set the URLs on the Account Experience → UI theming page in the Console; empty fields are hidden. Labels are localized and can be overridden per locale — including a markdown link [label](url) to point a locale at a different URL.

Configure OAuth 2.0 Device Authorization Grant per project

Enterprise customers can now configure the OAuth 2.0 Device Authorization Grant (RFC 8628) for each project. The new settings let you tune the runtime behavior of the device flow that ships with Ory Hydra to match your product:

User code entropy preset (high, medium, or low) — controls how long and how guess-resistant the user_code is.
Token polling interval — the value Hydra reports to client devices in the interval response field.
Device + user code lifespan — how long an issued device_code and user_code remain valid.
Device verification URL and device success URL — point end users at your own UI when they enter the user_code, instead of the Ory fallback pages.
Discovery override for the device authorization endpoint — advertise a different device_authorization_endpoint in /.well-known/openid-configuration.

The new fields appear on the OAuth 2.0 configuration page in the Console and on the project settings API. They are gated behind the new hydra_device_authorization Enterprise feature; non-Enterprise projects see the section but cannot change the values.

OAuth2 tokens include the organization ID for organization members

When a member of an organization completes an OAuth2 or OpenID Connect flow through the hosted consent screen, the issued tokens now include the identity's organization ID. The claim appears as organization_id in the ID token and in the access token session data (under ext in JWT access tokens, promotable via allowed_top_level_claims). Identities that do not belong to an organization get no claim.

Custom consent UIs are unaffected: they keep full control over their session claims.

This is now available on Ory Network.

Ory Hydra

Configure OAuth 2.0 Device Authorization Grant per project

User code entropy preset (high, medium, or low) — controls how long and how guess-resistant the user_code is.
Token polling interval — the value Hydra reports to client devices in the interval response field.
Device + user code lifespan — how long an issued device_code and user_code remain valid.
Device verification URL and device success URL — point end users at your own UI when they enter the user_code, instead of the Ory fallback pages.
Discovery override for the device authorization endpoint — advertise a different device_authorization_endpoint in /.well-known/openid-configuration.

This is now available on Ory Network.

Ory Kratos

Kratos gains a FIPS 140-3 build with a PBKDF2 password hasher

Ory Enterprise License releases now include a dedicated FIPS build of Kratos (kratos_oel_fips_<version>_<os>_<arch>) next to the standard build. The FIPS build uses the Go Cryptographic Module and starts with GODEBUG=fips140=on by default, so all cryptographic operations run through the FIPS 140-3 validated module. The standard build is unchanged.

PBKDF2 password hasher

You can now choose pbkdf2 as the password hashing algorithm alongside argon2 and bcrypt. PBKDF2-HMAC-SHA256 is FIPS 140-3 approved, which makes it the recommended choice for FIPS-compliant deployments. Configure it under hashers:

hashers:
  algorithm: pbkdf2
  pbkdf2:
    iterations: 600000
    salt_length: 16
    key_length: 32

The defaults are 600,000 iterations, a 16-byte salt, and a 32-byte derived key.

Existing password hashes keep working

Passwords hashed with a different algorithm still verify as before. When an identity signs in with such a password, Kratos re-hashes it with the configured algorithm on the next successful login, just as it already does when you switch between argon2 and bcrypt. No migration or password reset is needed.

FIPS mode log signals

When the FIPS build runs, Kratos tells you where your configuration deviates from a FIPS-compliant setup:

On startup, Kratos logs that FIPS 140-3 mode is active.
On startup, Kratos warns when the configured password hasher or cipher is not FIPS 140-3 approved (any hasher other than pbkdf2, or any cipher other than aes, including the default noop).
When signing a session JSON Web Token through the JWT webhook, Kratos warns if the signing algorithm is not FIPS 140-3 approved (once per algorithm). Configure a JSON Web Key with an approved algorithm (RS*, PS*, ES*, HS*, or EdDSA) for a fully FIPS-compliant deployment.

These warnings do not block any operation.

One-time-code and verification messages can be branded per OAuth2 client

The login_code_valid, registration_code_valid, and verification_code_valid courier templates (email and SMS), as well as the link method's verification_valid email template, now include a scoped oauth2_login_request object when the flow was started through an OAuth2 login challenge. Verification flows inherit the challenge from the OAuth2-initiated registration or login that triggered them. The object contains the challenge and the initiating client's client_id, client_name, client_uri, logo_uri, and metadata. Custom HTTP mail servers can brand these messages per OAuth2 client from template_data.oauth2_login_request.client — a trusted, server-sourced value — without relying on the end-user-controlled transient_payload or resolving the login challenge with an unscoped API token. Flows without a login challenge are unchanged.

Stricter validation of iOS device attestations at enrollment

When you enroll an iOS device key, Kratos now inspects the authenticator data of the Apple App Attest attestation and rejects keys that fail any of these checks:

The attestation environment (AAGUID) must be the production environment. Development keys, which can be produced on jailbroken devices, are accepted only when relaxed attestation is enabled, and such keys remain short-lived.
The signature counter must be zero, confirming the key was just created and has never been used.
The credential ID embedded in the attestation must match the key identifier the client submits.

These checks harden the enrollment flow against forged or reused attestations. Compliant iOS clients are unaffected.

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

No significant changes in this release.