Custom Teams app authentication fails after migrating Azure AD app registration to new tenant

Hi Kudos-Ng,

Thank you for your prompt and thorough questions. I’ve gathered the following details to help diagnose the issue:

1. Error Details

• The “invalid tenant” error appears immediately after initiating sign-in from within Teams (desktop client) when the Teams app opens the Microsoft identity sign-in dialog.
• After I click “Accept” (or similar), it then transitions to “unauthorized” when the token is returned and the app attempts to call the back-end API.
• I captured a screenshot and network trace in Teams DevTools (desktop client → pressing Ctrl+Shift+I → Network tab) showing the token endpoint response status code 400 with error code AADSTS50020: User account from identity provider does not exist in tenant <newTenantId>. …

2. Token Retrieval / Authority Used

• In the network trace I observed that the authority used in the authentication request is:
  https://login.microsoftonline.com/<newTenantId>/oauth2/v2.0/authorize?…
• I confirmed that the <newTenantId> corresponds to the tenant where the app registration now resides.
• I also verified that no requests were being sent to common or organizations endpoints.

3. Teams App Manifest & Authentication Code Changes

• After migration, in the Teams app manifest I updated:
  • "$schema": kept same value
    • "id": updated to the new Azure AD app registration Client (Application) ID in the new tenant
      • "packageName": unchanged
        • "validDomains": added the new registration domain and removed the old one
          • "webApplicationInfo": { "id": "<new-ClientID>", "resource": "<ApplicationIDURI-in-new-tenant>" }
          • • On the back-end side (ASP.NET Core Web API), I updated the AzureAd:TenantId, AzureAd:ClientId, and AzureAd:Instance values in appsettings.json, pointed to the new tenant and new client secret. I also cleaned up cached tokens and restarted the app.

4. App Registration Approach

• We created a completely new app registration in the new tenant, configured it as single-tenant.
• We then updated the Teams app manifest and our code accordingly. The old registration still exists in the previous tenant but is no longer used.
• My understanding is that we do not have guest users from the old tenant using this new registration; all users are native to the new tenant

Additionally:

• I verified that the redirect URI in Azure AD corresponds exactly to what the Teams client is using (including the same scheme and path).
• I ensured that the back-end API is protected by Azure AD (with Require Authenticated Users) and that the “Access tokens” option is enabled for “ID tokens” in the registration’s Authentication blade.
• I noted that the token’s tid claim corresponds to the new tenant ID, but the aud claim appears to reference the old application ID URI (from the previous tenant).

My current suspicious is that despite changing the registration and manifest, there may still be referencesto the old tenant’s application ID URI or issuer, causing the tokens to be rejected by the API or Teams host (hence “unauthorized”).

Sorry if my previouse response is so frustrated, here’s what I mean:

I verified that the redirect URI in Azure AD matches exactly what the Teams client uses (same scheme and path). The back-end API is secured by Azure AD with Require Authenticated Users, and both Access tokens and ID tokens are enabled in the app registration.

The token’s tid claim correctly points to the new tenant, but the aud claim still references the old app ID URI from the previous tenant.

My current assumption is that even after updating the registration and manifest, some cached references possibly in Teams or the manifest package still point to the old tenant’s app ID URI or issuer, causing the token to be rejected and leading to the “unauthorized” error.

Hi Tomlin Izie,

Thank you very much for your feedback.

I have taken note of your information, but I still need some time for further researching in order to be able to give you the most accurate answer. With your consent, I will send you a detailed response by tomorrow. I know that this may cause inconvenience and thank you very much for your patience.

Best regards,

Hi Tomlin Izie,

Apologies for the late response.

I’ve been reviewing the details you shared, especially the point where you noticed that the aud claim still references the old App ID URI from the previous tenant. Based on this, I’ve gathered some insights and would like to request a few additional details to help troubleshoot further.

The reason this matter is that in v1.0 tokens, the aud claim can be either the client ID or the resource URI passed in the request, while in v2.0 tokens it is always the client ID of the API. If your token still shows the old Application ID URI, it may indicate that the request is using the v1.0 endpoint with a resource parameter, or that some configuration still points to the old URI. You can also decode the token and check the ver claim: 1.0 means v1.0 token, 2.0 means v2.0 token. Reference: https://free.blessedness.top/en-us/entra/identity-platform/access-token-claims-reference#payload-claims

To confirm this, could you share the full request URL captured from your network trace (with any sensitive values redacted)? If possible, you can also send these details or your updated manifest via a private message for security. This will help us see whether scope or resource query parameter is being used. In addition, please let us know which authentication library or flow you are using—MSAL, ADAL, or a custom OAuth implementation. If it’s MSAL, include the configuration details such as authority and scopes. If it’s custom, clarify how you are passing scope or resource in the request.

Looking forward to hearing from you!

Hi Kudos

Yes, sure I can give it to you, however, I afraid my full snippet is quite comprehensive cuz it also contain the API bridge method we using for connect multi tenancy.

So can I archive it and send it to you by email ? Or you can reach to me by <PII removed>.com