Auth0 Release Notes

### 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: ```json 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 te…

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.

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](https://auth0.com/docs/secure/call-apis-on-users-behalf/token-vault/privileged-worker-token-exchange-with-token-vault#privileged-worker-token-exchange-with-token-vault).

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](https://auth0.com/docs/manage-users/organizations/organization-roles "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\](https://www.okta.com/agreements.).

**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](https://auth0.com/docs/manage-users/organizations/configure-organizations/grant-application-access "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 fou…

__Dashboard Search for Organization members is now available in Public Beta!__ Find your organization members faster without scrolling through paginated lists. Users can now __search Organization Members in real time by name, email, ID and filter by blocked status.__ 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 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](https://auth0.com/docs/ai-agents-mcp/cross-app-access).

When generating a Self-Service Enterprise Configuration ticket, you can now delegate the third-party application access decision to your customer's customer admin — rather than setting it yourself at ticket creation time. Enable third-party access delegation on the ticket, and the customer admin will see a new step in the setup wizard where they can choose to allow third-party applications to use their SSO connection. If they enable it, the connection is configured for third-party application access. If they skip it, the setting is not applied. When the option is omitted, the wizard experience is unchanged. This option is mutually exclusive with setting domain connection access directly on the ticket — you either set the value directly or delegate it to the customer admin, not both. **Note:** If the connection is associated with an Auth0 Organization and you want third-party applications to authenticate users through that organization, you must separately configure the organization to allow third-party client access after setup is complete. [Learn more](https://auth0.com/docs/authenticate/enterprise-connections/self-service-enterprise-configuration/manage-self-service-enterprise-config)

We are excited to announce that Anonymous Sessions is now available in Beta for Auth0 customers with paid plans. This feature enables applications to create and manage stateless sessions for unauthenticated users, supporting use cases like guest checkout, shopping cart persistence, and pre-login personalization. ### What's in the beta: - __A new Core Endpoint:__ POST /anonymous/token – Create sessions, refresh sessions, request access tokens - __Seamless Session Linking:__ Link anonymous sessions to authenticated users through pre-registration and post-login actions. - __Activity Preservation:__ All anonymous session data from different devices can follow the authenticated user profile upon login. #### ✨ New configuration options - **Configure your anonymous sessions length** - Anonymous Sessions length configuration is now available as a tenant setting - **Configure your clients and APIs to allow for anonymous sessions** - Anonymous Sessions configuration is now available in Applications and APIs #### 🚀 Use Cases: - Guest checkout flows in e-commerce applications - Pre-login personalization and recommendations - Seamless user onboarding with continuity on known data - Cross-device continuity ## Documentation Links [Anonymous sessions documentation](https://auth0.com/docs/manage-users/sessions/anonymous-sessions) ## Join the beta! If you're interested in joining the anonymous sessions beta program, please send a request through the [Auth0 Support Cente…

Third-party applications now work with Auth0 Organizations. Tenant admins can allow or block third-party app access on a per-organization basis — access is blocked by default, so existing organizations are unaffected until you explicitly opt in. - To authenticate users within an organization, a third-party app's connection must be promoted to domain level (`is_domain_connection: true`). - User consent is scoped per organization — granting access in one organization does not carry over to another.  To learn more, read [Enable third-party application access for an Organization](https://auth0.com/docs/manage-users/organizations/configure-organizations/enable-third-party-application-access).

Auth0 now supports the session_expiry claim for Okta and OIDC-based Enterprise connections, in alignment with the IPSIE SL1 profile. When your upstream identity provider includes a session_expiry value in the ID token, Auth0 uses it to enforce the ceiling on the Auth0 session lifetime — evaluated as the minimum of the IdP claim, your tenant's absolute session expiration, and any expiry set via Actions. This closes a real gap in federated sessions: when a federated user's access expires at their IdP, their Auth0 session terminates accordingly — no stale sessions, no residual access. Enable it on any Okta/OIDC Enterprise connection via the Dashboard or Management API. For end-to-end enforcement down to your downstream applications, deploy a Post-Login Action to inject the final session_expiry value as a custom claim in the Auth0-issued ID token. Note: Supported on Okta/OIDC Enterprise connections only. SAML connections are not supported. This feature implements the evolving IPSIE SL1 open standard. See the [product documentation](https://auth0-feat-session-expiry-oidc-ipsie.auth0-mintlify.app/docs/authenticate/enterprise-connections/session-expiry-enterprise-connections)

We are excited to announce the release of our new __Outbound SCIM Action template for Event Streams__! This new capability delivers an infrastructure-free way to push `user.created`, `user.updated`, and `user.deleted` events directly from Auth0 to any `SCIM 2.0`-compliant downstream application, making it easier than ever to automate your user provisioning workflows. __Key Highlights:__ - __Infrastructure-free provisioning__: Use our ready-to-copy [Outbound SCIM Action template](https://github.com/auth0/opensource-marketplace/tree/main/templates/outbound-scim-EVENT\_STREAM) to translate Auth0 user events into standard `SCIM 2.0 REST` requests (`POST`, `PUT`, and `DELETE`). This eliminates the need to build, host, or maintain custom webhook consumers. - __Template-driven customization__: You retain full control over your provisioning logic. Edit the script to map specific Auth0 attributes to your downstream `SCIM` schema, or enable opt-in behaviors like `UPSERT` (create-on-update) for trickling in users. - __Built-in fault tolerance__: The template script handles API timeouts and retries for transient failures natively. __How to get started:__ To use this feature, navigate to __Event Streams__ in the Auth0 Dashboard, create a new stream with __Auth0 Actions__ as the destination, and apply the __Outbound SCIM provisioning template__. *Note: Because the Event Stream only reacts to new events, we recommend performing a on…

We're excited to announce that **Refresh Token Metadata** is now **Generally Available** for Enterprise customers. Refresh Token Metadata allows you to attach custom key-value pairs to refresh tokens, enabling richer context storage and more personalized authentication experiences. ### What's included in the feature **Store Custom Data on Refresh Tokens** You can now attach up to 25 custom key-value pairs to each refresh token. This metadata persists throughout the token's lifecycle and can be accessed or modified via the Management API. ```javascript // In Post-Login Action exports.onExecutePostLogin = async (event, api) => { api.refreshToken.setMetadata('deviceName', event.request.user_agent); api.refreshToken.setMetadata('loginRegion', event.request.geoip?.countryCode); api.refreshToken.setMetadata('orgContext', event.organization?.id); }; ``` **Management API Support** Access and manage refresh token metadata programmatically: - `GET /api/v2/refresh-tokens/{id}` - Retrieve token with metadata - `PATCH /api/v2/refresh-tokens/{id}` - Update token metadata - `DELETE /api/v2/refresh-tokens/{id}` - Revoke token Learn more about Refresh Token Metadata in our [documentation](https://auth0.com/docs/secure/tokens/refresh-tokens/refresh-token-metadata) and our [blog](https://auth0.com/blog/auth0-session-refresh-token-metadata-guide/)

We are happy to share that Google Workspace Directory Sync for Groups is now available in Early Access without enrolment! All [previously announced](https://auth0.com/changelog#3sQ4fmmnZQuIAu9jZBoBOS) Early Access capabilities including automated group synchronization, "Sync all" functionality, and partial group selection are now available out-of-the-box without enrolment. Additionally, you can now natively assign groups synced through Google Workspace to Auth0 tenant-level RBAC roles and Auth0 organization-specific roles, allowing group members to automatically inherit correct permissions when they log in. This update is available to all customers in public cloud today, and will be gradually rolling out to private cloud environments in the coming weeks. To get started, navigate to your Google Workspace enterprise connection in the Auth0 Dashboard and configure your group synchronization preferences. Learn more in our public documentation: - [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) - [Assign Roles for Enterprise Groups](https://auth0.com/docs/manage-users/access-control/configure-core-rbac/rbac-users/assign-roles-to-groups)

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