Auth0 Changelog

We're excited to announce the addition of two new endpoints for refresh token management, introducing granularity in search and revocation capabilities, as well as bulk revocation of refresh tokens (up to 100 individual IDs at a time): - A new GET api/v2/refresh-tokens endpoint which allows retrieving refresh tokens for a user_id or a user_id + client_id combination - A new POST api/v2/refresh-tokens/revoke endpoint which allows RT revocation: - by ids (up to 100 at a time) - by user_id (remove all refresh tokens for a given user) - by user_id + client_id (remove all refresh tokens bound to a client for a given user) - by user_id + client_id + audience (remove all refresh bound to a client and a resource server for a given user) The new endpoints are in __Early Access__. Please contact your TAM or open a support ticket to get this feature enabled in your tenant

We have updated the machine learning model driving Bot Detection during the Signup Flow. This update lowers false-negative rates to intercept more automated traffic while keeping false-positive rates low for valid users. __What's New:__ __Smarter Signup Security:__ Optimized thresholds catch advanced bot behaviors while preserving a seamless registration experience for legitimate users. __Consistent Protection at Scale:__ The model now delivers uniform detection accuracy across tenants of all sizes, regardless of your baseline traffic volumes. __Note:__ This model optimization specifically targets the signup flow and rolls out automatically to Enterprise tenants utilizing Attack Protection with no customer action or migration steps required. To learn more about Bot Detection check out our online docs [here]("https://auth0.com/docs/secure/attack-protection/bot-detection)

We’re pleased to announce that support for Groups within Auth0’s [Inbound SCIM](https://auth0.com/docs/authenticate/protocols/scim/configure-inbound-scim) for Enterprise Connections capability is now Generally Available (GA)! This release closes the loop between identity provisioning and access control by allowing you to natively map synced groups to Auth0 roles at two levels: globally at the tenant level, or scoped specifically to an organization based on the user’s login context. Additionally, developers can now accelerate B2B onboarding by empowering their enterprise customers to self-configure SCIM provisioning for groups directly. __What’s new in GA:__ Building on our [Early Access](https://auth0.com/changelog#6osxJFJUB5gsCePUpSanRQ) capabilities, this release introduces the following enhancements to deliver out-of-the-box B2B delegated administration: - __Associate tenant-level RBAC roles with Enterprise Groups__: For global access, you can assign Auth0 tenant-level roles directly to SCIM-provisioned groups. Any member of the synced group will automatically inherit these roles globally. - __Assign Organization scoped roles to Enterprise Groups__: You can now assign organization scoped roles to SCIM-provisioned groups. In tandem with [Auto-Membership](https://auth0.com/docs/manage-users/organizations/configure-organizations/grant-just-in-time-membership), your customers' users will automatically inherit workspace-scoped permissions the moment they log in. - __Self-Service Enterprise Configuration__: Empower your enterprise customers (or their IdP administrators) to configure SCIM provisioning for users and groups on their own through the [Self-Service](https://auth0.com/docs/authenticate/enterprise-connections/self-service-enterprise-configuration/manage-self-service-enterprise-config) flow, accelerating B2B onboarding and removing your support team from the loop. __How to get started:__ This feature will be rolled out to all public cloud environments over the next few days and to private cloud environments as per their release pipeline. SCIM Groups is available for all tenants whose Auth0 plan includes Enterprise Connections. To enable it, navigate to the Auth0 Dashboard, go to __Authentication > Enterprise__, select your SAML, OpenID Connect, Okta Workforce, or Microsoft Entra ID connection, and toggle __Sync user profiles using SCIM__ to __On__ under the __Provisioning__ tab. __Learn more:__ - [Configure Inbound SCIM](https://auth0.com/docs/authenticate/protocols/scim/configure-inbound-scim) - [Assign Roles to Enterprise Groups](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-groups) - [Self-Service Enterprise Configuration](https://auth0.com/docs/authenticate/enterprise-connections/self-service-enterprise-configuration#self-service-enterprise-configuration-workflow) - [Group Events using the Eventing Platform](https://auth0.com/docs/events)

We are excited to announce that the redesigned __Dashboard navigation and information architecture (IA)__ is now available in Beta. This update is the first step toward a more unified platform experience across Auth0, making it faster to find what you need and easier to act on everything across the platform. Alongside the IA changes, this beta also includes a significant visual refresh. ## What's in the Beta ### Flattened navigation - __Label-only group headers__ so every item is visible at a glance, reducing clicks and making pages faster to reach. - __Reorganized around common tasks__ to surface the pages you use most and match the way you actually work. - __External actions__ have moved out of the sidebar and into the top bar, keeping the sidebar focused on tenant configuration. ### Consolidated & renamed pages - __Related functionality grouped together__ to bring common tasks closer together. - __Clearer naming__ to better align functionality across the platform. ### Availability - Existing bookmarks and deep links will continue to work and you'll be automatically redirected to the new page. - This is a navigation, IA, and visual update only. All underlying functionality and APIs remain the same. ## Join the beta! If you're interested in joining the Dashboard Navigation & IA Refresh beta program, please send a request through the [Auth0 Support Center](https://support.auth0.com) or contact your Technical Account Manager (TAM) or Auth0 Sales Executive to help you out with the process.

We're excited to announce that __Dashboard Search for Applications__ is now available in Public Beta! Find your applications faster without scrolling through paginated lists.  __What's New:__ Dashboard users can now __search and filter applications__ in real time by application name, client ID, external client ID, metadata, application type, and first-party status. - __Multiple filter options__ — Combine up to 5 filters - __Guided filter menu__ with Boolean search logic - __Filters persist in URLs__ for sharing and bookmarking Rolling out progressively to Public Cloud tenants starting this week, with broader availability in the coming weeks. For detailed documentation on search capabilities, visit our [Product documentation](https://www.auth0.com/docs/get-started/auth0-overview/dashboard/search-and-filter-auth0-dashboard).

We're happy to announce that `strict` third-party applications now support machine-to-machine (M2M) access using the `client_credentials` grant type. As you expose your APIs to AI agents and partner backend services that operate without a user in the loop, you need those integrations to work within the same secure-by-default posture as the rest of your third-party application setup. This release makes that possible.  __What's included__: - `client_credentials` grant type support for `strict` third-party applications, available via the Management API and Dashboard. - Organization-scoped M2M access: `strict` third-party applications can request access tokens within the scope of a specific organization, with the same explicit grant requirements that apply to all M2M applications. Learn more about [M2M access for organizations](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications). - M2M access is intentionally restricted to applications created manually via the Management API or Dashboard. Applications registered via Dynamic Client Registration are excluded to prevent uncontrolled token issuance by unvetted third parties. To learn more, visit the [Third-Party Applications documentation](https://auth0.com/docs/get-started/applications/third-party-applications).

Boost Passkey adoption by enabling shared enrollment across subdomains. You can now customize the RP ID to allow a single Passkey to authenticate users across multiple applications under the same root domain. Now GA! Learn more: [Enable and Configure Passkey Authentication for Database Connections](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy) [Native Passkeys for Mobile Applications](https://auth0.com/docs/authenticate/database-connections/passkeys/native-passkeys-for-mobile-applications) [Passkey Authentication for Database Connections](https://auth0.com/docs/authenticate/database-connections/passkeys) -

We're excited to announce the GA release of __Token Vault with Organization Support__! ISVs building multi-tenant B2B SaaS applications and agents on Auth0 Organizations can now use Token Vault to store and exchange third-party tokens within the context of each organization their users belong to. With this release, Token Vault exchanges and the Connected Accounts flow respect `org_id` end-to-end. Tokens are scoped to `(user, org_id)`, so each organization maintains its own token records for a given user and data isolation between organizations is preserved by default. Token Vault exchanges that do not carry an `org_id` claim continue to behave as before. For complete setup instructions and more, refer to our [documentation](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault#use-with-organizations)..

We are excited to announce that we are adding __new Credentials Exchange Actions Access Token Scope Interfaces__ and they are now available in [__Early Access__](https://auth0.com/docs/troubleshoot/product-lifecycle/product-release-stages#early-access "Early Access"). These new interfaces allow you to customize the scopes to be considered when the access token is issued by writing __Credentials Exchange Actions__, considering the restrictions based on API and Client Grants definitions. __Early Access__ functionality includes: - __Add/Remove:__ New interfaces to add or remove target scopes from Credentials Exchange Actions. - __Set/Clear:__ Additional interfaces to clear or set target scopes from Credentials Exchange Actions without having to loop through the list of scopes. - __Read:__ The list of target scopes becomes available immediately after being transformed. - __Limits:__ Increased limits to handle up-to 1000 scopes for both __Credentials Exchange Actions__. - __Bonus:__ The limits were also increased for __Post Login Actions__. - __Docs:__ - __Event Object__: [https://auth0.com/docs/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-event-object#param-target-scopes\](https://auth0.com/docs/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-event-object#param-target-scopes "Event Object") - __API Object__: [https://auth0.com/docs/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-api-object#api-transaction\](https://auth0.com/docs/customize/actions/explore-triggers/machine-to-machine-trigger/credentials-exchange-api-object#api-transaction "API Object")

We're excited to announce that __Custom Token Exchange now supports Delegated Authorization__. This release is available to all __Enterprise, B2B Professional, and B2C Professional customers__. Delegated Authorization covers scenarios where a principal (e.g. a human support agent, a backend service, an AI agent) performs actions in the context of a user. Unlike traditional impersonation where the actor's identity is lost, delegated authorization preserves both identities: the `sub` claim identifies the user being acted for, while a standards-based `act` claim (per [RFC 8693](https://www.rfc-editor.org/rfc/rfc8693.html)) identifies who is actually performing the action. Every token carries a verifiable record of the delegation. With the flexibility to define custom actor semantics and authorization logic via Actions, __customers now have the tools to address emerging access patterns, including agentic AI flows, alongside traditional delegation scenarios__ like support tooling and service-to-service chains. Key __highlights__ of this release: - Actor token parameters: Pass `actor_token` and `actor_token_type` to convey the acting party's credential - `setActor()` Action command: Developers explicitly control when and how delegation `act` claim is included in tokens via the new `setActor()` method - Auth0 ID tokens as actor tokens: Automatic validation when the actor is an Auth0-managed user - Audit trail: Actor identity captured in tenant logs for compliance and traceability - Nesting support: Up to 5 levels of delegation chains for multi-hop service scenarios To learn more, visit the [Custom Token Exchange documentation](https://auth0.com/docs/authenticate/custom-token-exchange). 

We have enhanced Tenant Access Control Lists (ACLs) to provide granular control over upstream proxy infrastructure and canonical domain routing. With this update, you can now isolate traffic by enforcing distinct rules on your canonical hostnames while keeping your user-facing custom domains open. ##### What's New? * **Canonical Hostname Routing** * Match access rules directly against your canonical hostnames. This allows you to lock down backend default domains while keeping customer-facing custom domains open and accessible to your users. * **Connecting IP Verification** * Define precise allowed IPv4 and IPv6 CIDR blocks for the infrastructure (such as reverse proxies or content delivery networks) connecting directly to the Auth0 edge. * **Expanded Attribute Quotas** * The limit for Tenant ACL attributes has been increased from 10 to 20 per signal, giving you the additional flexibility needed to scale complex, multi-domain configurations seamlessly. ##### Resources To learn more about Tenant ACLs, click [here](https://auth0.com/docs/secure/tenant-access-control-list)

Federated Logout is now generally available for OIDC and Okta enterprise connections. When a user logs out with `?federated` appended to the logout URL, Auth0 calls the upstream identity provider's `end_session_endpoint` to terminate the IdP session, closing the gap where a lingering IdP session could silently re-authenticate the user on their next login attempt. Note: if federated logout is attempted without providing an `end_session_endpoint`, federated logout will not be able to be completed, and a `federated_logout_failed` tenant log will be generated. The user will be successfully logged out of Auth0 and redirected back to the application, just as with a standard (non-federated) logout. With federated logout: - Auth0 takes the burden off customers by handling IdP session termination - Customers simply indicate if the IdP session should be ended when the Auth0 logout endpoint is reached — no extra setup needed for compliant IdPs - Employers and employees have peace of mind that their data is not accessible when they logout from their applications This feature is available on all plans that include enterprise connections. Read the [documentation](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-idps ) to learn more.

Demonstrating Proof of Possession (DPoP) sender constraining for Enterprise Connections is now generally available. Customers can now establish Okta and OIDC Enterprise Connections with DPoP enabled on those connections. This is available on all plans with Enterprise Connections. DPoP for Enterprise Connections enables Auth0 to generate DPoP proofs when performing token exchange and calling userinfo endpoints on upstream OIDC and/or Okta connections. DPoP is a core building block of FAPI2 and IPSIE (Identity Proofing and Secure Identity Exchange) ecosystems. It provides a lightweight, standards-based way to enforce proof-of-possession (of a private key) without the operational overhead of mTLS token binding. Please see [product documentation](https://auth0.com/docs/authenticate/enterprise-connections/enable-dpop-enterprise-connections) for further details.

You can now delegate tenant-level user management with the **Tenant Manager** role. This allows you to offload day-to-day administrative tasks from Team Owners to dedicated managers, providing the autonomy they need without exposing sensitive configuration settings. **Key capabilities:** * **Independent administration:** Directly invite, update, and revoke tenant members without escalating to Team Owners. * **Scoped permissions:** Access is limited strictly to assigned tenants; sensitive configurations—such as connections and security logs—remain restricted to Team Owners. * **Audit trails:** All management actions are captured in Team Activity logs for full compliance and visibility. **Use cases:** * **Regional autonomy:** Empower regional leads to manage their own tenant members without granting visibility into other regional or global tenants. * **Separation of duties:** Delegate administrative tasks to specific departments while centralizing control of critical security settings at the account level. [Learn more about Teams Roles and Responsibilities](https://auth0.com/docs/get-started/auth0-teams/team-member-management#team-membership-role-comparison).

We have introduced a Dashboard configuration interface for Suspicious IP Throttling, specifically for Custom Token Exchange. This update allows administrators to easily set thresholds to throttle high-velocity traffic from suspicious IP addresses during the token exchange process. Learn more about Custom Token Exchange attack protection [here](https://auth0.com/docs/authenticate/custom-token-exchange/cte-attack-protection)

Non-Unique Emails is now Generally Available (GA) for all Auth0 customers. This feature allows multiple user accounts to share the same email address within a database connection, supporting real-world use cases like families, small businesses, and multi-role users who need separate accounts tied to the same email.

Key Details:

• Available on new database connections only (cannot be enabled on existing connections).
• Requires a different primary identifier (username or phone number) to uniquely distinguish users.
• All email communications (verification, password reset, etc.) are still sent to the shared email address.
• Once enabled on a connection, the non-unique email setting is permanent.

Documentation: Non-Unique Emails

Non-Unique Emails is now Generally Available (GA) for all Auth0 customers. This feature allows multiple user accounts to share the same email address within a database connection, supporting real-world use cases like families, small businesses, and multi-role users who need separate accounts tied to the same email.

Key Details:

• Available on new database connections only (cannot be enabled on existing connections).
• Requires a different primary identifier (username or phone number) to uniquely distinguish users.
• All email communications (verification, password reset, etc.) are still sent to the shared email address.
• Once enabled on a connection, the non-unique email setting is permanent.

Documentation: Non-Unique Emails

Auth0's ACR EA release empowers you to secure Account API token issuance by enforcing step-up authentication for sensitive scopes. Whether your users are managing their authentication factors via Universal Login or Embedded flows, you can now gate access through Actions-driven policies or enable a secure-by-default toggle. This ensures stronger security for self-service account management while maintaining a seamless experience for low-risk actions. Learn more here: API Settings Auth0 Docs My Account API Docs

Auth0's ACR EA release empowers you to secure Account API token issuance by enforcing step-up authentication for sensitive scopes. Whether your users are managing their authentication factors via Universal Login or Embedded flows, you can now gate access through Actions-driven policies or enable a secure-by-default toggle. This ensures stronger security for self-service account management while maintaining a seamless experience for low-risk actions. Learn more here: API Settings Auth0 Docs My Account API Docs

We are excited to announce that our new feature "Online refresh tokens" is now available to all customers in Beta. This powerful new feature is designed to simplify token management and modernize your application architecture, especially for Single Page Applications (SPAs) allowing you to bind refresh tokens to the sessions they originated from, which provides seamless and consistent continuation of a session when cookies are affected by the browser vendor behaviour across different applications.

What's in the Beta

✨ New configuration options

• Configure specific audiences to provide Online refresh tokens - online refresh tokens configuration is now available under the API > settings page

🔒 Applications Integration

• New scope — Request the new online_access scope to receive your online refresh tokens, which will be bound to the session
• Refresh tokens normally — Online refresh tokens will continue your application access while the session exists
• Revoke a session, revoke its refresh tokens — Once the session is revoked, all its online refresh tokens become invalid, too

🚀 Availability

• Since online refresh tokens lifecycle is entirely based on their underlying session, online refresh tokens can be issued only in OIDC flows that generate a valid session and can return refresh tokens
• Following OIDC standards, implicit sessions that do generate a session but shall not return a refresh token, will not provide online refresh tokens either

Documentation Links

Online refresh tokens documentation

Join the beta!

If you're interested in joining the online refresh token beta program, please send a request through the Auth0 Support Center or contact your Technical Account Manager (TAM) or Auth0 Sales Executive to help you out with the process