Azure AD应用manifest中requiredResourceAccess与oauth2Permissions的区别及作用时机

Hey Thomas, great question—let’s break down these two manifest properties clearly, and clarify when oauth2Permissions (like the default user_impersonation) come into play.

1. What is requiredResourceAccess? #

Think of this as your application’s shopping list of permissions it needs from other resources. Here’s the breakdown:

• It’s used when your app acts as a client that wants to access external APIs (like Microsoft Graph, a custom internal API, or a third-party service registered in Azure AD).
• When you add API permissions via the Azure AD portal, those permissions (whether delegated or application-level) get added to this array as permission IDs.
• This property tells Azure AD: "My app needs to access Resource X with Permission Y/Z". After a user or admin grants consent, your app receives tokens that include these granted permissions, allowing it to call the target resource’s API.

2. What is oauth2Permissions? #

This is for when your application acts as a resource API (not a client). It defines the permissions that other client apps can request to access your API. Here’s how it works:

• When you create a custom API app registration, Azure AD automatically adds a default user_impersonation permission here. You can also add custom permissions (like read_invoices, write_customer_data) tailored to your API’s functionality.
• Other client apps will reference these permissions in their own requiredResourceAccess array when they want to call your API. Once consent is granted, those clients can include these permission scopes in their access tokens, and your API can validate these scopes to control access to its endpoints.

Key Differences at a Glance #

When Does user_impersonation (a Common oauth2Permissions Entry) Work? #

The user_impersonation permission is all about allowing client apps to act on behalf of a signed-in user when accessing your API. For example:

• Suppose you built a project management API. A client app (like a mobile app) wants to let users view their own project tasks. The client app will request your API’s user_impersonation permission in its requiredResourceAccess.
• After the user consents, the mobile app gets an access token that includes the user_impersonation scope and the user’s identity. Your API can then use this token to verify that the request is being made on behalf of a valid user, and return only that user’s project data.

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