ECONNREFUSED when using createRemoteJWKSet

[xbassols]

When using createRemoteJWKSet this error is being generated:
Error: connect ECONNREFUSED 127.0.0.1:443\n at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1141:16)

I tried with different urls like so:
const AppleJWKS = createRemoteJWKSet(new URL("https://appleid.apple.com/auth/keys"));
or the example one:
const JWKS = createRemoteJWKSet(new URL('https://www.googleapis.com/oauth2/v3/certs'))
with the same error as output.

When debugging the error I noticed that in the fetch.js file the https library is being used and the on('error' listener being triggered.

When changing:
protocols[url.protocol](url, { agent, timeout }, async (response) => {
for
protocols[url.protocol](url.href, async (response) => {
the code proceeds properly.

I don't really get what is causing the error but if I use a URL object in the https module it doesn't work.

Code to reproduce the behaviour:

// formatted code snippet that reproduces the behaviour
const AppleJWKS = createRemoteJWKSet(new URL("https://appleid.apple.com/auth/keys"));
let tokenPayload = await jwtVerify(req.body.token, AppleJWKS, {
  audience: config.APPLE_APP_ID
});

Expected behaviour
It should make the https call properly and parse the JWKS so it can be used for JWT validation.

Environment:

• jose version: 3.5.2

• affected runtime is: Node.js v12.18.2

• [ x] the bug is happening on latest jose too.

• [ x] i have searched the issues tracker on github for similar issues and couldn't find anything related.

[panva]

I am absolutely certain this is the same issue as in panva/node-openid-client#320, this traces back to sindresorhus/got#1515 which traces back to a number of libraries that are possibly in your dependency tree that are monkey patching node's http/https clients. So in summary, not an issue with this library. The way node's API is used is in line with its documentation.

Libraries identified to this so far (note they may be intrinsic dependencies of yours)

• https://github.com/DataDog/dd-trace-js
• https://github.com/mailjet/mailjet-apiv3-nodejs
• https://github.com/TooTallNate/node-agent-base

I will recommend you to remove all other dependencies and keep on adding them one by one until the culprit shows itself. You wouldn't want a library messing with node's stdlib in your stack now, would you?

[panva]

> const jwks = createRemoteJWKSet(new URL('https://appleid.apple.com/auth/keys'));
> jwks({ kid: 'eXaunmL', alg: 'RS256' }).then(console.log)
Promise { <pending> }
> PublicKeyObject { [Symbol(kKeyType)]: 'public' }

works as intended when not affected by the described above issue that's caused by one of your dependencies.

[panva]

Nevertheless, if all it takes to bypass that issue is to pass url.href, i'll push a change.

[xbassols]

Thanks to your input I can confirm it is a dependency problem, in my case:
mailgun-js -> socks-proxy-agent -> agent-base (this last package is who is causing the problem)