[Discussion] Refocusing node-auth0 on the Management API - Your feedback wanted

[tusharpandey13]

Hi everyone 👋

We're planning the next chapter for node-auth0 and want your input before we finalize anything.

What's happening

The auth0 package today does two jobs:

1. ManagementClient — managing your Auth0 tenant (users, connections, clients, etc.)
2. AuthenticationClient — authentication flows (login, sign-up, passwordless, token exchange, CIBA, and more)

Over the last couple of years, Auth0's JavaScript SDKs have moved toward a layered, framework-friendly architecture built around @auth0/auth0-auth-js and @auth0/auth0-server-js. These are designed specifically for authentication and work across classic and modern runtimes.

We're exploring focusing node-auth0 on the Management API and pointing authentication use cases at that newer stack. Nothing is changing in your current version, and any transition would come with a long runway, a migration guide, and tooling to make the move as smooth as possible.

Before we commit to anything, we want to hear from you. Your feedback directly shapes what we build and how we sequence it.

How you can help

If you use AuthenticationClient (or UserInfoClient) from node-auth0, we'd be grateful for a reply covering any of the following:

1. What do you use it for?

Which methods / flows do you rely on? For example:

• oauth.* (authorization code, client credentials, refresh, token exchange, PAR…)
• database.* (sign up, change password)
• passwordless.* (email / SMS)
• backchannel.* (CIBA)
• getUserInfo()
• Revoke token

2. How is it wired into your app?

• Backend framework (Express, Fastify, NestJS, Next.js, none…)?
• Node version / runtime (Node LTS, serverless/Lambda, edge/Workers…)?
• CommonJS or ESM?

3. What would make migration hard for you?

This is the most useful part for us. Don't hold back — tell us what would genuinely hurt. A few things we suspect might bite, but we'd love to hear what actually matters to you:

• Do you pass custom options per request — headers, timeouts, that kind of thing?
• Do you read anything off the response headers, like rate-limit info or request IDs?
• Are you catching specific error types, or relying on a particular error shape?
• Have you built test mocks around the current response format that you'd have to redo?
• And the big one: is there anything here that would be an outright dealbreaker?

4. Take the newer SDKs for a spin

We'd love it if you could try @auth0/auth0-auth-js or @auth0/auth0-server-js on a small slice of your app and tell us how it goes:

• What worked well?
• What's missing, or felt worse than node-auth0?
• What would make you confident to switch for real?

Even a quick "I tried X and hit Y" is hugely valuable — it tells us exactly where the rough edges are before you'd have to live with them.

What we're committing to

• No surprises. Your current version keeps working. We won't pull anything out from under you.
• We'll share back. Once we've gathered enough input, we'll post a summary and our plan in this thread.
• Migration support. Whatever direction we take, we'll ship a migration guide and tooling.

Thanks for reading and feel free to provide any feedback below.