Auth0 Release Notes

As part of our commitment to maintaining the highest security and compliance standards, we will soon be updating our authentication service configuration to increase the length and entropy of our refresh tokens. ## What is changing? We are increasing the cryptographic entropy of our issued Refresh Tokens. As a result, the string length of newly issued Refresh Tokens will increase beyond the current ~45-character baseline. ## Why is this changing? Higher entropy ensures that refresh tokens are even more resilient against brute-force attacks and key-guessing attempts. [Auth0's lifecycle policies](https://auth0.com/docs/troubleshoot/product-lifecycle#backward-compatible-non-breaking-changes) explicitly note that token formats and lengths are non-deterministic and subject to change without deprecation notices. However, we want to proactively notify you to ensure a seamless transition for your integrations. ## Who is impacted? You may be impacted if your client applications, APIs, or database schemas perform any of the following: - __Hardcoded length checks__: Validating that a token string is strictly 45 characters long. - __Fixed-size database storage__: Storing refresh tokens in fixed-width columns (e.g., VARCHAR(45) or CHAR(45)). - __Regex validation__: Employing regex patterns that enforce a maximum length limit. ## Recommended Actions - Remove strict length validations: Treat refresh tokens as variable-length opaque strings. - Update database storage: Ensure co…

We are excited to announce that __Actions Modules__ is now available in [__General Availability__](https://auth0.com/docs/troubleshoot/product-lifecycle/product-release-stages#general-availability). This feature allows you to create, manage, and share reusable code across different Actions within your Auth0 Tenant. ### Key Highlights - __Simplified Code Management:__ Reduce code duplication and improve organization by writing common logic once and importing it into any Action where it is needed. This makes your Actions easier to maintain and update. - __Cross-trigger Access:__ Reuse custom functions across multiple Actions and Triggers. - __Independent Secrets and Dependencies:__ Define independent secrets and dependencies for each Action Module. - __Improved Performance:__ Move expensive initialization work into a module that can be reused across multiple Actions. This avoids re-running the same setup code in every execution. - __Unit Testing:__ Write unit tests using helpers available at [__@auth0/actions__](https://www.npmjs.com/package/@auth0/actions?activeTab=readme). - __IntelliSense:__ Get autocompletion and type hints in your code editor when writing Actions that use your Action Modules, either in the Auth0 Dashboard or in your own editor using [__@auth0/actions__](https://www.npmjs.com/package/@auth0/actions?activeTab=readme). ### Learn More - [Actions Modules Overview](https://auth0.com/docs/customize/actions/modules)…

You can now assign a custom `user_id` to new database-connection users at signup by calling the `api.user.setUserId()` method in a `pre-user-registration` Action. Previously, Auth0 automatically generated user IDs in the standard `auth0|<id>` format for new signups. Customers who needed custom or legacy-compatible IDs had to build self-hosted signup pages or rely on bulk import. Now you can define any custom `user_id` format — UUIDs, domain-specific IDs, or IDs derived from your existing systems — directly in an Action, keeping identity consistent across imported and newly-created users. ```javascript exports.onExecutePreUserRegistration = async (event, api) => { const crypto = require('crypto'); api.user.setUserId(crypto.randomUUID()); }; ``` Custom user IDs are supported for Database connections (including custom databases with automatic migration), Universal Login sign-up, the Authentication API signup endpoint, and the Management API Create User endpoint. They are not supported for passwordless, social, or enterprise connections, or for bulk import. The custom ID must be unique within the connection and meet the same validation rules as the Management API `user_id` parameter. [Read the docs →](https://auth0.com/docs/authenticate/database-connections/custom-user-id) > **Early Access:** This feature is in Early Access and is subject to change. By using this feature, you agree to the applicable Free Trial terms in Okta's [Master Subscription Agree…

We are excited to announce the __Early Access (EA)__ release of __Member Management__ for the __My Organization API and Embeddable UI Components__. Building on the Organization Details and Identity Provider Management foundation, this release gives B2B SaaS developers everything they need to let organization administrators manage their own members — sending invitations, assigning roles, and controlling access — without building custom backend infrastructure. __Key Highlights:__ __Member Invitations__: Organization administrators can invite new members by email, pre-assign roles at the time of invitation, and route invitees through a specific identity provider or user store. Bulk invitations of up to 10 invitees are supported in a single atomic request. __Member Management__: Administrators can list and view members in their organization, with field projection and checkpoint-based pagination for large organizations. Members are automatically filtered based on the caller's access level, ensuring sensitive data is never inadvertently exposed. __Role Assignment__: Roles can be assigned to and removed from members directly through the API or UI components. Permission guardrails prevent delegated administrators from assigning roles that exceed their own permissions or assigning roles to themselves. __Member Access Level System__: A new access level model — none, readonly, limited, and full — controls what each member can see and do within an organiza…

You can now connect your existing authorization server to Auth0 for enterprise SSO, SCIM provisioning, and multi-tenant org management — without migrating your users. __What's new__ B2B Connect Beta let you layer Auth0 enterprise identity on top of your own authorization server. Early Access adds real-time visibility into enterprise directory changes, automatic session termination when an enterprise IdP ends a session, faster and more reliable discovery of which identity provider an end user's organization uses, and support for applications that don't have an external authorization server at all. __What you can do in EA__ - Stream connection events (created, updated, deleted) from your enterprise connections to a webhook, Amazon EventBridge, or your own event pipeline - Automatically terminate an active session in your application when the enterprise identity provider ends the corresponding session, keeping your app's session state in sync with the IdP - Resolve which enterprise connection an end user belongs to based on their email domain, so users land directly on their organization's SSO without extra prompts or manual configuration - Don't have your own authorization server? Connect an application directly to Auth0 — no external authorization server required — and get started faster with new quickstart guides __What stays the same__ Your authorization server remains the source of truth for sessions and tokens. B2B Connect continues to return an enriched ID tok…

You can now stream real-time notifications when an enterprise connection changes — without polling the Management API. __What's new__ Previously, detecting changes to an enterprise connection (a new SSO connection added, an existing one updated, or one removed) required polling the Management API on a schedule. With connection events, Auth0 notifies you the moment a change happens. __What you can do in EA__ - Subscribe to connection.created, connection.updated, and connection.deleted events for your enterprise connections — Azure AD, ADFS, Google Workspace, Active Directory, LDAP, and Ping - Deliver events to a webhook or Amazon EventBridge - Consume events as CloudEvents-formatted JSON, so they work with your existing event tooling __What stays the same__ Enterprise connection management via the Dashboard and Management API is unchanged. Connection events are additive — you don't need to change how you create or manage connections to start using them. To learn more, review the Connection Events [documentation](https://auth0.com/docs/events). By using Connection Events, 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\](https://www.okta.com/agreements).

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](“https://auth0.com/docs/secure/tenant-access-control-list/deny-all-tenant-acl”)

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](https://auth0.com/docs/manage-users/my-organization-api).

 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](https://auth0.com/docs/get-started/auth0-overview/dashboard/use-dashboard-navigation#enable-auth0-dashboard-navigation)

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](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors) [Configure Email MFA notifications ](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-email-notifications-for-mfa) [Configure SMS and Voice MFA notifications](https://auth0.com/docs/secure/multi-factor-authentication/multi-factor-authentication-factors/configure-sms-voice-notifications-mfa)

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](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) - 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](https://auth0.com/docs/ai-agents-mcp/cross-app-access/requesting-app). By using Cross-App Access Requesting App, you agree to the applicable Free Trial terms in Okta’s Master Subscription Agreement and Okta’…

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](https://auth0.com/docs/authe…

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

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](https://auth0.com/docs/authenticate/database-connections/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…

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

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 - __…

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](https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/google-directory-sync) - [Manage Self-Service Enterprise Configuration](https://auth0.com/docs/authenticate/enterprise-connections/self-service-enterprise-configuration/manage-self-service-enterprise-config)

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.

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](https://auth0.com/docs/ai-agents-mcp/agents-as-principal).