Need tenant admin consent for Microsoft Graph API permissions (Chat.ReadWrite, ChatMember.ReadWrite) – stuck in consent loop

The behavior comes from tenant policies: the requested Microsoft Graph delegated permissions require admin approval and user consent is blocked, so Graph Explorer keeps redirecting to the “Need admin approval” page.

To move forward, an administrator must grant consent on your behalf; there is no alternative delegated permission that bypasses this requirement.

1. Why admin consent is required and why you see a loop

• Some delegated Microsoft Graph permissions are admin-restricted. When a non-admin user tries to consent, they see an “unauthorized to consent” / “Need admin approval” experience and must ask an administrator to approve the app for the tenant.
• Tenant admins can also configure consent policies so that any new app or scope requires admin approval, even if the permission is not admin-restricted by default. In that case, users see the same “Need admin approval” message for Graph Explorer or your own app.
• Once an admin grants consent for the tenant, users are no longer prompted unless consent is revoked or new permissions are added.

This matches the behavior described in the Microsoft Graph quick start FAQ: even though the sample (or Graph Explorer) may not request inherently admin-only scopes, tenant policy can still force admin approval.

2. Correct process to request tenant admin consent

Because you are not an admin, the next steps must be done by someone with an appropriate role (Global Administrator, Company Administrator, Cloud/Application Administrator, or similar).

There are two main options.

Option A – Admin grants consent directly in the app (Graph Explorer or your app)

1. Ask a directory admin to sign in to the same app you are using (for example, Graph Explorer or your own registered app).
2. When the consent screen appears, the admin must:
   • Review the requested Microsoft Graph permissions (for example, Chat.ReadWrite, ChatMember.ReadWrite, ChatMessage.Send).
   • Select “Consent on behalf of your organization”.
   • Approve the request.
3. After a successful admin consent, the app receives a response indicating admin_consent=True, and all users in the tenant can use those permissions without further prompts, unless new scopes are added later.

If the admin does not see the consent screen, they can force it by appending &prompt=consent to the sign-in/authorize URL used by the app, as described in the consent troubleshooting guidance.

Option B – Admin uses the tenant-wide admin consent URL

If you have a custom app registration (not Graph Explorer), an admin can grant tenant-wide consent via the admin consent endpoint:

https://login.microsoftonline.com/{organization}/adminconsent?client_id={client-id}

Where:

• {client-id} is your application’s Application (client) ID.
• {organization} is the tenant ID or a verified domain name (or organizations to use the admin’s home tenant).

Process for the admin:

1. Open the constructed URL in a browser while signed in as an admin.
2. Review the list of permissions configured on the app registration (these must already include Chat.ReadWrite, ChatMember.ReadWrite, ChatMessage.Send, etc.).
3. Select Consent on behalf of your organization and approve.
4. On success, the browser is redirected to the configured redirect_uri with admin_consent=True.

If the admin cancels, the response contains an error such as permission_denied.

3. Recommended internal workflow/team to engage

From a product/tenant perspective, the correct internal path is:

1. Identify who manages Microsoft 365 / Entra ID in your organization (often the Microsoft 365 admin, Identity/Entra team, or Security/Compliance team).
2. Provide them with:
   • The name of the app (Graph Explorer or your custom app).
   • The list of required delegated permissions: Chat.ReadWrite, ChatMember.ReadWrite, ChatMessage.Send.
   • A justification for why these permissions are needed (for example, adding external partner sellers to existing Teams chats and sending messages on behalf of the user).
   • If using a custom app, the tenant-wide admin consent URL constructed as above.
3. Ask them either to:
   • Grant tenant-wide admin consent for the app, or
   • Enable and use the admin consent workflow so that your consent request can be routed and approved through their standard process.

If tenant policy is configured to block user consent entirely, this is the only way to unblock testing.

4. Alternatives or reduced-permission testing

Based on the provided documentation, there is no supported way to bypass admin consent when tenant policy requires it. Some points:

• Admins can change consent policies so that users can consent to low-impact permissions themselves, but this is a tenant-wide security decision and must be made by the admin.
• For Graph samples, official guidance when you see the “Need admin approval” message is to either:
  • Work with your administrators to get approval, or
  • Use a personal Microsoft account or a separate test Microsoft 365 tenant where you have admin rights.

For your scenario (Teams chat membership and messaging), the permissions are inherently sensitive, so in a corporate tenant they will almost always require admin consent. A separate test tenant where you are the admin is often the most practical way to experiment freely.

In summary, to unblock testing in your corporate tenant, an Entra/Microsoft 365 admin must grant tenant-wide admin consent for the requested Graph delegated permissions using either the in-app consent screen (with “Consent on behalf of your organization”) or the admin consent endpoint URL.

References:

• Developer’s guide to requesting permissions and consent in Microsoft Identity Platform
• Admin consent on the Microsoft identity platform
• Extend tab app with Microsoft Graph permissions and scopes
• Troubleshoot consent issues in Microsoft Entra ID
• Microsoft Graph quick start FAQ
• Grant tenant-wide admin consent to an application (portal)
• Corporate account apps registration error: AADSTS90094 - Microsoft Q&A