Getting ClientAuthError: endpoints_resolution_error: Error: could not resolve endpoints with @azure/msal-node 1.9.1 #4879
Comments
awanlin
added
bug-unconfirmed
|
@Robbie-Microsoft I noticed you worked on #4744, do you have any idea why I would be running into this error? |
|
@awanlin Thanks for the information. Are you using a network proxy? |
ghost
added
answered
jasonnutter
added
the
bug
ghost
removed
bug-unconfirmed
|
@jasonnutter I saw an ongoing issue which states the setup isn't working on network proxy but I am not using any proxies right now and it stopped working on my servers recently with the same error as mentioned above. My implementation is almost similar to what it is stated here. But version is 1.8.0 which I had to re install for some other reasons. |
|
@jasonnutter no, I'm not using a network proxy, our setup is very simple |
|
cc @EmLauber |
|
same issue here any news? @jasonnutter ? |
|
I'm trying to reproduce the issue so I can figure out what's wrong. I'll update this issue once I have more information. |
|
@awanlin can you reproduce this issue locally in development? Or does in only happen in production? |
|
@hectormmg, I ran into this error both on my local environment and once deployed to our development environment, it did not go to staging or production once I noticed the errors I cancelled the deployment. This code is in a plugin that is part of our Backstage developer portal which runs in a Docker container and deployed to AWS. I'd be willing to share the entire code with you in some secure fashion if that helps you? |
|
@hectormmg, any updates on this? Thanks in advance! |
|
@awanlin apologies for the delay, we have been investigating a possibly related issue with msal-node's network module that may be affecting the way network and HTTP errors are reported. Will update this issue when we have more information. |
|
Just wanted to check in to see if there was any update on this? We have tried using version |
|
As @awanlin mentioned, this is not working for us too. We have a very simple environment and this is the error we are receiving. Any updates? |
|
Error is still there on 1.12.1 |
|
@jsbinette, @bgavrilMS sent me the files from your app that you sent him, so I've taken a look at your app. Based on what I saw, the only thing I can see different is that you're running your confidential client methods (acquireTokenByClientCredential) in express routes. I wrote my own express app and was unable to reproduce your issue. So I've done the following: I've updated the custom-INetworkModule-and-network-tracing sample so that it now supports an express server and running confidential client requests via express routes. Additionally, I added a custom axios http client that can be used instead of the existing http client - we used to use axios before I updated the http client to move away from axios because it didn't function that well when run behind a proxy. My ask to you, if you have time and are willing: play with this updated sample - copy a skeleton of your express app into this sample and run it (once with the existing http client and once with the axios http client), and see if you are still experiencing the same error. If you receive the same error with the axios http client, I suspect there is a problem in your configuration. |
|
I'm facing similar issue with v1.15.0.. tried everything from comments above, but nothing seems to work. I also incorporated the custom Unclear why authority URL is not being respected even though it's received by |
|
It seems to get fixed by updating the below dependencies: Before (fails): After (works): Thanks @bgavrilMS and @Robbie-Microsoft for the hint :) |
|
@cheenamalhotra thanks so much for our debugging session today! I believe I've identified the root cause of the issue and have linked the PR with a fix. |
|
My node backend suddently stopped working today (1/3/2023) and showed the error mentioned here. Any workaround for now? also any schedule for the update release? Thank you |
|
@chanphillip The linked PR should be in next Monday's (March 6, 2023) build. |
We had to push back yesterday's (March 6, 2023) monthly release to today (March 7, 2023), there was an issue with a PR that had to go out. |
|
@Robbie-Microsoft works! with 1.16.0. THANK YOU! |
|
Big thanks to @cheenamalhotra for finding a consistent repro for this and to @Robbie-Microsoft for figuring out a fix. |
|
Hello, I still have this issue. In my package.json My config const azureAdConfig = { My server log: [Thu, 06 Jul 2023 11:13:49 GMT] : @azure/[email protected] : Info - getAuthCodeUrl called And IN my proxy, it's look like microsoftonline close the connection with a 302 URL: http://login.microsoftonline.com/$mytenantId/v2.0/.well-known/openid-configuration Content-Length: 0 If I curl same the URL with my proxy, I receive a 200 with the correct payload. Thank you for your help |
|
I am facing this issue with a network proxy, and can't seem to get past it in any way at all. It works fine in development but fails when pushed to production. |
|
I am getting the same issue with v1.18.2. Any idea what could be the problem? |
|
@thetminko Please upgrade your msal-node version from 1.18.2 to 2.1.0. If your issue still persists, then please create a new issue. |
|
I am getting the same 500 error when trying to call an Azure Function in local development environment from Postman: endpoints_resolution_error: Endpoints cannot be resolved. Calling the live function endpoint works fine. package.json: {
"name": "",
"version": "1.0.0",
"description": "",
"main": "src/functions/*.js",
"scripts": {
"start": "func start",
"test": "echo \"No tests yet...\""
},
"dependencies": {
"@azure/functions": "^4.0.0-alpha.1",
"@azure/msal-node": "^2.5.1",
"axios": "^1.6.0"
},
"devDependencies": {
"azure-functions-core-tools": "^4.x"
}
}Node.js, using v4 programming model in Azure Functions. Relevant function code: const msal = require('@azure/msal-node');
const axios = require('axios');
const msal_config = {
auth: {
clientId: process.env["azure_ad_app_registration_client_id"],
authority: `https://login.microsoftonline.com/${process.env["azure_ad_app_registration_tenant_id"]}`,
clientSecret: process.env["azure_ad_app_registration_client_secret"],
}
};
const cca = new msal.ConfidentialClientApplication(msal_config);
const clientCredentialRequest = {
scopes: ["https://graph.microsoft.com/.default"],
};
const response = await cca.acquireTokenByClientCredential(clientCredentialRequest);
const token = response.accessToken;
// context.log is broken in Azure Functions, it's not synchronous, apparently this has been a known issue for a long time
// https://github.com/Azure/azure-functions-host/issues/9238
// apparently this is a fix available in this pull request:
// https://github.com/Azure/azure-functions-host/pull/9657
context.log('token'):
context.log(token):
return { jsonBody: {"some_key": "some value"} } |
|
In case it helps anyone, an update to my last message... I had been troubleshooting this for two days. I stripped down all my function code, and the only thing that was causing the error was getting the token. So I asked myself: 'Why can't i get a token from my local computer'? I created a GET request in Postman to get a token with the details below, and the token came back immediately. So there were no invisible reasons (network/security etc) for not being able to get a token from my computer. The settings for the request were: After that, I started up the local function again with I then made a call to the local function endpoint and got a response almost immediately. So, something in the process of getting a token (outside of the function context) 'freed up' the code in the function to work correctly and to be able to retrieve and use a token. EDIT 01: 24 hours later, without changing any code, tried calling the local function endpoint again and I get the same 500 error as before: "endpoints_resolution_error: Endpoints cannot be resolved" This time, trying to get a token in Postman just to 'make it work' isn't working like it did yesterday. EDIT 02: I use Starlink, I swtiched to using a VPN and the error went away and I have no idea why using Starlink would prevent msal-node from being able to get a token to use with Microsoft Graph. |
|
I had this problem and couldn't figure out the cause until I tried upgrading node.js from v14 to v16+. After doing more testing with node v18 it seems to be working fine. Although I didn't see it documented in the javascript sdk documentation, So another potential fix: upgrade node.js. |
and others
Core Library
MSAL Node (@azure/msal-node)
Core Library Version
1.9.1
Wrapper Library
Not Applicable
Wrapper Library Version
None
Description
Since upgrading from 1.9.0 to 1.9.1 we are running into the error listed in this issue below. We have a node application that runs on an interval to update profile pictures in Backstage a Developer Portal we are using. It's very simple.
Rolling back to 1.9.0 the error goes away. I'm not sure what specifically is causing this issue but I feel like it is something in PR #4744. That being said there might be simply something that we need to include to resolve this like some additional configuration.
Any help with this would be greatly appreciated!
Error Message
ClientAuthError: endpoints_resolution_error: Error: could not resolve endpoints. Please check network and try again. Detail: ClientAuthError: openid_config_error: Could not retrieve endpoints. Check your authority and verify the .well-known/openid-configuration endpoint returns the required endpoints. Attempted to retrieve endpoints from: https://login.microsoftonline.com/{tenantId}/v2.0/.well-known/openid-configuration
Note that
{tenantId}in the URL above is our actual tenantId, just removed for security reasons.Msal Logs
No response
MSAL Configuration
Relevant Code Snippets
Reproduction Steps
I'm not totally sure how to describe this:
Notice in the logs the error listed in this issue occurs
Expected Behavior
There should be no error and the process should continue to work as it did with version 1.9.0
Identity Provider
Azure AD / MSA
Browsers Affected (Select all that apply)
None (Server)
Regression
@azure/msal-node 1.9.0
Source
External (Customer)
The text was updated successfully, but these errors were encountered: