API Permissions and App Roles in Microsoft Entra ID (SC-300)
Why Are API Permissions and App Roles Important?
In modern cloud environments, applications frequently need to access resources and APIs on behalf of users or as standalone services. Without a robust permissions model, applications could gain excessive access to sensitive data, violating the principle of least privilege. API permissions and app roles in Microsoft Entra ID (formerly Azure AD) provide a structured, secure, and auditable way to control what an application can do and what data it can access. For the SC-300 exam, understanding these concepts is critical because they are foundational to implementing and managing workload identities securely.
What Are API Permissions?
API permissions define the level of access that an application requests to a specific API (such as Microsoft Graph, Azure Key Vault, or a custom API). There are two main types of API permissions in Microsoft Entra ID:
1. Delegated Permissions
These permissions are used when an application acts on behalf of a signed-in user. The effective permissions are the intersection of the permissions granted to the app and the permissions the signed-in user already has. For example, if an app has the delegated permission User.Read.All but the signed-in user is not an admin, the app cannot read all users' profiles — it can only read what the user themselves can access.
2. Application Permissions
These permissions are used when an application runs without a signed-in user (e.g., background services, daemons, or automated pipelines). Application permissions grant the app direct access to the resource, and the effective permissions are exactly what is granted. These are more powerful and typically require admin consent.
What Are App Roles?
App roles are custom roles defined within an application's registration in Microsoft Entra ID. They allow developers and administrators to implement role-based access control (RBAC) within their applications. App roles can be assigned to:
- Users and groups: For delegated scenarios where the app needs to know the user's role.
- Applications (service principals): For application-to-application authorization scenarios.
App roles are declared in the application manifest (or through the Entra ID portal under App registrations > App roles). When a user or application is assigned an app role, that role appears as a claim in the token (the roles claim), which the receiving application can then use to make authorization decisions.
How API Permissions Work — Step by Step
1. Register the application in Microsoft Entra ID under App registrations.
2. Configure API permissions in the portal by navigating to the app registration > API permissions > Add a permission. You can choose from Microsoft APIs (like Microsoft Graph) or your own custom APIs.
3. Select the permission type: Delegated or Application.
4. Grant admin consent (if required). Some permissions, especially application permissions and high-privilege delegated permissions, require a Global Administrator or Privileged Role Administrator to grant consent on behalf of the organization.
5. The application requests a token from the Microsoft identity platform. The token includes the granted permissions (as scopes for delegated permissions or roles for application permissions).
6. The target API validates the token and checks the permissions/roles claims to authorize or deny the request.
How App Roles Work — Step by Step
1. Define app roles in the app registration manifest or through the portal (App registrations > App roles > Create app role). You specify a display name, allowed member types (Users/Groups, Applications, or Both), a value (the string that appears in the token), and a description.
2. Assign users, groups, or applications to the app roles. For users and groups, this is done under Enterprise applications > Users and groups. For applications, you assign the app role as an application permission.
3. The roles claim appears in the token issued to the application. The application reads the roles claim and enforces authorization logic accordingly.
Key Differences Between Delegated and Application Permissions
Delegated Permissions:
- Require a signed-in user
- Effective access = intersection of app permissions and user privileges
- Can use user consent or admin consent
- Use the scp (scope) claim in the access token
Application Permissions:
- No signed-in user required
- Effective access = exactly what is granted to the app
- Always require admin consent
- Use the roles claim in the access token
Consent Framework
Understanding the consent framework is essential:
- User consent: Individual users can consent to low-risk delegated permissions for an app (if allowed by policy).
- Admin consent: An administrator consents on behalf of the entire organization. Required for application permissions and high-privilege delegated permissions.
- Admin consent workflow: If user consent is restricted, users can request admin consent through a workflow that notifies designated reviewers.
- Administrators can configure permission grant policies to control which permissions users can consent to on their own.
The .default Scope
When requesting tokens using the client credentials flow (application permissions), the application requests the .default scope (e.g., https://graph.microsoft.com/.default). This tells the Microsoft identity platform to issue a token with all application permissions that have been granted and consented to.
Practical Scenarios for the SC-300 Exam
- A daemon application needs to read all users in the directory without user interaction: Use application permissions with User.Read.All on Microsoft Graph, and grant admin consent.
- A web application needs to read the signed-in user's profile: Use delegated permissions with User.Read.
- A custom API needs to differentiate between admin and regular users: Define app roles such as Admin and Reader, assign users to these roles, and check the roles claim in the incoming token.
- An application calls another custom API in a service-to-service scenario: Define an app role with allowed member type set to Applications, assign the calling app's service principal to that role, and validate the roles claim in the API.
Important Portal Navigation
- App registrations > API permissions: Where you add, remove, and manage API permissions for the application.
- App registrations > App roles: Where you define custom roles for the application.
- App registrations > Expose an API: Where you define scopes (delegated permissions) that your custom API exposes to client applications.
- Enterprise applications > Users and groups: Where you assign users and groups to app roles.
- Enterprise applications > Permissions: Where you review and grant/revoke admin consent.
Microsoft Graph Permission Tiers (Common Examples)
- User.Read: Read the signed-in user's profile (delegated, low privilege)
- User.Read.All: Read all users' profiles (delegated or application, higher privilege)
- Mail.Read: Read the signed-in user's mail (delegated)
- Mail.Read (application): Read all users' mail (application, high privilege, requires admin consent)
- Directory.Read.All: Read directory data (application, requires admin consent)
Exam Tips: Answering Questions on API Permissions and App Roles
1. Know the difference between delegated and application permissions. If the scenario describes a daemon, background service, or service-to-service communication with no user involvement, the answer is application permissions. If a user is signed in and the app acts on their behalf, it is delegated permissions.
2. Remember the effective permissions rule for delegated permissions. The effective access is the intersection of what the app is granted and what the user can do. This is a common exam trap — an app with User.Read.All delegated permission does NOT mean a regular user can suddenly read all profiles.
3. Application permissions always require admin consent. If a question asks who needs to consent for an application permission, the answer is always an administrator (Global Administrator or Privileged Role Administrator).
4. Understand app roles vs. API permissions. App roles are for RBAC within your application or for app-to-app authorization. API permissions are for accessing external APIs. If a question talks about controlling what a user or service can do within an application, think app roles. If it talks about accessing Microsoft Graph or another API, think API permissions.
5. The roles claim vs. the scp claim. Application permissions appear in the roles claim. Delegated permissions appear in the scp (scope) claim. App roles assigned to users also appear in the roles claim. Exam questions may test your knowledge of which claim to inspect.
6. Admin consent workflow questions. If users cannot consent to an app and need to request access, the admin consent workflow must be enabled. Know that this is configured under Enterprise applications > User settings.
7. Expose an API vs. API permissions. If the question is about a custom API that needs to define its own permissions for client apps to request, the answer involves Expose an API and defining scopes. If the question is about a client app requesting access to an existing API, the answer involves API permissions.
8. Least privilege principle. Always choose the permission with the least privilege that satisfies the requirement. If a question asks which permission to assign for reading the signed-in user's profile, choose User.Read over User.Read.All.
9. Watch for keyword signals in exam questions. Keywords like without user interaction, background process, daemon, or service principal signal application permissions. Keywords like on behalf of the user, signed-in user, or user context signal delegated permissions.
10. Service principal assignments. When assigning app roles to another application (service-to-service), remember that you are assigning the role to the service principal of the calling application, not the app registration itself. This is a subtle but important distinction that may appear in exam scenarios.
11. Incremental consent. For delegated permissions, applications can use incremental consent to request additional permissions as needed rather than requesting all permissions upfront. This is a best practice that may appear in scenario-based questions.
12. Review the permission grant status. In the portal, a permission can be in a state of Granted for [tenant] (admin consented) or Not granted. Questions may present screenshots or descriptions of the permission status and ask you to identify the issue (e.g., permissions added but not yet consented to by an admin).
