Auth0 Release Notes

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

We're excited to announce Agents as Principal is now in Early Access, giving AI agents a first-class identity in Auth0 - distinct from human users and clients. If you're running agents in production today, they're likely standing in as a shared client or user identity, which means you can't tell which agent acted, track it when it's acting for someone else, or separate its traffic from a human's. This release gives every agent its own identifier, credentials, and audit trail so you can!

• Know Exactly Which Agent Acted: Every agent gets a unique identity of its own, instead of hiding behind a shared client or a user account. You can create and manage agent identities directly, so "who did this" has a real answer.
• Track Delegation End to End: When an agent acts on a user's behalf, the full chain - who delegated, to which agent, through which app - is encoded in the token and auditable through every hop.
• Bring Your Existing Agents In: Already running agents outside Auth0 through your own registry, an MCP server, or elsewhere? Associate the identifier you already use internally with an Auth0 client, so you're not re-provisioning agents you've already built.

To enable the Agent as Principal Early Access release in your Auth0 tenant once available in your environment, please contact your Auth0 Account Team.

Learn more in the documentation.

Original source

We're thrilled to announce Token Vault Privileged Worker is now in Early Access, letting your autonomous agents pull a user's third-party tokens - Gmail, Drive, Slack, and more - from Token Vault with no user session required.

Token Vault today assumes a human is actively logged in to hand over their token; if your agent runs on a schedule, in CI, or wakes up at 2am with no one signed in, there may not always be a user signed in. Privileged Worker gives your background agents their own strong credential to authorize that exchange directly.

With privileged worker, you can register a trusted worker identity, authenticate it with Private Key JWT or mTLS, and it can request a specific user's third-party token directly from Token Vault. We give you the ability to pin each worker credential to specific connections and scopes, so a compromised credential can only reach what it was actually authorized for.

To enable the Privileged Worker Early Access release in your Auth0 tenant once available in your environment, please contact your Auth0 Account Team.

Learn more in the documentation.

Original source

We now have an expansive Actions Reference Catalog available to dive deeper into Actions Triggers and their Event and API Objects. Within this new catalog, you can reference the event and api objects available to Auth0 Actions for each trigger, detailing the transaction data you can read and the methods you can call from your custom code.

Try out the new Actions Reference Catalog here: https://auth0.com/docs/actions/reference

Original source

You can now create roles scoped to individual organizations — without metadata workarounds or custom Actions logic.

What's new

Auth0 Organizations previously required you to share tenant-wide roles across all your customer organizations. With org-scoped roles, each organization gets its own role definitions, independent permissions, and user assignments.

What you can do in EA

• Create, update, and delete roles within a specific organization via the Management API or Dashboard
• Assign org-scoped roles to users and enterprise groups
• Pre-assign a role when inviting a user to an organization

What stays the same

Existing tenant-level RBAC is unchanged. Tenants not using org-scoped roles are unaffected.

To learn more, review Organization Roles.

By using Organization-to-Application Entitlement, 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

Organization-to-App Entitlement lets you control which applications the members of an organization can access - natively, without custom code.

If you sell multiple products and different customers have purchased different combinations, you can now enforce those boundaries directly in Auth0. When a member of an org tries to log in to an app they're not entitled to, Auth0 denies access automatically. No Actions. No metadata checks. No custom logic to maintain.

Opt-in, per org. Entitlement enforcement is disabled by default - existing orgs and login flows are unaffected until you explicitly enable it. You can roll out to one org at a time, making it safe to adopt incrementally.

Safe to configure before you go live. You can set up all your entitlements first, then enable enforcement when you're ready. There's no risk of locking members out during configuration.

To learn more, review Grant Per-Application Access to an Organization.

By using Organization-to-Application Entitlement, 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're excited to announce that Cross App Access (XAA) for Resource Applications is now in Open Early Access. You can use this feature in production today at no additional cost through Auth0 Enterprise Connections, available to Enterprise, B2B Pro, and B2B Essential customers, or test it during the trial period on Free tenants.

Cross App Access (XAA) is a new open standard for passing authorization across domains, built for the emerging Enterprise AI landscape, enabling seamless agent-to-app and app-to-app connections. Connecting AI Agents and Third-Party Apps in an enterprise introduces two key challenges: poor IT visibility into data sharing, and repetitive user consent flows. XAA solves this by centralizing IT control over these connections, eliminating consent fatigue while improving governance and visibility into data sharing.

This release is for the Resource App side: any Auth0 customer looking to expose their MCP servers and APIs to AI Agents and other enterprise applications. No code changes are needed: simply configure the feature on your Auth0 tenant to instantly support central policy enforcement and a seamless user experience. XAA supports both SAML and OIDC enterprise IdPs, with specific support for Okta.

To learn more, read our documentation.

Original source