Auth0 Release Notes

**Credential Guard** is now supported for Private Cloud on Azure customers! This enhancement brings: - 🔍 **Proactive Threat Hunting** – A dedicated security team infiltrates criminal communities and gains access to breach data that isn’t otherwise available–enabling detection of compromised passwords within 12–36 hours instead of the traditional months - ⏱ **Faster Detection** – Detects breaches 250% faster than standard automated solutions - 🌍 **Expanded Coverage** – Automates breached password detection coverage in over **200+ countries and territories**, ensuring that users worldwide receive consistent, localized protection. For additional details and to learn how to enable **Credential Guard**, please view our online documentation [here](https://auth0.com/docs/secure/attack-protection/breached-password-detection#detect-breaches-faster-with-credential-guard).

We’re excited to announce that __Custom Phone Providers and the Unified Phone Experience__ are now Generally Available. __Custom Phone Providers__: With this feature, customers can configure custom phone providers and customize phone messages not only when leveraging phone number as an identifier, but also when using MFA and Passwordless! Auth0’s CI/CD tooling (Auth0 CLI, Deploy CLI, and Terraform Provider) now fully supports Custom Phone Providers. To access these new capabilities, upgrade to the latest versions of Auth0 CLI, Deploy CLI, and Terraform Provider. We encourage you to get started with Custom Phone Providers today by checking out our [documentation](https://auth0.com/docs/customize/phone-messages/configure-phone-messaging-providers/configure-a-custom-phone-provider) and if you have any feedback, give us a shout in our [community channel](https://community.auth0.com/)! __Unified Phone Experience__: The Unified Phone Experience offers a consolidated experience where you can configure a tenant-level phone provider that will be used for Phone as ID, MFA, and Passwordless flows. Additionally, the management of phone templates will be centralized on a single page. This unification aims to reduce redundancy across Auth0 features and present a more streamlined user experience. The unified experience will be the default for any new tenants created after this release, and existing tenants will have the ability to revert to the legacy experience if desired.…

We're improving both account security and user experience by extending **Breached Password Detection** to the **password reset flow**. #### 🔹 What’s New? Previously, users could unknowingly reset their passwords to compromised credentials, creating security risks and potentially requiring another reset. With this update, you can now prevent users from setting their password to a known breached credential during the reset flow -just like during sign-up and login. Additionally, with this rollout we have also **increased coverage** of Breached Password Detection on Sign-Up to cover the **Management API**! #### 🚀 Benefits **Stronger security** – Protects against compromised credentials at every stage. **Better user experience** – Avoids unnecessary password resets by blocking breached passwords upfront. This update helps prevent your users from using known compromised credentials throughout their password lifecycle, giving your users stronger security on their accounts. For additional details and to learn how to enable **Breach Password Detection on Password Reset Flows**, please view our online documentation [here](https://auth0.com/docs/secure/attack-protection/breached-password-detection).

This feature allows developers to ensure their custom database scripts are compatible with specific Node.js runtime versions. Here's a summary of the key points: - __Bulk Testing Compatibility:__ The feature can test the compatibility of custom database scripts with different supported Node.js runtime versions. - __Database Connections Limit:__ It is available if your tenant has 1 to 10 database connections with custom database scripts enabled. - __Navigation Path:__ The feature can be accessed by going to Tenant Settings → Advanced → Extensibility → Verify Custom DB Scripts. __Actions Based on Results:__ After testing, the results can be verified and corrective actions can be taken if any compatibility issues are identified. Checkout our online documentation to learn more about [Extensibility Tenant Settings](https://auth0.com/docs/get-started/tenant-settings#extensibility "Extensibility Tenant Settings")!

We are excited to announce the next Early Access release of Advanced Customizations for Universal Login! This release adds support for building custom versions of Universal Login’s MFA enrollment screens and 3 of our most common MFA factors using the new ACUL SDK. Advanced Customizations for Universal Login enables you to build custom, client-rendered interfaces for Universal Login screens, allowing you to control every pixel of your Universal Login experience. This release allows you to building custom versions of the following screens: * MFA Detect Browser Capabilities * MFA Begin Enroll Options * MFA Enroll Result * MFA Login-options * MFA Email List * MFA Email Challenge * MFA Country Codes * MFA SMS Enrollment * MFA SMS List * MFA SMS Challenge * MFA Push Welcome * MFA Push Enrollment QR * MFA Push List * MFA Push Challenge Push We are well on our way to adding support for everything that Universal Login currently supports out of the box. Checkout our [online documentation](https://auth0.com/docs/customize/login-pages/advanced-customizations) to learn more about ACUL and stay tuned to the Auth0 Changelog for updates and announcements!

We have deprecated the invalidation of user sessions when performing database connection user update (PATCH - `/api/v2/users/{id}`) requests where: * The `email` or `email_verified` attributes are set to an unchanged value; * The `email_verified` attribute is set to a `true` value. These changes allow for consistent behavior between setting an email as verified through the Management API and the built-in email verification flows provided by the service. In addition, it improves the overall end-user experience by avoiding session invalidation in situations that do not require it, such as setting either the `email` or `email_verified` attributes to unchanged values. The dashboard will be updated with a migration toggle to opt out of the deprecated behavior ahead of its future end-of-life; we have provided additional information and timelines for enforcing this change through a [dashboard and support center notification](https://manage.auth0.com/#/notifications/67ab8c121f5c740896fcfd19).

We are excited to introduce the Usage Metrics Dashboard in Okta Fine-Grained Authorization (FGA), providing customers with deeper visibility into their authorization usage. This new dashboard, available under the “Manage Account” section of the Okta FGA dashboard, helps teams monitor, analyze and manage their FGA consumption efficiently. What’s New? ## - __Monitor Key Metrics__: Track Monthly Active Users (MAUs), Total Tuple Count, and Monthly Average Requests Per Second (RPS). Time Frame Selection: View trends over the Last Month or Last 3 Months, with the current month’s data always included for the latest insights. - __Granular Data Views__: Click on “View Table” option to see a detailed breakdown of usage by store and time period. - __Hourly Updates__: Data is refreshed hourly to help you make informed decisions. Learn More: ## Check out the [documentation](https://docs.fga.dev/intro/dashboard#usage-metrics-dashboard) for details on how to use the dashboard effectively.

__Email OTP Verification__ is now __Generally Available (GA)__, minor improvements will continue to roll out over the next __1-4 weeks__ to enhance performance and usability. With __Email OTP Verification__, users are required to enter a One-Time Password (OTP) sent to their email during the signup or password reset process. This ensures email verification happens __before__ account creation or password reset is completed, offering enhanced security and reducing the chances of mistyped or fake email accounts. __Key Highlights:__ - __Synchronous Email Verification:__ Prevents account creation or password reset until users verify their email via OTP. - __Improved Security:__ Helps prevent fake accounts, ensures accurate email addresses, and discourages phishing through email links. - __Applicability:__ Available for both email verification during signup and password reset challenges. __Prerequisites:__ - Must be using __Universal Login__. - Connection must have __Flexible Identifiers__ enabled. - Email OTP is only compatible when using the __Identifier First Authentication Profile__. To enable this feature, navigate to the __Attributes__ tab on any connection and change the __Verification Method__ under the __Email__ attribute settings from __Verification Link__ to __OTP__.

We are thrilled to announce the Early Access release of Custom Token Exchange. __Enterprise customers__ can now request access to use this feature. Token Exchange is an OAuth grant-type that enables the exchange of security tokens for other security tokens, typically access_tokens. Custom Token Exchange provides a flexible __solution using Actions that allows customers to provide their custom logic to control the exchange__ - i.e. effectively providing the means to implement custom authentication semantics using Actions.  This __added flexibility__ can be used by customers to tackle __advanced integration use cases__, such as: - Seamlessly migrating users to Auth0 - Integrating external IDPs - Exchanging Auth0 tokens for a different audience - ... and other use cases where regular federation and/or OIDC flows are not an option To learn more, read our [documentation](https://auth0.com/docs/custom-token-exchange-early-access). Reach out to you Auth0 contact to request access!

At Auth0, we understand that no two customer identity stories are the same. Every company has a brand identity, a secret sauce, and a unique aesthetic vision. Today, we are very excited to introduce the next evolution in customization for Universal Login, **Advanced Customizations for Universal Login** (ACUL). ACUL enables your team to build custom, client-rendered versions of each Universal Login screen, allowing you to control every pixel of the Universal Login experience.  This Early Access release of ACUL is available to all paid customers. Public cloud customers can start using it today! Those on private cloud will be enabled as part of their regular release cycle. This initial EA release provides a new configuration API, CDT and SDK support, and allows you to build custom versions of the following screens: * Login * Login Id * Login Password * Login Passwordless Email Code * Login Passwordless SMS OTP * Signup * Signup Id * Signup Password * Passkey Enrollment * Passkey Enrollment Local * Phone Identifier Enrollment *(used for identity verification during Signup)* * Phone Identifier Challenge *(used for identity verification during Signup)* * Email Identifier Challenge *(used for identity verification during Signup)* * Interstitial Captcha * Reset Password * Reset Password Email * Reset Password Request \…

We’re thrilled to announce that Auth0 now supports Universal Logout integration with Okta Workforce Identity Cloud! Okta Universal Logout is based on the [Global Token Revocation](https://www.ietf.org/archive/id/draft-parecki-oauth-global-token-revocation-04.html) specification and allows security incident management tools [Okta Identity Threat Protection](https://www.okta.com/products/identity-threat-protection/) to send back-channel requests to revoke users' sessions and refresh tokens when they identify a change in risk. With this feature, Auth0 customers federating with Okta Workforce Identity using the [Okta](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/okta), [SAML](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/saml), or [OpenID Connect](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/oidc) connection types no longer need to build a global token revocation endpoint. Instead, with minimal configuration required, they can provide the Okta admin with Auth0’s connection-specific endpoint URL. This integration provides security benefits for apps that depend on refresh tokens and Auth0 sessions, as both are revoked when Auth0 receives a Universal Logout request for a user. This integration can also trigger Auth0's OIDC back-channel logout feature to terminate custom application sessions. To learn more about Universal Logout support in Auth0, click [he…

Customers now have Enhanced Rate Limit Reporting via Logs, including: - Increased Rate Limit Log (api_limit) Publishing Frequency: receive 1X per minute notifications indicating when you have exhausted a rate limit. - New Rate Limit Warning Log (api_limit_warning): receive 1X per minutes notifiactions indicating when you have exhuasted 80% of your rate limit request token allocation. - Enhanced Logs Schema: additional attributes of HTTP path and method and bucket size will be included to allow for easier mapping between Logs and API Rate Limit Configuration Docs. https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations

We are excited to introduce the Per-Module Authorization feature. This enables large organizations to securely share authorization models by specifying which application credentials can update data for specific modules. Teams that are responsible for their own separate services can now limit access to modification of authorization data on a per-module basis. Last year, we released [Modular Models](https://docs.fga.dev/modeling/modular-models), where a single model could be separated into modules across multiple files, allowing teams to use features in their source code management platforms (such as GitHub’s [CODEOWNERS](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) feature) to enforce access on who can modify parts of a model. Per-Module Authorization builds on top of that work to further define permissions for applications. Workflows can be implemented where different teams maintain their portion of an FGA model independently and also ensure that the services and applications owned by the respective teams can only modify their own authorization data. For more details, refer to Okta FGA’s [documentation](https://docs.fga.dev/intro/dashboard#grant-authorized-clients-access-to-write-specific-modules) on how to grant client credentials access to only specific modules.

We are excited to announce the next major version of Next.js SDK. With the introduction of [nextjs-auth0 v4](https://github.com/auth0/nextjs-auth0), we now support Next.js 15 and React 19, allowing developers to leverage the latest features and improvements in both frameworks. This compatibility not only enhances the development experience but also ensures that applications can take full advantage of performance optimizations. This updated SDK features a simplified architecture and is edge-compatible by default, enhancing performance and flexibility for developers. What’s new: - __Middleware-Based Authentication:__ Improved compatibility and reduced maintenance by moving to middleware-based handlers. - __Enhanced Security:__ Switched to encrypted cookies and removed outdated cookie logic. - __Resolved State Mismatch Issues:__ Fixed long-standing issues reported by the community. - __Improved Session Management:__ Implemented rolling sessions and eliminated cookie chunking. - __Improved Hooks and Helpers:__ Introduced useUser(), getAccessToken(), and getSession() for easier data fetching and session handling. - __Stateful Sessions with Custom Databases:__ Support for "Bring Your Own Database" (BYODB). - Compatibility with __Next.js 15__, __Turbopack__, and __React 19__ - __Simplified architecture__, API, and configuration options Learn More: - [Quickstart](https://auth0.com/docs/quickstart/webapp/nextjs/interactive) - [Migration Gui…

__What’s Changing:__ We are improving the Dashboard configuration experience for email providers. The default From address field will be required when creating or updating email provider configuration through the Dashboard. Customers do not need to take immediate action, and the Management API will maintain the field as optional for backward compatibility. __Key Dashboard Updates:__ 1. __Configuring New Email Providers__: Customers must supply a default From address when configuring a new email provider. 2. __Changing Existing Email Providers__: Customers must supply a default From address when updating an existing email provider. Existing configured email providers that do not have a From address configured will continue to work as before. __Why This Matters__: An email provider configured without a default From address may lead to a poor user experience because email template customizations are not supported when a customer-defined From address is unavailable. By requiring a default From address at the email provider level, email template customizations will be respected even if the email template does not have a template-specific From address. __Rollout Timing__: We plan to roll out this change in the coming days. After the rollout, customers can expect to see the enforcement of this required field on the Dashboard.

We’re excited to announce that __Custom Email Providers__ is now __Generally Available__. With this feature, customers can configure custom email providers and customize emails so they can have full control of the email delivery process. This feature utilizes the Actions framework and leverages the Actions Code Editor so you can more completely manage, monitor, and troubleshoot your email communications. Auth0’s CI/CD tooling (Auth0 CLI, Deploy CLI, and Terraform Provider) now fully supports Custom Email Providers. To access these new capabilities, upgrade to the latest versions of Auth0 CLI, Deploy CLI, and Terraform Provider. We encourage you to get started with Custom Email Providers today by checking out our [documentation](https://auth0.com/docs/customize/email/configure-a-custom-email-provider) and if you have any feedback, give us a shout in our [community channel](https://community.auth0.com/)!

This Beta feature logs in real-time output form your custom Actions code. This includes all console.log output and exceptions. For example, a custom Action code such as below: console.log("Hello world!"); Will show up within Dashboard > Monitoring > Actions Logs as  You can also use examples such as below to catch and log errors for making it easy to debug and troubleshoot your Actions. try { nonExistentFunction(); } catch (error) { console.error(error); // Expected output: ReferenceError: nonExistentFunction is not defined // (Note: the exact output may be browser-dependent) } These logs are not stored and are only available within the dashboard when you are logged in and are on the Dashboard > Monitoring > Actions Logs tab within the browser. These logs are designed to help you troubleshoot as you write or modify your custom Actions code.