We’re an Auth0 Enterprise customer and are currently evaluating several Early Access features for use in our production environment, including:
My Account API
Passkey Native SDK
Auth0 Library Modules
Auth0 Token Exchange
We understand that Early Access features can be used in production and that minor changes may occur before General Availability.
We have a few questions:
If changes are made to an Early Access feature that require updates to customer implementations, how are customers notified and what notice period is typically provided?
Does Auth0’s standard deprecation and migration process apply to Early Access features if customer action is required?
For Auth0 Token Exchange:
Does usage count towards M2M, MAU, or neither?
Are there any additional licensing or billing implications?
Are there any specific rate limits, quotas, or production-use considerations that we should be aware of?
We’re assessing the operational and commercial impact of adopting these features in production and would appreciate any guidance from the Auth0 team or customers with experience using them.
For GA features, we will notify users in regards to breaking changes that will require the reconfiguration of your environment. This is not true for EA features.
If a breaking change or API modification is required for an EA feature, Auth0 typically notifies the designated Tenant Administrators via email, posts updates in the Auth0 Community, and updates the official Auth0 Changelog. However, there is no officially guaranteed notice period. Changes can occur rapidly as the Product team iterates based on early customer feedback.
Auth0’s standard deprecation process does not apply to EA features. The standard process guarantees long migration windows and legacy support overlapping with new releases. With EA features, Auth0 reserves the right to alter interfaces, change behaviors, or (in rare cases) completely roll back the feature without the standard long-term deprecation runway.
If you use EA features in production, your engineering team must have the agility to refactor implementations with relatively short notice if the underlying API changes before GA.
Token Exchange (based on RFC 8693) allows an application to swap an existing token for a new Auth0 token. Here is how it impacts your tenant:
MAU: If the token being exchanged belongs to a user (e.g., acting on behalf of a user), that user will count as a Monthly Active User (MAU) for the billing period if they haven’t already been counted.
M2M Quotas: The actual transaction of hitting the /oauth/token endpoint with a token exchange grant type typically consumes your Machine-to-Machine (M2M) token quotas . Because Token Exchange involves backend services requesting tokens, Auth0 meters this similarly to Client Credentials grants.
Licensing and Billing Implications
Currently, in EA, the feature itself may not have a distinct line-item cost, but the volume of tokens you exchange will eat into your Enterprise M2M allotted limits. Furthermore, Auth0 imposes an Entity Limit of 100 Custom Token Exchange Profiles per tenant. If your architecture requires more profiles, you will need to negotiate that with your Account Executive. Once the feature hits GA, Auth0 may introduce specific add-on pricing for high-volume exchange usage, similar to how Enterprise Connections are billed.
Rate Limits and Production Considerations
Token Exchange endpoints have significantly stricter rate limits than standard login endpoints to prevent abuse.
For Enterprise Public Cloud environments, the strict rate limits are:
→ Custom Token Exchange: 15 requests per second (Sustained & Burst).
→ On-Behalf-Of Token Exchange: 30 requests per second (Sustained & Burst).
To provide some additional context, we’re currently trying to build a passkey enrollment experience within Universal Login that gives us more control over when and how passkeys are introduced to users.
From our investigation so far, we haven’t found a supported way to:
Present passkey enrollment at a specific point in the Universal Login journey.
Initiate passkey enrollment based on our own flow logic.
Continue a custom journey after passkey enrollment has completed.
Because of this, we’re currently relying on a combination of:
Custom Token Exchange
My Account API endpoints to list and enroll passkeys
Auth0 native screens + Auth0 Forms + Auth0 Custom Actions
These capabilities appear to be the building blocks needed to achieve the experience we’re looking for.
With that in mind, we had a few follow-up questions:
If changes are introduced to any of these Early Access capabilities before GA, will an alternative mechanism or replacement capability be available at the time the changes are introduced so we have a path to update their implementations?
If an Early Access capability is ultimately removed, will a supported replacement be made available before or at the time when the capability is retired?
Does the M2M token quota apply to both Custom Token Exchange and On-Behalf-Of Token Exchange, or only one of these flows?
Are refresh token exchanges (token refresh operations) also counted towards the M2M token quota?
I am sorry for the delayed reply to your follow-up questions!
To answer your questions directly:
EA Changes: Auth0 aims to provide migration paths and alternatives for breaking changes, but because these features are EA, a seamless, immediate replacement is not contractually guaranteed at the exact moment of a change.
EA Removal: If an EA feature is entirely retired instead of graduating to General Availability (GA), Auth0 will issue an End-of-Life (EOL) notice. However, a supported 1:1 replacement is not guaranteed.
M2M Quota for Token Exchange: Neither Custom Token Exchange nor On-Behalf-Of (OBO) Token Exchange consumes your M2M token quota.
Refresh Tokens: Refresh token exchanges do not count towards your M2M token quota; they are tied to user flows and MAU.