Teams bot app SSO signin failure with a resource match failed

Tharushi De Silva 75 Reputation points
2026-04-21T14:46:00.06+00:00

Hi,

I am implementing SSO flow for a bot app built using Teams SDK and I keep getting a 200 response with a sign in failure .

I have checked the application ID URI, token exchange URL (in bot resource) and the manifest webApplicationInfo which matches the api://{azuread-client-id} going through the troubleshooting tips.

I have the azure bot resource registered as a single tenant and the entra app registered to support multiple entra id tenants. I do get a response from the web chat (because it would use standard OAuth flow and does not rely on SSO token exchange as I got to know) but from teams client it gives this signin error with the following payload.

I have also tried out setting the Azure AD app to single tenant and testing the bot app inside the same teams tenant that was used for the azure resource registration. Still the same sign in failure happens. Which means it cannot be a cross tenant issue. I am currently following this github discussion as well, and that has the details needed for troubleshooting.

https://github.com/orgs/community/discussions/193132

I have also raised this in https://github.com/microsoft/teams-sdk/issues/2183.

I have been following the official documentation on teams sdk sso setup https://learn.microsoft.com/en-us/microsoftteams/platform/teams-sdk/teams/user-authentication/sso-setup.

Great to know if there could be anything that's missing. TIA

{
    "name": "signin/failure",
    "type": "invoke",
    "value": {
        "code": "resourcematchfailed",
        "message": "Resource match failed"
    }
}
Microsoft Teams | Development
Microsoft Teams | Development

Building, integrating, or customizing apps and workflows within Microsoft Teams using developer tools and APIs

0 comments
Answer recommended by moderator
Tharushi De Silva 75 Reputation points
2026-07-08T21:17:27.74+00:00

Hi,

I was able to fix the issue and couldn't update here.

Root cause was an App Registration conflict in the Developer Portal

Sharing the fix in case it helps others who hit the same "resource match failure":

The issue was caused by an inconsistency in the app registration on the Developer Portal.. the Teams client wasn't correctly matching the registered app to its manifest.

This tends to happen when the registration is done manually rather than through the M365 Agents Toolkit, which normally handles registering the app and its entities for you. The SSO sample guides don't mention this out explicitly, so if you're setting things up manually, double-check that your app registration and manifest are fully aligned.

Closing this out as resolved. Thanks all for the discussion!

Was this answer helpful?

1 person found this answer helpful.

3 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Sayali-MSFT 6,476 Reputation points Microsoft External Staff Moderator
    2026-04-23T09:19:38.8666667+00:00

    Hello Tharushi De Silva,
    The resourcematchfailed sign-in error in Teams SSO indicates that the resource (Application ID URI) used during token exchange does not exactly match across the Azure AD app registration, Teams app manifest, and bot configuration. Even minor mismatches—such as using different app IDs, incorrect URI formats, or trailing slashes—cause Teams to reject the token exchange, even if OAuth works in Web Chat. This issue is typically not related to tenant configuration (single vs multi-tenant), but rather to strict audience validation in Teams SSO.
    Fixing it requires ensuring the same Azure AD app is used everywhere, the webApplicationInfo.resource matches the exact Application ID URI (api://<client-id>), and that the access_as_user scope and OAuth connection are correctly configured and aligned.

    Was this answer helpful?

    0 comments
  2. Hin-V 16,830 Reputation points Microsoft External Staff Moderator
    2026-04-21T16:39:51.4266667+00:00

    Hi @Tharushi De Silva

    Good day, and thank you for providing the detailed information. 

    First, I’d like to clarify that this is a user‑to‑user support forum. Moderators participating here do not have access to backend systems, nor can we directly intervene in Microsoft product functionality. Our role is limited to providing technical guidance and sharing best‑practice recommendations based on reported issues, requests, and scenarios. 

    You could refer to the AI response first. As far as I understand, the resourcematchfailed issue indicates that the audience (aud) claim in the token returned by Entra ID does not exactly match (character‑by‑character) the resource value expected by the Teams client. 

    In the Teams SSO flow: 

    The Teams client silently requests an access token from Entra ID on behalf of the logged-in user. 

    It then passes this token to the bot through the token exchange mechanism. 

    If the aud in the token does not perfectly match the webApplicationInfo.resource defined in your Teams app manifest (and the Application ID URI in the Entra app), Teams will reject it with “Resource match failed”. 

    This is why web chat usually works (they use standard OAuth flow), while the real Teams client fails. 

    To resolve this, I would recommend verifying that the Application ID URI is identical across the Entra app, the Teams manifest (webApplicationInfo.resource), and the Azure Bot OAuth connection Token Exchange URL. In addition, please confirm that the OAuth connection is linked to the correct Entra application and that the connection name used in the bot code exactly matches the one configured in Azure. 

    If everything appears correct, you could consider recreating the OAuth connection, as stale or inconsistent configuration can cause Teams to request a token for the wrong resource. Also, capturing and decoding the token issued by Teams can help confirm whether the audience claim matches the expected Application ID URI. Once the audience is aligned, the SSO flow should complete successfully. 

    If you have any additional concerns, feel free to comment below. I would be more than happy to assist. 

    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.

    Was this answer helpful?

  3. AI answer

    2026-04-21T14:46:40.98+00:00

    The signin/failure with code: "resourcematchfailed" indicates that the token Teams is trying to exchange does not match the resource (Application ID URI) that the bot expects for SSO. Web Chat works because it falls back to the normal OAuth card flow, while Teams is attempting the SSO token exchange path and failing the resource match.

    To resolve this, verify all of the following are aligned for the SSO token exchange scenario:

    1. Application ID URI and audience
      • Ensure the Application ID URI configured in Microsoft Entra ID exactly matches what the Teams client is using as the audience for the token exchange.
      • In SSO scenarios, the audience must match the TokenExchangeResource.Uri and the Application ID URI exposed in Entra ID.
      • If the audience in the token does not match the Application ID URI, Teams cannot match the resource and the exchange fails.
      • Inspect the access token using a tool such as JWT and confirm:
        • aud (Audience) equals the Application ID URI configured in Entra ID.
        • tid (Tenant ID) is the expected tenant.
        • scp (Scopes) are as defined in the Entra app.
    2. Consistency between Entra ID, code, and Teams app manifest
      • A generic SSO/sign-in failure often occurs when one or more Entra ID configurations do not match what is in the code and manifest. Confirm that the following values are identical across:
        • Microsoft Entra ID app registration
        • Bot/tab code configuration
        • Teams app manifest (webApplicationInfo and any SSO-related settings)
      • Specifically verify:
        1. App ID: The Entra Application (client) ID is the same in:
          • Teams app manifest
          • Bot code configuration
        2. App secret: The client secret used by the bot backend matches the Entra Client credentials and is not expired.
        3. Application ID URI: The Application ID URI in code and manifest matches the Application ID URI in Entra ID.
        4. Permissions and consent: The scopes defined in Entra ID are correct for the app and have been granted (including admin consent if required).
    3. Token exchange flow behavior
      • In Teams, the SSO flow is:
        1. Bot sends an OAuth card.
        2. Teams intercepts the OAuth card and, if TokenExchangeResource is present, sends a signin/tokenExchange invoke with an exchangeable token whose audience must match TokenExchangeResource.Uri.
        3. Bot returns a TokenExchangeInvokeResponse with a status code.
      • If the TokenExchangeInvokeResponse.status is 200, Teams does not show the OAuth card and SSO succeeds.
      • For any other status, or if the response is not received, Teams falls back to the OAuth card flow.
      • A resource mismatch at this stage leads to the resourcematchfailed failure and the signin/failure invoke.
    4. Teams SSO configuration for the remote service
      • For a Teams SSO-enabled bot/tab using TeamsFx or similar patterns, confirm the remote service configuration matches the Entra app:
        • M365_CLIENT_ID = Entra app client ID
        • M365_CLIENT_SECRET = Entra app client secret
        • M365_TENANT_ID = Entra tenant ID
        • M365_AUTHORITY_HOST = Entra OAuth authority host
        • M365_APPLICATION_ID_URI = Identifier URI for the Entra app (must match Application ID URI and token audience)
      • In infrastructure templates (for example, azure.bicep), ensure m365ApplicationIdUri is set consistently (for example, api://botid-${botAadAppClientId} if that is the chosen pattern) and that this value is used everywhere.
    5. Tenant and consent considerations
      • If the Entra app is in the same tenant as Teams, users are typically granted an access token without a consent prompt; if the app is in a different tenant, consent is required.
      • If permissions or scopes were changed, users might need to consent again.
      • If consent fails or required permissions are missing, the bot falls back to a sign-in card.
    6. Error classification and generic failures
      • A generic sign-in error can also appear if any Entra configuration is incorrect. In that case, re-check:
        • App ID
        • App secret
        • Application ID URI
        • Scopes and admin consent
        • Token claims (aud, tid, preferred_username, scp, ver) against the expected values.

    In summary, the resourcematchfailed failure is almost always due to a mismatch between the token audience and the Application ID URI/TokenExchangeResource.Uri. Aligning the Application ID URI in Entra ID, Teams manifest (webApplicationInfo), bot code, and remote service configuration, then validating the token’s aud claim, resolves this class of SSO sign-in failures.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.