v4: Looks like all code in constructing Auth0Client must be edge-compatible. Can we lift this?

[pcpLiu]

Checklist

• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Describe the problem you'd like to have solved

Hi,

We are currently migrating to v4 from v3. One frustrating issue is that when constructing Auth0Client on the option beforeSessionSaved, we met some edge runtime issue. Turns out, we cannot use any non-edge API in those code.

Describe the ideal solution

Can we lift this restriction? We are relying on some 3rd party libraries to do logic verifications and this dramatically limit our capabilities

Alternatives and current workarounds

No response

Additional context

No response

[hgmeza]

+1

my company is using a deployment service where functions@edge, middleware@edge (anything in the edge) is not supported. In V3, we were able to leverage withPageAuthRequired and withApiAuthRequired from the sdk where they did not run at the edge.

I am unable to find docs that differentiate different apis nor find documentation where the v4 auth0 apis are running on. Are there equivalents of withPageAuthRequired in v4? How can I authenticate on a non-edge runtime? Docs state that the default behavior is to run on edge. That gives me the impression I can do the non-edge as well but I am unable to find that on the docs.

[tusharpandey13]

Thank you for highlighting this issue.

In v4, we've made architectural changes to support Next.js App Router and Edge Runtime, which means that code used in Auth0Client construction (including hooks like beforeSessionSaved) must be edge-compatible.
This is a deliberate design decision to ensure the SDK works seamlessly in all Next.js environments, including Edge Functions and Middleware, which have stricter runtime limitations.

While we don't plan to remove this constraint entirely (as it would compromise our edge compatibility), we're exploring some potential solutions:

1. Creating a separate "node-only" entry point that doesn't have these constraints
2. Adding a configuration option to explicitly opt out of edge compatibility
3. Providing helper utilities that bridge between edge and Node.js environments

We are also open to community suggestions on how to tackle this problem efficiently.

Could you share more about your specific use case and which third-party libraries you're trying to use? This would help us prioritize and design the right solution.

In the meantime, you might consider moving non-edge-compatible code outside the Auth0Client construction and implementing a pattern where edge-compatible code calls these functions conditionally when not in an edge environment.

[hgmeza]

@tusharpandey13

We are using AWS Amplify for our production applications. Their Nextjs support can be found here: https://docs.aws.amazon.com/amplify/latest/userguide/ssr-amplify-support.html#supported-unsupported-features

It would had been nice that both approaches had been supported on v4 just like v3 is doing, where you can set and authenticate the requests on the middleware, or programmatically use the higher order functions to keep a page or api route authenticated. It's unfortunate that this has been classified as a Feature Request since it was supported before.

In the meantime, you might consider moving non-edge-compatible code outside the Auth0Client construction and implementing a pattern where edge-compatible code calls these functions conditionally when not in an edge environment.

Do you have any guidance on how to achieve this? it sounds that most probably we would need to build a custom authorizer, but i may be wrong.

Adding a configuration option to explicitly opt out of edge compatibility

This would be a nice solve!

Unfortunately this is a big blocker for us for upgrading to Next 15 and most likely we would have to stop using this library and rely on the @auth0/auth0-react client authentication since its not an option to move away from Amplify and change how we secure the route api handlers.

[AurelienGasser]

+1

In v3, we fetch user permissions from the DB, encrypt them, and store them in session.user. This saves us a DB roundtrip on every request because verifying permissions can be done simply by checking the session.user object.

In v4 this is not possible because beforeSessionSaved must be edge compatible (so it cannot fetch information from the DB)

[arpit-jn]

Hi @pcpLiu, this isn't on our immediate roadmap, but we're open to feedback and discussion on specific use cases. We're moving this conversation to GitHub Discussions so everyone can chime in. Feel free to continue the conversation there. We're happy to move it back to Issues if it gains traction or clarity.