A cloud-based identity and access management service for securing user authentication and resource access
Single app registration as both OAuth client and protected API/resource — admin consent from a second tenant fails with AADSTS90009 or AADSTS650052 depending on scope format
I have one multitenant App Registration that serves two roles:
- It's the protected API/resource — my backend MCP server.
- It's also the OAuth client — the same registration is what an external MCP client uses.
The app is not published.
Sign in works fine for users inside my own tenant.
The problem is entirely about onboarding a second tenant: I want an admin in that other tenant to grant one tenant-wide consent so their users can use the app, and I can't get that consent to succeed no matter which admin-consent URL format I try.
Attempt 1 — v2 admin consent endpoint, scope as the App ID URI:
https://login.microsoftonline.com/<target-tenant-id>/v2.0/adminconsent
?client_id=<my-app-client-id>
&scope=api://<my-app-client-id>/.default
&redirect_uri=...
Result:
AADSTS90009: Application '<my-app-client-id>'(api://<my-app-client-id>) is requesting a token for itself. This scenario is supported only if resource is specified using the GUID based App Identifier.
Attempt 2 — same endpoint, scope as the bare GUID instead (as the error above instructed):
https://login.microsoftonline.com/<target-tenant-id>/v2.0/adminconsent
?client_id=<my-app-client-id>
&scope=<my-app-client-id>/.default
&redirect_uri=...
Result:
AADSTS650052: The app is trying to access a service '<my-app-client-id>'(<my-app-display-name>) that your organization '<target-tenant-id>' lacks a service principal for.
My understanding is that the admin consent flow should create the Enterprise Application (service principal) in the target tenant. Instead, it fails because the service principal doesn't exist.
Attempt 3 — v1 admin consent endpoint:
https://login.microsoftonline.com/common/adminconsent
?client_id=<my-app-client-id>
Result: the admin gets redirected to a "Need admin approval" page instead of a consent/accept screen.
**
Question:** Is using a single multitenant App Registration as both the OAuth client and the protected API officially supported for cross-tenant delegated consent? If so, what configuration am I missing? If not, is using two App Registrations (one for the OAuth client and one for the protected resource/API) the only supported approach?