Graph管理员许可：为何不始终使用/common/adminconsent端点？

Great question! Even though both endpoints trigger similar admin consent experiences (like redirects and permission confirmation prompts), there are practical reasons to use the tenant-specific endpoint (GET https://login.microsoftonline.com/{tenant}/adminconsent) instead of relying solely on /common:

• Eliminate tenant ambiguity
  If your app is built for a specific organization (e.g., an internal enterprise tool), specifying the tenant ID or domain ensures the admin completes consent in the correct tenant context. This is critical if the admin has access to multiple Azure AD tenants—using /common might prompt them to select a tenant, which introduces room for error (like granting permissions to the wrong tenant by accident).

• Streamline service principal creation and follow-up operations
  When you use the tenant-specific endpoint, Azure AD directly creates the app's service principal in that target tenant (if it doesn't already exist). This simplifies subsequent token requests and permission management, as there's no extra step to resolve the tenant first. With /common, the system has to dynamically determine the tenant during the flow, which can add unnecessary redirects or user prompts.

• Enforce compliance and permission boundaries
  For strict compliance scenarios, apps need to be confined to a specific tenant. Using the tenant-specific endpoint ensures consent is only granted within that tenant's boundaries, preventing accidental cross-tenant permission grants that could violate organizational security policies.

• Simplify troubleshooting and logging
  When debugging consent issues, logs from the tenant-specific endpoint clearly tie to a single tenant. With /common, you’d need extra steps to parse which tenant the consent was granted for, making it harder to trace and resolve problems quickly.

内容的提问来源于stack exchange，提问作者Karlheinz Reinhardt