We are evaluating Auth0 Free and B2C Essentials for a public third-party MCP client using authorization-code PKCE and refresh tokens. Our API immediately records local removal even when the client is disconnected. We need fresh trusted consent to reconnect later while every old access token and old refresh authorization, including a refresh already in flight at removal, remains denied.
What supported mechanism on both Free and Essentials provides either (a) a durable authorization/family binding that can be included in access tokens and retained across refresh, with a distinct binding after fresh consent, or (b) documented revocation-completion and ordering guarantees that let the API safely admit only new authority? Please identify the exact APIs/Action properties, plan entitlements, rotation behavior and treatment of in-flight refresh and outstanding authorization codes.
We can use standard grant/device-credential administrator APIs and local API enforcement, but cannot rely on Enterprise-only event.refresh_token, refresh-token metadata, the newer refresh-token management endpoints, temporary trial privileges, or storing the customer’s raw tokens. If Free/Essentials cannot meet this outcome, please confirm that directly. No purchase or tenant mutation is requested.
Hi @mcp-dev-enquiry
Welcome to the Auth0 Community!
I understand that you are asking whether Auth0 Free or B2C Essentials plans provide either a durable authorization or family binding mechanism that persists in access tokens across refresh with a distinct binding after fresh consent, or documented revocation-completion and ordering guarantees that allow your API to safely admit only new authority after client disconnection and local token removal — without relying on Enterprise-only features like event.refresh_token, refresh-token metadata, or the newer refresh-token management endpoints.
Direct answer: Auth0 Free and B2C Essentials do not provide a supported mechanism that meets both requirements.
Here is what is available and what is not:
What is NOT available on Free/Essentials:
-
Management API refresh-token endpoints (/api/v2/users/{user_id}/refresh-tokens): Enterprise-only. This endpoint is explicitly blocked on Free and B2C Essentials plans with a feature_not_enabled error.
-
Refresh-token metadata or family-binding claims: Auth0 does not document a native “family_id” or “authorization_binding” claim that persists across refresh and changes after fresh consent. Custom claims are available on all plans, but Auth0 does not provide a built-in family binding identifier.
-
Documented revocation-completion and ordering guarantees: Auth0’s revocation semantics are documented as: “each revocation request invalidates not only the specific token, but all other tokens based on the same authorization grant.” However, there are no published guarantees about the ordering of in-flight refresh requests, authorization code exchanges, or the atomicity of revocation relative to concurrent token operations.
-
In-flight refresh token handling: No documented behavior specifies what happens to a refresh token exchange that is in-flight when revocation is initiated. The system does not guarantee that an in-flight refresh will be denied if revocation occurs during the request.
What IS available on Free/Essentials:
-
Authentication API /oauth/revoke endpoint: Available on all plans. You can revoke a refresh token by calling POST https://YOUR_DOMAIN/oauth/revoke with the refresh token in the request body. However, this revocation applies to the entire authorization grant (all refresh tokens for that user, application, and audience), not to individual tokens.
-
Custom claims in access tokens via Actions: Available on all plans, including Free. You can add namespaced custom claims to access tokens using a Post Login Action. However, Auth0 does not provide a built-in family binding or authorization binding claim, and custom claims do not automatically change after fresh consent unless you explicitly implement that logic.
-
Refresh Token Rotation: Available on all plans. When enabled, each refresh token exchange returns a new refresh token, and the old one is invalidated. However, rotation does not provide a family binding identifier, and there are no documented guarantees about in-flight refresh handling.
-
Authorization code expiration: Authorization codes expire after 10 minutes by default, but there is no documented mechanism to revoke a specific authorization code or to guarantee that an in-flight code exchange will fail if revocation is initiated.
Why this does not meet your requirements:
-
No durable family binding: Auth0 does not expose a refresh token family ID or authorization grant ID in access tokens on Free/Essentials. You cannot include a binding in the access token that persists across refresh and changes after fresh consent.
-
No revocation ordering guarantees: Auth0 does not document the order in which revocation takes effect relative to in-flight refresh requests or authorization code exchanges. Your API cannot safely rely on a revocation being processed before an in-flight refresh completes.
-
No authorization code revocation: There is no API to revoke a specific authorization code on Free/Essentials. An authorization code that is in-flight at the moment of client disconnection may still be exchangeable for tokens after revocation.
Recommended next steps:
-
Consider an Enterprise plan if your use case requires refresh-token management endpoints, family binding identifiers, or documented revocation guarantees.
-
Implement application-level authorization binding by storing a session or authorization state in your backend (not in Auth0) and invalidating it when the client disconnects. Issue a new session identifier after fresh consent. This approach does not rely on Auth0 to provide family binding or revocation guarantees, but it requires you to manage state separately.
-
Use short-lived access tokens (e.g., 5–15 minutes) and require fresh authentication after disconnection, rather than relying on refresh tokens and revocation guarantees.
We recommend contacting our Auth0 Sales Team directly to verify the current feature set for your plan and to discuss whether your use case can be met with a different plan or architecture.
Hope this helped answer your questions, please reach out to us for any other issues or requests and we will gladly look into it!
Have a great one,
Gerald