[v4] Allow configuring network requests to auth0 to go through proxy

[nunameya]

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

v3 had an agent property with supplied proxy configuration for the underlying network calls made by the openid and this auth0 sdk client.

v4 doesn't expose this property. Is there an expected workaround?

Describe the ideal solution

agent property is available or a proxy url can be set via a known environment variable which is respected by the auth0 sdk.

Alternatives and current workarounds

No response

Additional context

No response

[nandan-bhat]

Hi @nunameya ,

Thanks for letting us know about this issue.

In v3, the agent property was available because nextjs-auth0 was using openid-client v5.x.x. In v4, we upgraded to openid-client v6.x.x, where the agent / http_options hook was removed as part of the move to a fetch-based API.

I would have suggested using a custom fetch to attach a proxy agent, but I realized that Auth0ClientOptions does not currently expose a fetch option.

As a workaround, you can try overriding globalThis.fetch with a custom implementation that supports a proxy agent before initializing Auth0Client. This is not something I recommend, since it affects all fetch calls, but if it works for your setup, you can try it for now.

I’ll discuss this with the team and get back once I have more clarity.

[nunameya]

Thanks @nandan-bhat

I'm not leaning towards overriding global fetch. I scoured the code and I don't see any other workaround. This will need an update from y'all.

I'd recommend letting us supply proxy agent instead of supplying a custom fetch since it keeps the sdk contract contrainted to what the consumer needs and introduces minimal coupling.

Let me know what the team thinks and if y'all have any ETA.

[nunameya]

@nandan-bhat any updates? We're blocked on upgrading to v4 and blocked on moving to next15.

[nunameya]

@nandan-bhat

I attempted a couple work arounds and ended up empty handed.

1. Monkey patching global fetch: I do not want to go this route since it affects all API calls in our app but regardless I decided to give it a try. I can see that all API calls within my app respect the global proxied dispatcher but none of the auth0 sdk calls do. I attempted the monkey patch and setting up a global proxied dispatcher via undici.

2. Exposing fetch in the sdk options: With an updated forked sdk, I attempted supplying a fetch that has the proxy set to the sdk. However, since auth0 now heavily relies on operating in the middleware layer of next; I'm finding that the fetch used by the sdk is from edge runtime instead of nodejs. Thus, we lose the ability to import any node libs (proxy agent, undici et al) and using them to proxy our calls through the updated fetch. This observation also explained why my first attempt at setting a global dispatcher wasn't working -- auth0 fetch is in a completely different runtime!

Are there any ideas to get around this from the team? We're currently blocked on moving forward with our migration to v4.

[nandan-bhat]

Hi @nunameya ,

Thanks for your patience, and thanks for the detailed updates

This looks related to where the SDK runs. In Next.js, these calls often happen in Edge middleware, where Node-based proxy agents aren’t available. That’s likely why the workarounds you tried didn’t work as expected.

If possible, could you try this with Next.js 16 using proxy.ts ? That runs on the Node runtime and may allow proxying to work for your setup.

Adding proper proxy support in the SDK itself will take time, but we agree it’s a valid request. We’ll follow up once we have a clearer path forward.

[nandan-bhat]

@nunameya

Did you try this on Next.js 16 using proxy.ts ? Did it work ?

[nunameya]

@nandan-bhat No, I haven't been able to try it out yet.

Is there any update on your end?

[nandan-bhat]

@nunameya

Unfortunately, no. As you pointed out earlier, even if we expose a custom fetch option in the SDK, you would still run into the same middleware / edge runtime issue.

I was checking whether Next.js 16 with proxy.ts could help unblock this.

[nunameya]

Ok, thanks @nandan-bhat

I'll try to test it out in the next couple of weeks. If you / team come up with any other way -- please comment back