Changelog

In September we will introduce new regions for ZITADEL Cloud:

• 🇺🇸 United States
• 🇪🇺 European Union
• 🇦🇺 Australia

The already existing 🇨🇭 Switzerland region will remain in our offering. Both GDPR and Global regions will be continued, but no new instances can be created. Already existing instances will receive an additionally generated domain indicating the instances’ region to provide consistent domains for all customers.

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.