Auth0 Release Notes

You can now configure a Deny All rule within your Tenant Access Control List (ACL) to reject all incoming traffic to your assigned scope.

By utilizing the new match_all: true attribute, this rule bypasses specific signal matching (such as IP or geolocation) to apply comprehensive protection across the full tenant scope.

When assigned a high priority value, it acts as an effective fallback rule to secure your platform against unauthorized requests.

Resources

Docs: Configure Tenant ACL Deny All Rule

Original source

We're excited to announce that self-service configuration of Third-Party Application Access and Cross App Access (XAA) is now available through the My Organization API and Embeddable UI Components, in Open Early Access. This capability is available to all customers - configuring XAA specifically follows the same availability as Cross App Access (XAA) for Resource Applications itself.

Instead of routing every configuration change for your existing or new customers through your team and the Auth0 Dashboard, your customers' own Organization Admins can now self-service configure, within guardrails you set upfront:

• Third-party application access for their Organization
• Third-party application access for a connection of their Organization
• The Cross App Access (XAA) Resource Application role for a connection

Each setting is independent and you retain full control over which settings are delegated and which values Organization Admins can choose. Enabling XAA additionally requires the connection's identity provider to use a domain verified for the associated Organization, keeping cross-app authorization scoped to identity providers your customers actually control.

To learn more, read our documentation.

Original source

We're excited to announce that the Dashboard Navigation & IA Refresh is now available in Early Access, bringing a redesigned sidebar, improved information architecture, consistent, breadcrumbs, and a modernized visual experience to the Auth0 Dashboard.

How to Enable

The new navigation is available as an opt-in feature per user account upon login. Simply click "Try now" when the popup appears, or toggle it anytime from your profile menu in the top-right corner.

This update is available to all customers in public cloud, and will be gradually rolling out to private cloud environments in the coming months.

Learn More

Dashboard Navigation Documentation

Original source

We are happy to announce that Advanced MFA Configurations are now Generally Available! This is a highly awaited capability that allows customers to completely tailor their user's MFA Journeys to their security and UX needs

With Advanced MFA Configurations you can:

• Change the period that we will "Remember this device" for MFA purposes, from a minimum of 1 hour to a maximum of 30 days idle lifetimes and 90 days absolute lifetimes (from the previously fixed 30 days for both)
• Configure the OTP lengths for SMS and email MFA factors, between 4 to 10 digits (From the previous fixed 6 digits)
• Configure the OTP lifetime for SMS MFA (between 30 seconds and 1 hour) and email (between 5 minutes and 1 hour)

Learn more

Configure MFA

Configure Email MFA notifications

Configure SMS and Voice MFA notifications

Original source

We're excited to announce that Auth0 now supports acting as a requesting application in Cross-App Access flows in Early Access.

Today, every user has to click "Connect your account" for every integration, in every app, one at a time. For AI agents, assistants, and ISVs onboarding enterprise customers, that's friction on every new integration and every new user. Cross-App Access Requesting App removes it: apps that authenticate enterprise users can now fetch a third-party API token for that user without asking them to manually connect the account first. Auth0 gets it directly via the user's existing IdP trust relationship.

Key highlights:

• Built on Auth0 Token Vault, using the ID-JAG (Identity Assertion Authorization Grant) protocol
• Org-aware: in multi-org tenants, connection resolution respects org_id — rejecting the request if the enterprise connection or target resource app isn't enabled for that organization, or if the org context is ambiguous across multiple identities
• New Dashboard toggle to enable it on enterprise connections
• Currently supported on OIDC and Okta Workforce connections

To learn more, visit the Cross App Access Requesting App documentation.

By using Cross-App Access Requesting App, 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 at https://www.okta.com/agreements.

Original source

We are excited to announce that Custom Token Exchange is now Generally Available. This feature is available to all Enterprise, B2B Professional, and B2C Professional customers, as well as part of the Trial period for free tenants.

Custom Token Exchange lets your application exchange an existing token — issued by Auth0, or by an external identity provider — for Auth0 access, ID, and refresh tokens, using custom Action logic that you fully control. Requests are validated and authorized by your Custom Token Exchange Action before Auth0 issues tokens for the resulting session, giving you the flexibility to support advanced integration use cases such as migrating users to Auth0, integrating with an external identity provider, or getting Auth0 tokens for another audience.

Custom Token Exchange also underpins Auth0's delegated authorization model, letting a service, AI agent, or support agent act on behalf of a user — whether to call APIs for them or, via Session Delegation, to establish a web session as that user.

Key incremental highlights of this release:

• Dashboard support: Create and manage Custom Token Exchange Profiles and their associated Actions directly from the Auth0 Dashboard
• Shared transaction context: Set transaction metadata in your Custom Token Exchange Action and read it from your Post-Login Action, to customize the resulting tokens based on information from the subject or actor token

To learn more, visit the Custom Token Exchange and Custom Token Exchange Use Cases documentation.

Original source

Custom Rate Limits allow Auth0 Customers to limit the amount of RPS their first-party, third-party, or CIMD apps can consume, so as to mitigate the risk that any one Client can exhaust the customer’s Tenant Rate Limit Entitlement on their tenant’s Authentication API Rate Limit Policy.

Key Early Access Features:

• API-based self service configuration of Custom Rate Limit Policies to limit the number of Authentication API - OAuth requests that can be consumed by individual clients or group of clients (all third-party apps, or CIMD apps) can consume
• Configure Rate Limit Policy enforcement to more safely rollout policies. Enforcement can be configured to block requests, or trigger non-blocking notifications.

Visit the Docs here: https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy/custom-rate-limit-policies

Original source

The Flexible Password Policy for database connections is now generally available.

The Flexible Password Policy replaces Auth0's legacy password configuration with a single options.password_options object, giving you more granular control over how passwords are validated on your database connections:

• Composition — set a minimum length, require specific character types, and block sequential or repeated characters
• History — prevent password reuse across a configurable number of previous passwords
• Dictionary — block common passwords using a 10,000- or 100,000-word list, plus your own custom entries
• Profile data — block passwords containing values from the user's profile, with a configurable field list

You can configure it in the Auth0 Dashboard under Authentication > Database > [your connection] > Authentication Methods > Password, or through the Management API. To learn more, read Flexible Password Policy.

New database connections now use the Flexible Password Policy by default

As of July 2026, new database connections are created with the Flexible Password Policy applied by default. If you create a database connection without specifying a password configuration — through the Dashboard, the Management API, the Deploy CLI, Terraform, or an Auth0 SDK — it will use these defaults, which align with current NIST password guidance:

Setting Default Minimum password length 15 Required character types None Maximum length exceeded Error Sequential characters Allowed Identical characters Allowed

Your existing database connections are unchanged. They keep their current password configuration until you choose to migrate them.

If you create database connections programmatically

If your automation creates database connections and configures password rules using the legacy fields (passwordPolicy, password_complexity_options, password_history, password_no_personal_info, password_dictionary), review the following before your next deployment:

• On update, PATCH /api/v2/connections/{id} returns 400 invalid_body if the request contains both password_options and legacy password fields. If your integration reads a connection and writes it back with legacy fields added, send only password_options instead.

To migrate your payloads, see the legacy-to-flexible field mapping in Enable the Flexible Password Policy.

Continuing to use legacy password policies

Legacy password policies remain supported, and there is no end-of-life date for them. If you prefer to keep a legacy configuration on a new connection, remove options.password_options from the connection using the Management API. Should we deprecate legacy password policies in the future, we will announce it here with at least 12 months' notice and a migration guide.

If you need additional time before this default applies to your tenant, contact Auth0 Support.

Original source

Your custom signup and login fields and consent checkboxes configured in Universal Login now capture the same data on Social and Enterprise connections as they already do on database and passwordless.

Previously, a user signing up through a social button or an enterprise identity provider could skip past those fields entirely, since they only appeared on database and passwordless connections.

No configuration changes are needed: existing Custom Prompts setups now apply the same way across every connection type.

Configure or review your setup in the Dashboard under Branding → Universal Login → Enhance screens with partials, or via the Management API.

Learn More: https://auth0.com/docs/customize/login-pages/universal-login/customize-signup-and-login-prompts

Original source

Auth0 now supports Session Delegation via Custom Token Exchange

We're excited to announce that Auth0 now supports Session Delegation via Custom Token Exchange. This release is available to all Enterprise, B2B Professional, and B2C Professional customers.

Session Delegation builds on Custom Token Exchange's delegated authorization model to cover a common use case: letting an authorized actor, such as a support agent, establish a web session as another user, so they can navigate your application on that user's behalf rather than only calling APIs for them. As with delegated authorization, both identities are preserved throughout: the sub claim identifies the user the session belongs to, while the standards-based act claim (per RFC 8693) identifies who is actually acting. Every delegated session carries a verifiable, auditable record of who did what on whose behalf.

Key highlights of this release:

• Session Transfer Token: Requesting a Custom Token Exchange token with a special session_transfer audience returns a Session Transfer Token instead of an access token, authorized by the same Action logic you already control for delegation
• Seamless redemption: Redirect the browser to the target application, which redeems the token through the standard /authorize endpoint — no extra login step for the user being acted for
• Built-in guardrails: Delegated sessions are short-lived, issue no refresh tokens, skip MFA/consent prompts by design, and can be bound to the requesting IP address
• Dedicated audit trail: Delegated logins generate distinct tenant log events, separate from regular logins, for compliance and traceability

To learn more, visit the Session Delegation and Custom Token Exchange Use Cases documentation.

Original source

We’re excited to announce that support for Group and Group Membership in Google Workspace Inbound Directory Sync is now Generally Available (GA) for all Auth0 customers!

What’s new:

• Paginated Dashboard UI: Tenant admins can now easily browse, filter, and search groups from their Google Workspace directory using a paginated, searchable table directly in the Auth0 Management Dashboard.
• Self-Service Selective Group Sync: You can now empower your enterprise customers’ IT teams to self-configure Google Workspace Directory Sync and selectively sync all groups, or a subset of groups through the Self-Service assistant flow. This same paginated, searchable table is fully integrated into the self-service assistant setup flow, giving your customers’ admins complete control over their synchronized selection set.

Learn more:

• How to Sync Google Workspace Users and Groups to Auth0 with Directory Sync
• Manage Self-Service Enterprise Configuration

Original source

We're expanding Organizations Search with powerful new filtering capabilities.

What's New

Find organizations using:

• Name — Search by unique organization identifier
• Display name — Search by human-readable display name
• ID — Exact organization identifier lookup
• Metadata — Filter by custom key-value pairs
• Third-party client access — Filter by access policy (allow or block)
• App entitlement active — Filter by app entitlement status

How It Works

Navigate to Auth0 Dashboard > Organizations and use the search bar to build filters. Combine up to 5 filters simultaneously with AND/OR logic. Filter pills persist in the URL so you can share or bookmark filtered views.

Rolling out progressively to Public Cloud starting this week, with broader availability in the coming days.

Original source

We're excited to announce that Global Search is now in Beta, bringing entity search directly to the Command Palette (Cmd+K).

What's New

Search across your Auth0 tenant in real time:

• Applications, APIs, Organizations, and Users — Find by name, ID, email, or identifier
• No syntax required — Plain text search with instant results
• Copy identifiers instantly — One click to grab IDs
• Direct navigation — "View more" links take you to filtered entity lists for additional results

This update is available to all customers in public cloud, and will be gradually rolling out to private cloud environments in the coming months.

Original source

Enterprise Connect is now in Beta. It lets you use Auth0 as a modular B2B identity layer. You can federate your existing SAML or OIDC capable authorization server to Auth0 and layer on enterprise SSO, user provisioning, and self-service onboarding / setup capabilities for B2B use cases.

A guided setup walks you through federating over OIDC or SAML, including Okta as a connection strategy, configuring the integration, self-service onboarding, adding user profile claims into ID tokens using Actions code, and wiring up outbound SCIM user provisioning. Connection lifecycle events (connection.created, connection.updated, connection.deleted) keep your local domain map in sync as customers onboard.

Please contact the Sales team if you would like to evaluate Enterprise Connect Beta.

Original source

Overview

Curated Blocklists extend Auth0 Tenant Access Control Lists (ACLs) by integrating dynamically updated threat intelligence directly into your Tenant ACL rules.

Instead of manually tracking and updating individual IP ranges or ASNs, Attack Protection customers can delegate IP risk management to Auth0 Threat Intel, ensuring continuous, automated protection against evolving threat vectors.

Available Categories

Referencing curated categories using the auth0.<category> prefix allows precise blocking based on traffic origin:

• auth0.low_reputation: High-risk IP addresses identified as active threat vectors or origin points.
• auth0.tor: Active TOR exit nodes.
• auth0.proxy: Residential, data center, or public proxies.
• auth0.vpn: Commercial Virtual Private Network (VPN) providers.
• auth0.icloud_relay_proxy: Egress nodes for Apple iCloud Private Relay traffic.

API Request Structure

To configure curated lists, pass the desired identifiers in the auth0_managed array within the match object of your rule definition:

POST /api/v2/network-acls
{
"description": "Block low-reputation IPs",
"active": true,
"priority": 1,
"rule": {
"action": {
"block": true
},
"match": {
"auth0_managed": [
"auth0.low_reputation"
]
},
"scope": "authentication"
}
}

Configuration & Exception Handling

Configure curated blocklists via the Network ACLs Management API inside the auth0_managed matcher block. We recommend testing each category in your environment prior to enforcement. If a curated list blocks a legitimate user or IP, configure a higher-priority ACL rule that executes ahead of the managed list to explicitly allow the traffic.

For setup guides and details on Curated Blocklists and Tenant ACLs, check these links:

• Use Curated Blocklists
• Configure Tenant ACLs

Original source