Changelog

In this latest release the following changes have been made:

• Cockroach DB support has been removed in favor of PostgreSQL in Zitadel V3 and future releases. Migration steps for the transition have been documented here and an open V3 product feedback thread is available for comment.
• The Zitadel repository license changed from an Apache 2.0 to an AGPL3 License as described in this recent blog post.
• Action V2 creation and management added to Zitadel management console. Also the action management API is now available as beta in the API V2 including an Action V1 migration guide
• OIDC Web key management is now available in the Zitadel management console as well in the API V2 beta offering.
• New permission check framework implemented that supports system users.
• Zitadel management console supports all currently available feature flags including user creation and list sessions.
• Romanian language support
• Added functionality to verify imported user passwords that were previously salted and hashed using plain MD5.

For a more indepth look at the full list of changes in this release, check out the Zitadel GitHub repository changes here.

In this latest pre-release the following changes have been made:

• Cockroach DB support has been removed in favor of PostgreSQL in Zitadel V3 and future releases. Migration steps for the transition have been documented here and an open V3 product feedback thread is available for comment.
• The Zitadel repository license changed from an Apache 2.0 to an AGPL3 License as described in this recent blog post.
• Action V2 creation and management added to Zitadel management console. Also the action management API is now available as beta in the API V2 including an Action V1 migration guide
• OIDC Web key management is now available in the Zitadel management console as well in the API V2 beta offering.
• New permission check framework implemented that supports system users.
• Zitadel management console supports all currently available feature flags including user creation and list sessions.
• Romanian language support
• Added functionality to verify imported user passwords that were previously salted and hashed using plain MD5.

For a more indepth look at the full list of changes in this release, check out the Zitadel GitHub repository changes here.

Before this feature, users could update their information when linking their account with a third party identity provider. This could result in unwanted behavior and communication issues, since ZITADEL and the third party IdP would have different information about the user.

In v2.60.0 of our software, a significant modification was made to the account linking process, resulting in the elimination of manual intervention by users. Previously, in situations where users lacked required profile information from third-party identity providers, ZITADEL would prompt the user to complete the missing information, rather than displaying an error message.

With this update we changed the behavior to a fully automatic account linking that doesn’t allow manual intervention by users anymore, ensuring consistency of user data.

If you are using an existing system, please read our Technical Advisory A-10011 for more details.

We heard you. After v2.59.0 users can rotate signing keys programmatically via API. Before this release the key endpoint potentially returned an empty response for low-usage instances which led to multiple issues for clients. The reason for this behavior was that the keys were created just in time when a request was made and keys were rotated automatically.

With the release of this feature, ZITADEL will create keys without expiry for each instance. Managers can create, rotate, and disable signing Keys via API.

You may need to enable key management in the feature settings of your instance. At this time the key management is only available through APIs. Management through Console will be possible with a future release.

With the release of v2.57.0, developers can set custom IDs for service users during creation, enhancing personalization and control.

Before that custom usernames were only possible for human users and service users' IDs were created automatically. This change improves more use cases for integration and testing of ZITADEL.

ZITADEL now offers a more flexible client ID structure, removing the '@' symbol and project name suffix for improved compatibility with third-party applications.

Previously the format was fixed to 123456789@project which was a generated ID suffixed by an '@' and the project name. The special character and format was not compatible with some clients, causing problems for integrations.

An admin or application may want to decrease the number of roles returned in the token. For instance, when a user is granted access to numerous organizations or in specific situations where the application wants to restrict that token's access to a certain organization or multiple organizations.

Including the newly introduced reserved scope with the organization ID or multiple scopes for each organization that should be included will now accomplish this.

Here's an example of the new scope: urn:zitadel:iam:org:roles:id:{orgID}

Note: The new scope will not function when Introspection or Userinfo are in legacy mode which can be enabled through feature settings.

We've introduced a new testing step within the SMTP provider creation/update wizard. This feature allows you to validate your mail provider configuration before saving it. Similar testing option is available for existing configurations in the SMTP provider table.

Additionally, we have refined our SMTP error messages to provide more actionable information Now, instead of generic errors like "could not dial," you'll receive clearer guidance on potential issues such as incorrect ports or firewall restrictions.

ZITADEL now allows organizations to enforce regular password changes for their users. This addresses the security need for periodic password updates.

Key Improvements:

• UI Management: Password age policies can now be easily configured in the Console UI at both instance and organization levels.
• Login UI Prompt: Users will be prompted to change their password in the Login UI if their current password exceeds the defined age limit.
• Customizable Messaging: The prompt message in the Login UI can be tailored through the Console and API.
• API Access: Information about the user's last password change is available in the Auth, Management, and User V2 APIs.
• Policy Retrieval: The password expiry settings can be obtained through the settings service.

This feature enhances ZITADEL's password management capabilities, providing organizations with greater control over password security and user experience.

We understand that many organizations, particularly enterprises, leverage SAML for user federation. In response to your needs, we've made significant steps in enhancing ZITADEL's interoperability with various SAML providers this May.

Previously, ZITADEL relied on a persistent nameID format, requiring external identity providers (IdPs) to consistently return this format for linking users. However, some IdPs utilize transient nameIDs, leading to mismatched user identities.

This update allows you to define the preferred nameID format and configure how ZITADEL maps users based on attributes received from the external IdP. For instance, you can leverage email addresses from the IdP to link users with matching emails in ZITADEL.

Actions already allow access to a user's organization metadata. But it was not possible to get the metadata of other organizations, such as from organizations of user grants / authorizations.

This feature adds the possibility to get the metadata of organizations the user is granted to (authorizations) in actions of Complement Token and Customize SAML Response flows by adding a getOrgMetadata function to the user grant list.

This feature allows to add locally generated RSA keys to service users. Until now, both public and private key material was generated by ZITADEL and the private key was downloaded by the user. Eliminating private key transmission over the network strengthens security. Users can now generate private machine keys locally for service users and avoid sending the sensitive key material over the network.

This update introduces enhancements to the lockout policy, providing finer-grained control over user access attempts. Similar to the existing functionality for passwords, administrators can now configure automatic lockouts after a specified number of consecutive failed Time-based One-Time Password (TOTP) checks. The new feature strengthens security posture by mitigating brute-force attacks targeting TOTP verification.

Lockouts are applied independently for each TOTP method. This ensures users retain the ability to attempt alternative verification methods (e.g., email OTP) even after exceeding the threshold for a specific TOTP method (e.g., mobile app).

Example Scenario:

If the lockout policy is set to trigger after 3 failed attempts, a user who enters an incorrect mobile app TOTP code twice would still have the opportunity to try email verification or another configured TOTP method. Only after exceeding the attempt limit for all available methods would the account be locked.

This update simplifies the configuration of email delivery within ZITADEL by introducing SMTP provider templates. These templates offer pre-defined settings for popular email service providers (ESPs) like Amazon SES, Mailgun, Mailjet, Postmark, Sendgrid, and a Generic SMTP option.

Benefits:

• Faster configuration: Leverage pre-configured settings to streamline the setup process for supported ESPs. You only need to provide your specific account details, significantly reducing configuration time.
• Reduced errors: Pre-defined templates minimize the risk of configuration errors associated with manual setup.
• Improved maintainability: Centralized templates ensure consistency and simplify future updates for supported ESPs.

We strongly recommend replacing the pre-configured SMTP service in ZITADEL Cloud for production environments. These default settings are for demonstration purposes only and may not provide the necessary level of security or reliability for critical deployments. Configuration with SMTP provider templates facilitates the transition to a secure, production-ready SMTP configuration.

Feature flags allow users to opt-in or opt-out of experimental features that are not intended to be generally available. Our intention is to provide means to access and test early features for users to test and provide feedback.

Feature settings are available in the default settings through the Console and via our Feature Service API.