Custom MCP Connector OAuth flow uses prompt=consent blocking non-admin users in enterprise Entra ID tenants

[Armexa-Shane]

MCP server URL or name

https://{dataverseOrgName}.crm.dynamics.com/api/mcp

How are you connecting to this server?

From a custom connector URL I entered manually

Where does the issue occur?

In the authorization screen

When did you last reproduce this?

2026-4-10 - 17:00 MST

Browser and OS

Any browser on Mac or Windows

Describe the issue

Custom MCP connectors in Claude.ai send prompt=consent in the OAuth 2.0 authorize URL on every connection and reconnection attempt. This forces Microsoft Entra ID to display a consent screen to users regardless of whether tenant-wide admin consent has already been granted for the application. In enterprise tenants with restricted user consent policies (which is standard security practice), non-admin users cannot complete the consent screen and receive an "Approval required" or "Need admin approval" error, permanently blocking them from using the connector.

The prompt=consent parameter is included even when the connector is configured with an OAuth Client ID and Client Secret in Advanced settings, meaning the admin has explicitly pre-registered and pre-authorized the application. There is no option in Claude's connector configuration to control or override this behavior.

Error details

Entra ID sign-in error code: 90095

Failure reason: "Admin consent is required for the permissions requested by this application. An admin consent request may be sent to the admin."

OAuth authorize URL generated by Claude includes prompt=consent at the end of every request

Full example URL: https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize?response_type=code&client_id={app-id}&redirect_uri=https://claude.ai/api/mcp/auth_callback&code_challenge=...&code_challenge_method=S256&state=...&scope=openid+profile+offline_access+https://armexa.crm.dynamics.com/api/mcp/mcp.tools&resource=https://{dataverseOrgName}.crm.dynamics.com/api/mcp&prompt=consent

Attempted mitigations that did NOT resolve the issue: granting admin consent via App Registrations, granting admin consent via Enterprise Applications, creating

AllPrincipals OAuth2PermissionGrants via Microsoft Graph PowerShell, classifying all permissions as Low impact, verifying publisher identity, toggling all three user consent policy options

Manually changing prompt=consent to prompt=login in the browser URL immediately resolves the issue and allows non-admin users to authenticate successfully

Expected behavior

Claude should use prompt=login (or omit the prompt parameter entirely) instead of prompt=consent when authenticating to custom connectors that have been configured with an OAuth Client ID and Client Secret in Advanced settings. The use of pre-registered credentials signals that the admin has intentionally set up and authorized the application. Forcing a consent prompt on every connection is unnecessary and incompatible with enterprise Entra ID tenant configurations where user consent is restricted. At minimum, the prompt parameter should be configurable in the connector's Advanced settings so admins can control this behavior.

Additional context

No response

[jhattarki]

I am having the same issue
With tenant policy set to "Do not allow user consent" - even when Admin consent is granted - regular users are prompted for consent (due to "prompt=consent" flag) which they cannot provide due the tenant policy

[GGS-Morrison]

Bumping this for visibility, as I've also encountered this issue. Every time my non-admin users attempt to connect, they are forced to submit a justification.

[localden]

Thank you for taking the time to report this with such thorough diagnostics, especially the detailed list of Entra-side mitigations you tried and the observation that changing prompt=consent to prompt=login in the URL unblocks the flow. That was exactly the signal we needed.

This was fixed in production on April 22, 2026. Claude no longer sends prompt=consent when the authorization endpoint is a Microsoft Entra ID host, so the flow should now complete without triggering the admin-approval gate in restricted-consent tenants. The prompt=consent parameter was originally added to ensure refresh tokens are issued by certain OIDC identity providers, but it was being applied to Entra unnecessarily.

Could you re-test the connection? If it works, you should see the standard Entra sign-in prompt without the "Need admin approval" screen. If you still hit the issue, please retry and share a fresh flow_id from the error URL (?step=start_error&flow_id=ofid_...) so we can trace it.

We're currently triaging open MCP issues, and this one is being closed as resolved. Please reopen or file a new issue with a fresh flow_id if the problem persists after re-testing.