We’re excited to announce the Early Access release of Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections! Auth0 customers can now leverage a more secure and standards-based method of client authentication for their enterprise identity providers.
Until now, federated connections relied on long-lived client secrets for back-channel authentication. This feature enables signing with asymmetric keys on Okta and OIDC connections, reducing the risk of credential leakage and enabling secure key management and rotation.
While Auth0 already supports Private Key JWT when acting as the Identity Provider, this release extends that security posture to outbound enterprise connections, allowing Auth0 to securely authenticate to upstream IdPs using signed JWTs instead of shared secrets.
For complete setup instructions and more, refer to our documentation.
By using Private Key JWT Client Authentication on your OIDC and Okta Enterprise Connections, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement and Okta’s Privacy Policy during use of the Early Access feature. The Free Trial terms can be found within the Master Subscription Agreement.
We’re excited to announce that Multi-Resource Refresh Tokens (MRRT) is now in Early Access for Enterprise customers.
This feature allows applications to use a single refresh token to request access tokens for multiple resource servers (APIs), each with its own audience and scopes. MRRT simplifies token lifecycle management, enhances developer experience, and improves session continuity across distributed API architectures.
What’s New?
We’re excited to announce the Early Access release of Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections! Auth0 customers can now leverage a more secure and standards-based method of client authentication for their enterprise identity providers.
Until now, federated connections relied on long-lived client secrets for back-channel authentication. This feature enables signing with asymmetric keys on Okta and OIDC connections, reducing the risk of credential leakage and enabling secure key management and rotation.
While Auth0 already supports Private Key JWT when acting as the Identity Provider, this release extends that security posture to outbound enterprise connections, allowing Auth0 to securely authenticate to upstream IdPs using signed JWTs instead of shared secrets.
For complete setup instructions and more, refer to our documentation.
By using Private Key JWT Client Authentication on your OIDC and Okta Enterprise Connections, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement and Okta’s Privacy Policy during use of the Early Access feature. The Free Trial terms can be found within the Master Subscription Agreement.
We’re excited to announce that Multi-Resource Refresh Tokens (MRRT) is now in Early Access for Enterprise customers.
This feature allows applications to use a single refresh token to request access tokens for multiple resource servers (APIs), each with its own audience and scopes. MRRT simplifies token lifecycle management, enhances developer experience, and improves session continuity across distributed API architectures.
What’s New?
We’re excited to announce the Early Access release of Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections! Auth0 customers can now leverage a more secure and standards-based method of client authentication for their enterprise identity providers.
Until now, federated connections relied on long-lived client secrets for back-channel authentication. This feature enables signing with asymmetric keys on Okta and OIDC connections, reducing the risk of credential leakage and enabling secure key management and rotation.
While Auth0 already supports Private Key JWT when acting as the Identity Provider, this release extends that security posture to outbound enterprise connections, allowing Auth0 to securely authenticate to upstream IdPs using signed JWTs instead of shared secrets.
For complete setup instructions and more, refer to our documentation.
By using Private Key JWT Client Authentication on your OIDC and Okta Enterprise Connections, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement and Okta’s Privacy Policy during use of the Early Access feature. The Free Trial terms can be found within the Master Subscription Agreement.
We’re excited to announce the Early Access release of Private Key JWT Client Authentication for OIDC and Okta Enterprise Connections! Auth0 customers can now leverage a more secure and standards-based method of client authentication for their enterprise identity providers.
Until now, federated connections relied on long-lived client secrets for back-channel authentication. This feature enables signing with asymmetric keys on Okta and OIDC connections, reducing the risk of credential leakage and enabling secure key management and rotation.
While Auth0 already supports Private Key JWT when acting as the Identity Provider, this release extends that security posture to outbound enterprise connections, allowing Auth0 to securely authenticate to upstream IdPs using signed JWTs instead of shared secrets.
For complete setup instructions and more, refer to our documentation.
By using Private Key JWT Client Authentication on your OIDC and Okta Enterprise Connections, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement and Okta’s Privacy Policy during use of the Early Access feature. The Free Trial terms can be found within the Master Subscription Agreement.
We’re excited to announce that Multi-Resource Refresh Tokens (MRRT) is now in Early Access for Enterprise customers.
This feature allows applications to use a single refresh token to request access tokens for multiple resource servers (APIs), each with its own audience and scopes. MRRT simplifies token lifecycle management, enhances developer experience, and improves session continuity across distributed API architectures.
What’s New?
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_sessionauthn_responseclient_secretclient_assertionrefresh_tokenPreviously, 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.
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.
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.
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.
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.
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.
The transition to the dashboard will improve the security posture and maintainability of the functionality, while simplifying future enhancements.
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.
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.
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_sessionauthn_responseclient_secretclient_assertionrefresh_tokenPreviously, 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.
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.
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.
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.
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.
The transition to the dashboard will improve the security posture and maintainability of the functionality, while simplifying future enhancements.
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.
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.
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.
The transition to the dashboard will improve the security posture and maintainability of the functionality, while simplifying future enhancements.
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.
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.
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_sessionauthn_responseclient_secretclient_assertionrefresh_tokenPreviously, 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.
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.
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.
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.
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.
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.
The transition to the dashboard will improve the security posture and maintainability of the functionality, while simplifying future enhancements.
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.
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.
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_sessionauthn_responseclient_secretclient_assertionrefresh_tokenPreviously, 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.
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.
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.
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.
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.
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.
Demonstrating Proof of Possession (DPoP) sender constraining for Enterprise Connections is now available in Early Access. Customers can now…
Demonstrating Proof of Possession (DPoP) sender constraining for Enterprise Connections is now available in Early Access. Customers can now…