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 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 columns storing refresh tokens use variable/flexible string sizes.

Timeline

Newly minted refresh tokens will start to have bigger sizes in the coming weeks.

Existing active sessions and existing refresh tokens will remain valid until expired or revoked; only newly issued tokens will reflect the updated length.

Questions?

If you have any questions or require support during this transition, please reach out to Support

Original source

We are excited to announce that Actions Modules is now available in 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.
• 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.

Learn More

• Actions Modules Overview
• Write Your First Action Module
• Test an Action Module
• Action Module Guidelines
• @auth0/actions

Original source

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.

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 →

> 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 Agreement.

Original source

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 organization, computed automatically from the member's organization connection access levels.

Permission-Aware UI Components: UI components automatically show or hide actions based on the authenticated user's effective permissions, surfaced directly from the ID token — no additional API call required.

B2B Observability: Tenant log events are emitted for all member, invitation, and role operations, giving developers full visibility into administrative activity.

Why This Matters

Member Management is the core of any B2B administrative experience. This release eliminates the need for custom-built invitation flows, role assignment UIs, and access control logic — replacing weeks of development work with a governed, embeddable solution that scales with your customers.

This feature is available for all tenants. To begin, navigate to the Applications > APIs section of your Dashboard to activate the My Organization API.

To learn more, read the My Organization API documentation and if you have any feedback, give us a shout in our community channel!

Original source

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.

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.

Original source

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 token that your server uses to mint its own — nothing changes about how you issue or manage tokens for your users.

To learn more, review the B2B Connect documentation.

By using B2B Connect, 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

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