Azure AD应用注册手动添加权限及许可方式相关技术咨询

Let’s break down your questions clearly to clarify the behavior of Azure AD app permissions:

1. Do permissions added via the UX get written to requiredResourceAccess? #

Absolutely. When you add delegated or application permissions through the Azure Portal UI and save your changes, these permissions are directly stored in the application object (your app registration) under the requiredResourceAccess property. This property acts as your app’s official "permission manifest"—it’s how Azure AD tracks exactly what permissions your application declares it needs to function.

You can confirm this by querying the Microsoft Graph API:

GET https://graph.microsoft.com/v1.0/applications/{your-app-id}

In the response, look for the requiredResourceAccess array, which will list each target resource (like Microsoft Graph) and the specific permission IDs you added.

2. Does clicking "Grant Permissions" sync permissions to the service principal? #

Yes, but there’s a critical distinction to note:

• Saving permissions to the app registration (requiredResourceAccess) only defines what permissions your app needs (it’s like a blueprint).
• Clicking Grant admin consent actually grants those permissions to the service principal—the tenant-specific instance of your app. This is the step that makes permissions active; without it, your app can’t actually use the permissions you’ve added, even if they’re listed in requiredResourceAccess.

Think of the app registration as a global template, and the service principal as the deployed copy of your app in your specific tenant. The consent step applies the template’s permission requirements to the deployed instance.

3. Can user consent achieve the same permission addition as admin consent? #

User consent is possible, but with important limitations:

• It only works for delegated permissions (application permissions can only be granted via admin consent).
• Tenant settings must allow user consent. By default, many tenants restrict user consent to either apps marked as "trusted" by admins, or block it entirely.
• High-risk delegated permissions (e.g., Mail.ReadWrite.All for Microsoft Graph) always require admin consent, regardless of tenant settings.

To enable user consent, an admin can navigate to Azure AD > Enterprise applications > User settings and configure the option "Users can consent to apps accessing company data on their behalf". Even then, users will only be able to consent to low/medium-risk delegated permissions that haven’t been blocked by admin policy.

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