Changelog

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 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.

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.

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.