CloudAdapter in-turn replies 401 Unauthorized

Question

CloudAdapter in-turn replies 401 Unauthorized

Mali, Priyanka (Ext) 40

Hello,

We are migrating an MS Teams application which is written in Node.js/Express from Azure sdk to microsoft s365 agent.

After migrating index.js file to use the new auth changes mentioned in migration article for azure we are getting 401 Unauthorized error.

Tried all the possible solutions but no luck.
Article - https://dori-uw-1.kuma-moon.com/en-us/microsoft-365/agents-sdk/bf-migration-nodejs?tabs=before
Error - Adapter process failed: Error: Unknown error type: Request failed with status code 401"" at CloudAdapter.runMiddleware (C:\VirtualAssistant\nic-core\node_modules@microsoft\agents-hosting\dist\src\baseAdapter.js:131:27) at process.processTicksAndRejections (c:\VirtualAssistant\lib\internal\process\task_queues.js:95:5) at async CloudAdapter.process (C:\VirtualAssistant\nic-core\node_modules@microsoft\agents-hosting\dist\src\cloudAdapter.js:245:9) at async C:\VirtualAssistant\nic-core\index.js:160:7 {stack: 'Error: Unknown error type: Request failed wit…:\VirtualAssistant\nic-core\index.js:160:7', message: 'Unknown error type: Request failed with status code 401""'}
ENv

MicrosoftAppType="MultiTenant"
clientId="xyz"
clientSecret="xyz"
tenantId="xyz"

Answer accepted by question author

4 additional answers

Your answer

Answer 1

Kudos-Ng 10,625 Microsoft External Staff Moderator

Hi Mali, Priyanka (Ext),

Thank you for posting your question in the Microsoft Q&A forum.

Based on your description and the migration article you’re following, you’ve updated the authentication passed to CloudAdapter as follows:

Bot Framework SDK (before):

const botFrameworkAuthentication = new ConfigurationBotFrameworkAuthentication(process.env);
const adapter = new CloudAdapter(botFrameworkAuthentication);

Microsoft 365 Agents SDK (after):

const authConfig = loadAuthConfigFromEnv();
const adapter = new CloudAdapter(authConfig);

I verified the behavior of loadAuthConfigFromEnv(). This helper does not explicitly carry an “AppType” (multi‑tenant vs single‑tenant) flag; instead, it infers tenancy from the presence of tenantId in your environment variables:

No tenantId present > interpreted as Multi‑tenant.
tenantId present > interpreted as Single‑tenant.

From your environment, it looks like your existing bot is most likely multi‑tenant, but you still have a tenantId configured. That causes loadAuthConfigFromEnv() to build a single‑tenant AuthConfiguration, which the CloudAdapter then uses to acquire wrong access tokens.

Additional note: Microsoft has deprecated new multi‑tenant bot creation after July 31, 2025. Existing multi‑tenant bots continue to function. If your scenario relies on multi‑tenant behavior and you already have a working multi‑tenant bot, removing tenantId in the environment is the appropriate path. If you intend to migrate to single‑tenant, try creating a new Single‑tenant Azure AD (Microsoft Entra) app registration > Update your bot’s configuration to use the new clientId, clientSecret, and tenantId associated with that single‑tenant app. This avoids 401 errors caused by stale or cached registration data and ensures your tokens are issued by the correct authority for single‑tenant operation.

I hope this helps resolve the 401 you’re seeing.

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Nivedipa-MSFT 3,946 Reputation points Microsoft External Staff Moderator

2025-12-02T03:41:38.4766667+00:00

Hi Mali, Priyanka (Ext) - Could you please confirm if the information above was helpful, or do you still need any additional details?
Mali, Priyanka (Ext) 40 Reputation points

2025-12-03T05:21:27.06+00:00

It helped Thankyou for clearing the issue but my app need tenent id and If I want to use new env's key value pair which are documented in microsoft sdk article along with tenant id what would be the available solution.
MicrosoftAppType="MultiTenant"
clientId="xyz"
clientSecret="xyz"
tenantId="xyz"
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-03T07:43:09.2833333+00:00
Hi Mali, Priyanka (Ext),

Thank you for your follow‑up question.

In the Agents SDK, loadAuthConfigFromEnv() determines tenancy based on environment variables:

No tenantId > interpreted as Multi‑tenant (authority resolves to organizations).

tenantId present > interpreted as Single‑tenant (authority resolves to that tenant).

If your application needs a tenant identifier for purposes such as app‑specific routing, home‑tenant Graph calls, or telemetry partitioning, that does not require passing tenantId to the adapter’s authentication loader. You can keep a separate configuration key (for example, HOME_TENANT_ID) for your own logic while omitting tenantId from the auth configuration, so the adapter continues to operate as multi‑tenant.

I hope this helps you decide the best next step for your scenario.
Mali, Priyanka (Ext) 40 Reputation points

2025-12-03T11:07:31.6066667+00:00
Can we keep it as old name MicrosoftAppTenantId? Will it not create a confusion like for datatypes we cannot change their type name from String to something else as Alphabets we cannot change their names.
eg.

string a = "abc";

alpthabets a = "abc"

it will indeed give us error with line 2. Can we change the key value pair for our application ? it wont create a problem like above right tenant id not found or anything else if we rename it to MicrosoftAppTenantId.
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-03T11:30:35.4033333+00:00
Hi Mali, Priyanka (Ext),

Thank you for asking this follow‑up.

As far as I know, environment variables are runtime configuration, not language types. Renaming a key does not cause a compile‑time error like changing string to alphabets in code.

The only impact is whether the SDK loader expects that key. If the loader doesn’t look for MicrosoftAppTenantId, it will simply ignore it — no crash, no error, just no effect on authentication.

Using loadAuthConfigFromEnv()

It only checks for tenantId.

If you rename it to MicrosoftAppTenantId, the loader will not see any tenant ID and will treat the bot as multi‑tenant.

If you want to use this environment variable in other parts of your implementation, you can safely access it with: process.env.MicrosoftAppTenantId

This way, you keep the value for your own logic without affecting the adapter’s authentication behavior.

Hope this clarifies your concern.

Answer 2

The 401 Unauthorized error you are encountering when using the CloudAdapter in your migrated MS Teams application could be due to several reasons related to authentication issues. Here are some steps you can take to troubleshoot this error:

Check App Registration: Ensure that your application is correctly registered in Azure Active Directory. Verify that the clientId, clientSecret, and tenantId are correctly configured in your environment variables.
Service Principal: If your application is a single-tenant Azure Bot Service, make sure that it is linked to a Service Principal in the tenant. You can check this in the Azure Portal under App Registrations. If a Service Principal does not exist, create one.
Token Scope: Ensure that the token you are using has the correct scopes. For Microsoft Teams applications, the required scope should typically include https://api.botframework.com/.default.
Environment Variables: Double-check that the environment variables are being loaded correctly in your application. You can log these variables to ensure they are set as expected.
Authentication Type: Since you are using MultiTenant, ensure that your application is configured to allow multi-tenant access in the Azure Portal. This can be found under the Supported account types section of your app registration.
Error Handling: Implement error handling in your code to capture and log more detailed error messages. This can help identify the root cause of the 401 error.

If you have verified all of the above and are still facing issues, consider reviewing the migration documentation for any additional configuration steps that may have been missed.

References:

Answer 3

Mali, Priyanka (Ext) 40

Hi Thankyou for replying, may I know what is issuers if you can send any guidance link for the same, I have made sure that tenantId is not present in env variables for dev env, i am still getting the issue. Did you get a chance to look into the env file which I attached for my dev env if not I am attaching the file again let me know if there are any env variables which loadAuthConfigFromEnv() does not accepts.

Mali, Priyanka (Ext) 40 Reputation points

2025-12-09T08:01:59.6133333+00:00

I have logged the issuers which I received in local as well as DEV env.

Local

issuers =``(3) ['https://api.botframework.com', 'https://sts.windows.net/undefined/', 'https://login.microsoftonline.com/undefined/v2.0']

0 =``'https://api.botframework.com'

1 =``'https://sts.windows.net/undefined/'

2 =``'https://login.microsoftonline.com/undefined/v2.0'

DEV

issuers: [

'https://api.botframework.com',

'https://sts.windows.net/undefined/',

'https://login.microsoftonline.com/undefined/v2.0'

],
Mali, Priyanka (Ext) 40 Reputation points

2025-12-09T14:02:45.8733333+00:00

Hi, Just following up if you got a chance to review the file and the logs shared for 401 issue in dev
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-09T15:03:41.76+00:00

Hi Mali, Priyanka (Ext),

Thank you for following up, and apologies for the delayed response.

I’ve received your reply along with the environment file and the follow-up details. After reviewing, it seems that the configurations are generally aligned, but the issue still persists. I’ve also done some additional research; unfortunately, I couldn’t find any further insights to resolve this.

In this case, to get more in-depth support and have other configurations in your tenant reviewed, I highly recommend submitting a support ticket through your Azure portal.

Wishing you the best and hope this gets resolved soon.
Mali, Priyanka (Ext) 40 Reputation points

2025-12-10T09:47:34.05+00:00

Hi,Thankyou for responding. One thing I would like to highlight is when I first deploy this changes bot was working fine.
After few other branches deployment I again deployed the same code changes back to dev and then it started giving me 401.
When I deploy back the working release back the bot works but with new build it fails.
I am not from devops background if you can help me understand what can I check that might have affected something in pipeline maybe.
Also other thing to highlight is with new build if I deploy another branch which do not have sdk changes the bot works fine.
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-11T09:36:15.4366667+00:00

Hi Mali, Priyanka (Ext),

Thank you for sharing the additional details.

From the latest context, I understand that initially, when you deployed the changes, everything worked fine. However, after merging with a few other branches and redeploying the same code, the bot started returning a 401 error. Deploying the previous working release resolves the issue, but the new build fails. You also mentioned that deploying another branch without SDK changes works fine.

I’m not from a DevOps background, and providing guidance on checking pipeline configurations falls outside my scope. However, I know a channel where many users with deeper technical or DevOps expertise can provide accurate insights. You might consider posting your issue here: https://github.com/orgs/community/discussions

Additionally, if you found my previous insights regarding the 401 issue helpful, please consider marking my answer as accepted. This helps confirm the information provided and makes it easier for other users facing similar issues to find the information quickly.

Thank you for your engagement and support.
Mali, Priyanka (Ext) 40 Reputation points

2025-12-11T09:39:39.43+00:00

Thankyou for your kind help and answersing all my follow up questions. This issue got resolved we were missing jwt token which is not required while running code in local. I added the extra piece of line server.use(authorizeJWT(authConfig)) and it started working.
Kudos-Ng 10,625 Reputation points Microsoft External Staff Moderator

2025-12-11T09:57:01.3866667+00:00

Hi Mali, Priyanka (Ext),

Thank you so much for your kind response. I truly appreciate it.

I’m really glad I could support you, and I believe the updates and insights you’ve shared will be valuable not only for the community but also for myself to continue improving and learning.

Best regards,

Share via

CloudAdapter in-turn replies 401 Unauthorized

4 additional answers

Your answer