Jun 18, 2025

What is changing?

We are deprecating the Real-time Webtask Logs extension with a planned end-of-life after (EOL) September 16, 2025.

As a replacement, we have published the Actions Real-time Logs feature integrated within the Auth0 Dashboard. The extension will cease to be available for new installations, but tenants with the extension already installed will maintain access until the planned EOL.

Why are we making this change?

The transition to the dashboard will improve the security posture and maintainability of the functionality, while simplifying future enhancements.

How are you affected?

For active users of the Real-time Webtask Logs extension, its scheduled removal will affect you, as the transition from extension to a direct dashboard capability inherently implies some user experience differences.

What action do you need to take?

You can start using the Actions Real-time Logs feature by navigating to Auth0 Dashboard > Monitoring > Actions Logs.

We recommend that extension users familiarize themselves with the new user interface to avoid disruption once the extension becomes unavailable.

We’ve added a new language option-Canadian French-to help our users in Canada and beyond build secure identity solutions more easily. If your language preference is set to Canadian French in your browser settings, Auth0 will detect this and automatically serve the Dashboard and Documentation in Canadian French. You can manually override this setting in the Auth0 Dashboard and Docs via the language switcher in the top-right corner.

What is changing?

The service will restrict access to additional property names within the event.request.query and event.request.body objects when executing actions for the post-login and credentials-exchange triggers. Tenants identified as using actions that may reference request properties planned for restriction will maintain access until September 16, 2025.

The service will restrict the following property names in the request-related objects:

auth_session
authn_response
client_secret
client_assertion
refresh_token

Previously, the implementation of an action could access the properties listed above in event.request.query and event.request.body to retrieve the value included in the corresponding network request. Once the planned restrictions become effective for a given tenant, all properties above will be undefined independently of the network request content.

The rollout of these additional restrictions is in progress for tenants where historical data did not show any actions using these property names. Tenants identified as potentially impacted by these restrictions will maintain existing behavior until the previously mentioned date.

Why are we making this change?

By restricting access to these properties, we aim to prevent potential mishandling of sensitive data within the custom code implemented for post-login and credentials-exchange actions. For example, we reduce the risk of unintentionally logging sensitive data in log operations that may output the whole request object.

How are you affected?

If any of your tenant's current actions no longer include any reference to one of the restricted property names or that despite having references to one of the names, it is not in the context of property access to event.request.query and event.request.body objects, then these changes should not impact your tenant.

If there are actual references to restricted request properties, the restriction of these properties may impact the action's logic. After the changes become effective, accessing those request properties will always return undefined. Without revising the actions' implementation, the respective authentication flows risk partial degradation or complete failure.

What action do you need to take?

If your tenants currently have actions referencing one of the restricted properties of the event.request.query and event.request.body objects in their implementation. For applicable actions, you must update their implementation to stop relying on the restricted properties of the request objects.

The exact implementation changes you may need to perform will depend on your overall implementation of the actions and each restricted request property's usage scenario.

For example, for scenarios related to reusing secret information previously available from the request, the support for secret management (event.secrets) as part of actions may provide a potential alternative. If the requests include restricted property names, but the information sent within them is not considered sensitive, you may consider using a different parameter name in the request, or ideally, consider using custom parameters as part of pushed authorization requests to avoid disclosing/interception of the data by end-users in browser-based flows. If the data is static per client or connection, consider storing it as part of client or connection metadata.

Jun 17, 2025

Auth0 is excited to announce the General Availability of Private Cloud Restoration resilience enhancement. This capability would come handy in the event of customer data loss or data corruption, and would assist customers in meeting regulatory requirements such as European Union’s Digital Operational Resilience Act (DORA).

This capability allows customers to request full restoration of their production Private Cloud environment from an Auth0 backup in the last 14 days. It also includes the option for one restoration test per year on a non-production Private Cloud environment. Please refer to Operational policies documentation for more.