🚨 Microsoft Teams Error Guide: 'AADSTS65001: The user or administrator has not consented' — Grant Admin Consent

Overview

Microsoft Entra ID raises AADSTS65001 when a Teams app, bot, or SSO tab requests a Microsoft Graph permission that has never been consented to by the user or a tenant administrator. The token endpoint refuses to issue an access token until consent exists.

AADSTS65001: The user or administrator has not consented to use the application
with ID '11112222-3333-4444-5555-666677778888' named 'Teams Ops Bot'.
Send an interactive authorization request for this user and resource.

In the on-behalf-of (OBO) flow used by Teams SSO tabs and bots, the same condition surfaces as a invalid_grant with the AADSTS65001 sub-error while exchanging the client-side token for a Graph token.

Symptoms

• SSO in a Teams tab succeeds client-side (getAuthToken returns a token) but the server-side OBO exchange fails with AADSTS65001.
• A bot’s TeamsSSOTokenExchange returns an error and the sign-in card keeps reappearing.
• Graph calls that worked for the app registrant fail for every other user in the tenant.
• The consent prompt never appears because the app requests permissions that require admin consent (e.g. Group.Read.All, Sites.Read.All).
• Works in the developer’s home tenant but fails after the app is installed in a customer tenant.

Common Root Causes

• No admin consent granted — the app requests high-privilege delegated scopes that only a Global Administrator can consent to.
• OBO with un-pre-authorized client — the Teams client app (1fec8e78-bce4-4aaf-ab1b-5451cc387264 for Teams) is not listed as a pre-authorized application on the API’s exposed scope, so the middle-tier token cannot be exchanged silently.
• Scope mismatch — the token was requested with a scope the app registration does not list under API permissions.
• User-assignment required — the enterprise application has “User assignment required” on but the user isn’t assigned.
• Wrong endpoint — authenticating against a specific tenant while the app is registered single-tenant elsewhere, or using /common for a single-tenant app.

Diagnostic Workflow

Decode the failing token request. The scope and client_id in the OBO call must match the app registration:

# OBO exchange that returns AADSTS65001
curl -X POST "https://login.microsoftonline.com/${TENANT_ID}/oauth2/v2.0/token" \
  -d "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
  -d "client_id=${API_APP_ID}" \
  -d "client_secret=${API_SECRET}" \
  -d "assertion=${CLIENT_SIDE_TOKEN}" \
  -d "scope=https://graph.microsoft.com/User.Read https://graph.microsoft.com/Group.Read.All" \
  -d "requested_token_use=on_behalf_of"

Inspect the granted permissions with Graph to confirm what consent actually exists:

# What delegated grants exist for this service principal?
az ad app permission list-grants --id "${API_APP_ID}" -o table

# List the OAuth2 permission grants
curl -H "Authorization: Bearer ${GRAPH_ADMIN_TOKEN}" \
  "https://graph.microsoft.com/v1.0/oauth2PermissionGrants?\$filter=clientId eq '${SP_OBJECT_ID}'"

Confirm Teams is pre-authorized on your exposed API scope in the manifest (preAuthorizedApplications):

"preAuthorizedApplications": [
  { "appId": "1fec8e78-bce4-4aaf-ab1b-5451cc387264",
    "delegatedPermissionIds": ["<your-access_as_user-scope-id>"] },
  { "appId": "5e3ce6c0-2b1f-4285-8d4b-75ee78787346",
    "delegatedPermissionIds": ["<your-access_as_user-scope-id>"] }
]

Example Root Cause Analysis

A team shipped a Teams SSO tab that read the user’s profile and their group memberships. In the developer’s tenant it worked because the developer was a Global Admin and had clicked through the consent dialog once. When a pilot customer installed the app, every user hit AADSTS65001 during the OBO exchange.

Two problems compounded. First, Group.Read.All requires admin consent — regular users could never self-consent, and no admin had granted it in the customer tenant. Second, the API app registration was missing the Teams desktop/web client IDs in preAuthorizedApplications, so even User.Read couldn’t be exchanged silently.

The fix was to (1) have the customer’s Global Admin grant tenant-wide admin consent via the admin consent URL, and (2) add both Teams client app IDs to preAuthorizedApplications on the access_as_user scope. After re-consent, the OBO exchange returned Graph tokens for all users.

Prevention Best Practices

• Request the minimum delegated scopes; avoid admin-consent-only permissions unless truly required.
• Add the Teams web and desktop client app IDs to preAuthorizedApplications so SSO tabs can exchange tokens silently.
• Ship an admin consent URL with your app for tenant admins: https://login.microsoftonline.com/{tenant}/adminconsent?client_id={appId}.
• Grant admin consent as part of deployment (az ad app permission admin-consent) rather than relying on per-user prompts.
• Handle AADSTS65001 in the bot/tab by returning a consent/sign-in card that triggers the interactive adminconsent flow.
• Keep the app single- vs multi-tenant setting consistent with the authority endpoint you call.

Quick Command Reference

# Grant admin consent for the app (requires admin)
az ad app permission admin-consent --id "${API_APP_ID}"

# Admin consent URL to hand to a tenant admin
echo "https://login.microsoftonline.com/${TENANT_ID}/adminconsent?client_id=${API_APP_ID}"

# List current API permissions on the app
az ad app permission list --id "${API_APP_ID}" -o table

# Show the enterprise app's assignment requirement
az ad sp show --id "${API_APP_ID}" --query "appRoleAssignmentRequired"

Conclusion

AADSTS65001 is a consent problem, not a code bug: the token endpoint has no record that anyone approved the scopes your Teams app is asking for. Confirm which scopes need admin consent, pre-authorize the Teams client apps on your exposed API scope, and grant tenant-wide admin consent at deployment time. Once consent exists and the OBO client is pre-authorized, SSO tabs and bots exchange Graph tokens silently for every user in the tenant.