🚨 Microsoft Teams Error: 'resourceRequiresConsent' — Cause, Fix, and Troubleshooting Guide

What this error means

Your Teams tab or personal app uses single sign-on. You call authentication.getAuthToken() from the Teams JavaScript SDK expecting a silent token, and the promise rejects with:

resourceRequiresConsent

This is a consent problem, not a credentials problem. The Teams client asked Azure AD (Microsoft Entra ID) for a token on the user’s behalf, and Entra refused to issue it silently because consent for the requested API permissions has not been recorded. When the SDK exchanges that token for a Graph or downstream-API token via the on-behalf-of flow, you see the server-side twin of this: AADSTS65001 with invalid_grant and a consent_required / interaction_required sub-error. Both mean the same thing — a human still has to consent, or an admin has to pre-authorize the flow.

What users report

• getAuthToken() rejects with resourceRequiresConsent on first use for a user or tenant.
• The on-behalf-of token exchange returns AADSTS65001: The user or administrator has not consented to use the application.
• SSO works for the developer’s own account but fails for other users in the tenant.
• It works in one tenant and fails in another with stricter admin-consent policies.
• Adding a new Graph scope to the app suddenly breaks previously-working SSO.
• The Teams desktop and web clients fail identically, ruling out a single-client quirk.

Tenant and app configuration causes

• No admin consent for the requested scopes. The app requests Graph permissions that require, or are configured to require, tenant-admin consent that has not been granted.
• Teams client IDs not pre-authorized. The Azure AD app’s exposed API (the access_as_user scope) does not list the Teams desktop, web, and mobile client application IDs as pre-authorized apps.
• Scope added after consent. Consent is per-scope; a newly added permission invalidates the silent path until re-consented.
• User-consent disabled by policy. The tenant blocks user consent, so anything short of admin pre-authorization requires interaction.
• Wrong resource/audience in the token request. Requesting a token for a resource the app is not authorized against forces a consent prompt.
• On-behalf-of downstream scope not consented. The initial SSO token is fine, but the downstream Graph scopes in the OBO exchange were never consented.

Confirming tenant configuration

Log the full rejection from getAuthToken — the SDK gives you a reason string you can branch on:

import { authentication } from "@microsoft/teams-js";

try {
  const token = await authentication.getAuthToken();
  console.log("SSO token acquired");
} catch (err) {
  console.error("getAuthToken failed:", err);
  // err is typically the string "resourceRequiresConsent"
}

Decode the token you do get (the SSO id token) to confirm which scopes and audience it carries. Paste the JWT into a decoder, or inspect the aud and scp claims. If scp is missing the Graph scopes you expect, the OBO exchange will fail with AADSTS65001.

On the server side, capture the raw Entra error body from the on-behalf-of call:

{
  "error": "invalid_grant",
  "error_description": "AADSTS65001: The user or administrator has not consented to use the application ...",
  "suberror": "consent_required"
}

The AADSTS65001 code plus consent_required confirms this is the server-side face of resourceRequiresConsent.

Resolution

There are three levers, and production apps usually need all three.

Pre-authorize the Teams client IDs on your app’s exposed API. In the Azure portal under App registrations to Expose an API, add the Teams desktop, web, and mobile client application IDs as authorized client applications for your access_as_user scope. Without this, the Teams client cannot silently obtain a token for your app.

Grant admin consent for the Graph scopes your app requests. Under API permissions, add the delegated permissions, then click Grant admin consent for the tenant. This records tenant-wide consent so users never see a prompt for those scopes.

Fall back to interactive consent when the silent path rejects. Catch resourceRequiresConsent and launch a consent popup with authentication.authenticate(), pointing at a login start page that runs the MSAL consent flow:

import { authentication } from "@microsoft/teams-js";

async function getToken() {
  try {
    return await authentication.getAuthToken();
  } catch (err) {
    if (err === "resourceRequiresConsent") {
      await authentication.authenticate({
        url: `${window.location.origin}/auth-start`,
        width: 600,
        height: 535,
      });
      return await authentication.getAuthToken();
    }
    throw err;
  }
}

The auth-start page performs the interactive consent, and after it completes the follow-up getAuthToken() succeeds silently.

Avoiding tenant drift

• Re-consent after every scope change. Adding a permission silently breaks SSO until admin consent is re-granted; treat scope changes as a consent event.
• Test with a non-admin user. Developers are often tenant admins and never see the consent wall real users hit.
• List all three Teams client IDs. Missing the mobile client ID means SSO works on desktop and web but fails on phones.
• Keep the auth-start domain in validDomains. The interactive fallback popup must load from a domain your manifest allows, or the popup itself fails.
• Do not over-request scopes. Every extra permission is another consent requirement and a bigger admin-consent ask.
• Handle the string, not an object. getAuthToken rejects with the reason string resourceRequiresConsent; compare against the string, not a .code property.

Related tenant errors

• AADSTS65001 Consent Required
• 401 Invalid Authentication Token
• 403 Authorization_RequestDenied