Authorization code flow results in "connect ECONNREFUSED 127.0.0.1:443"

[halestock]

Description

Hello, I am currently in the process of testing the upgrade path to 2.0.0 of this library using Auth0 as my oauth provider. After logging in to Auth0, the callback endpoint fails with the following error: BadRequestError: connect ECONNREFUSED 127.0.0.1:443 at /Users/hsostock/code/connect-web/node_modules/express-openid-connect/middleware/auth.js:105:31 at processTicksAndRejections (internal/process/task_queues.js:97:5)

Note: After doing some debugging, it appears that this is the result of an internal call to https://{auth0-domain}/.well-known/oauth-authorization-server returning a 404 Not Found error (which, for some reason, is surfaced as the above connection refused error).

Reproduction

I am using the following configuration in my express app:

const app = express();
app.use(oidc.auth({
  secret: "secret value",
  routes: {
    login: '/auth/login',
    logout: '/auth/logout',
    postLogoutRedirect: '/',
    callback: '/auth/callback',
  },
  session: {
    rolling: false,
    absoluteDuration: 60, // 60 seconds
  },
  authRequired: true,
  auth0Logout: true,
  clientID: "secret value",
  clientSecret: "secret value",
  baseURL: config.webUrl,
  issuerBaseURL: config.auth.issuerBaseURL,

  authorizationParams: {
    scope: 'openid profile email offline_access',
    response_type: 'code',
  },
}));

And occurs consistently (as mentioned) when validating the authorization code returned from Auth0.

Environment

• Version of this library used: 2.0.0
• Version of the platform or framework used, if applicable: Express 4.17.1
• Other relevant versions (language, server software, OS, browser): Node.js 12.13.1 / Typescript / Chrome

[adamjmcgrath]

Hi @halestock

connect ECONNREFUSED 127.0.0.1:443

This error suggests that something is trying to connect to https://localhost, but nothing is running on https://localhost

at .../express-openid-connect/middleware/auth.js:105:31

This suggests that it's being caught by https://github.com/auth0/express-openid-connect/blob/master/middleware/auth.js#L105 which would suggest that the error is being thrown from client.callback as this is the only place that will try and connect to another server (here where attempts to do the code exchange https://github.com/panva/node-openid-client/blob/67b6b7e7953948d157d1c21446ecf8c327bcbe30/lib/client.js#L460)

So if I had to guess I would say that config.auth.issuerBaseURL is pointing at https://localhost or the client is expecting some proxy to be at https://localhost (perhaps you have some http_proxy or https_proxy environmental variables set?)

[halestock]

This error suggests that something is trying to connect to https://localhost, but nothing is running on https://localhost

That's correct. We actually use a custom localhost domain - and it's run on http, not https (though it's just an alias for localhost, which is still accessible).

This suggests that it's being caught by https://github.com/auth0/express-openid-connect/blob/master/middleware/auth.js#L105 which would suggest that the error is being thrown from client.callback as this is the only place that will try and connect to another server (here where attempts to do the code exchange https://github.com/panva/node-openid-client/blob/67b6b7e7953948d157d1c21446ecf8c327bcbe30/lib/client.js#L460)

Correct, that's exactly the call that ultimately throws (and auth.js#L105 is where it's caught).

So if I had to guess I would say that config.auth.issuerBaseURL is pointing at https://localhost or the client is expecting some proxy to be at https://localhost (perhaps you have some http_proxy or https_proxy environmental variables set?)

issuerBaseURL is currently set to https://{domain}.us.auth0.com, not localhost (and is unchanged from when I was using the 1.x branch), and there are no env vars for http(s)_proxy. The only reference to anything locally is baseURL (which, as mentioned above, does not point to localhost but to our localhost alias domain.

[halestock]

So, assuming the failure when calling https://{auth0-domain}/.well-known/oauth-authorization-server is just a red herring, it seems like the issue here might be that it's ignoring the configured value for baseUrl, since it should be hitting the domain:port configured instead of just going to https://localhost.

[adamjmcgrath]

I was more thinking along the lines of issuerBaseURL somehow resolving to 127.0.0.1, if you don't have a proxy configured, somehow could you have a hosts file configured like this? Or have issuerBaseURL mixed up with baseURL somehow?

[halestock]

Gotcha. So, I don't think it's a misconfiguration issue, because on fresh start (with no cookies) of the web server, I'm redirected to auth0 for login successfully (and actually, on that first login, i'm redirected back and everything works fine). It's on subsequent auth flows that I start seeing this issue:

1. I open a new private chrome tab and navigate to my web server, and get redirected to the auth0 login page (as expected)
2. After entering credentials, I'm redirected back to my web server and the authorization code flow completes successfully.
3. I then open up a new private chrome tab, which redirects me to the auth0 login page (as expected)
4. After entering credentials, I'm redirected back to my web server (to the auth callback URL), and receive the ECONNREFUSED 127.0.0.1:443 error.

If (without restarting the server) I try logging in as a different user on a new private chrome tab, I again get the same error.

If I restart the web server, it will start working again for that initial auth flow (both with a new private chrome tab as well as a tab that still has the existing session cookies.)

[adamjmcgrath]

Hi @halestock - thanks for sharing that.

I'm not able to reproduce the issue following your steps on an app with the configuration you've described.

If you can provide an example app where I can reproduce the issue I might be able to help you debug it.

Alternatively, you could try putting a breakpoint around here https://github.com/panva/node-openid-client/blob/master/lib/helpers/client.js#L148 and seeing what code exchange request is being made and if it's successful.

absoluteDuration: 60, // 60 seconds

The only other thing that stands out is the short absolute duration of your session - you could also try reproducing the issue with a larger number (like 1 hr)

[halestock]

Sure, I'll try that and let you know. I'll also bump up the session length to rule that out (was only setting it that short for some unrelated session handling code).

[adamjmcgrath]

3. I then open up a new private chrome tab, which redirects me to the auth0 login page (as expected)

Also, I would expect you to be already logged in - since cookies are shared across private tabs in Chrome

[halestock]

Also, I would expect you to be already logged in - since cookies are shared across private tabs in Chrome

Ah, sorry, I should have been more clear. In that context I meant that I was clearing session/cookies (by closing the existing private windows) and starting from a clean slate. If I do open a new tab while one is open (which shares the existing session/cookies) after a successful login, it continues to work since it does not go through the auth flow again.

[halestock]

Alright, I think I'm getting somewhere. If I wrap https://github.com/panva/node-openid-client/blob/master/lib/helpers/client.js#L148 in a try/catch with await, I get the ECONNREFUSED error as above. If I go down a layer, the http call is made at https://github.com/panva/node-openid-client/blob/master/lib/helpers/request.js#L53. If I wrap that call in a try/catch, I still get ECONNREFUSED, which to me means it's likely coming from the got library.

This is the (sanitized) request options to got from a failing call:

{
  "form": {
    "grant_type": "authorization_code",
    "code": "{code}",
    "redirect_uri": "http://{localdomain}:14251/auth/callback",
    "code_verifier": "{code}"
  },
  "responseType": "json",
  "headers": {
    "Authorization": "Basic {token}",
    "User-Agent": "express-openid-connect/2.0.0",
    "Auth0-Client": "{id}"
  },
  "method": "POST",
  "url": "https://{domain}.us.auth0.com/oauth/token",
  "followRedirect": false,
  "retry": 0,
  "timeout": 5000,
  "throwHttpErrors": false
}

And this is the request options from a successful call:

{
  "form": {
    "grant_type": "authorization_code",
    "code": "{code}",
    "redirect_uri": "http://{localdomain}:14251/auth/callback",
    "code_verifier": "{code}"
  },
  "responseType": "json",
  "headers": {
    "Authorization": "Basic {token}",
    "User-Agent": "express-openid-connect/2.0.0",
    "Auth0-Client": "{id}"
  },
  "method": "POST",
  "url": "https://{domain}.us.auth0.com/oauth/token",
  "followRedirect": false,
  "retry": 0,
  "timeout": 5000,
  "throwHttpErrors": false
}

Which matches the failing call exactly (except for the codes/tokens/etc).

Is it possible this is at play here?

[adamjmcgrath]

Is it possible this is at play here?

Yes, that looks like a likely candidate. Do you have a dependency on node-agent-base? (check npm list node-agent-base)

[halestock]

No, no dependencies on node-agent-base.

[halestock]

Aha! It looks like I'm running a number of different versions of https-proxy-agent locally (all transitive) - and if I force them all to the latest version, it works again. So, looks like it's actually on my side of things.

[adamjmcgrath]

Well spotted, glad you got it sorted @halestock

[halestock]

Yep, thanks much for the assistance!

[jquense]

Heads up if anyone else runs into this, its npm list agent-base, not node-agent-base which the repo name not the package name. tripped me up for a while.

[andyndang]

Not sure why this is closed, but we fixed this with:

  "resolutions": {
    "agent-base": "^6.0.1"
  },

[derman10]

Not sure why this is closed, but we fixed this with:

  "resolutions": {
    "agent-base": "^6.0.1"
  },

where need to put this??

[perci-artur]

Not sure why this is closed, but we fixed this with:

  "resolutions": {
    "agent-base": "^6.0.1"
  },

where need to put this??

1. Run npm list agent-base to find the used versions. For me the latest one is 6.0.2.

2. Install that version with npm i agent-base@6.0.2.

3. Add overrides section to the package.json file; overrides is NPM equivalent for yarn resolutions:

  "overrides": {
    "agent-base": "^6.0.2"
  }