This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
--> Secure access to resources by using Microsoft Entra ID
--> Manage OAuth permission grants and consent settings
Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.
Overview
Microsoft Entra ID uses OAuth 2.0 permissions and consent to control whether applications can access protected resources such as Microsoft Graph and other APIs. When an application requests access to an API, the requested permissions describe what the application wants to do, and consent is the process through which a user or administrator authorizes that access.
For the SC-500 exam, it is important to understand that OAuth permissions are not simply an application configuration detail. They are an important security control because granting an application excessive permissions can allow that application to access sensitive organizational data.
The key concepts to understand are:
- Delegated permissions
- Application permissions
- User consent
- Administrator consent
- Tenant-wide admin consent
- OAuth permission grants
- User consent settings and policies
- Admin consent workflow
- Reviewing and revoking permissions
- Least privilege for application permissions
- The relationship between app registrations and enterprise applications
1. Understanding OAuth Permissions
An application normally needs permission to access a protected API. For example, an application might need to:
- Read a user’s basic profile
- Read a user’s email
- Read files that a user can access
- Read organizational directory information
- Access mailboxes
- Access data without a signed-in user
Microsoft Entra represents these access requirements as API permissions.
There are two fundamental permission types:
- Delegated permissions
- Application permissions
Understanding the difference is one of the most important concepts for this topic.
2. Delegated Permissions
Delegated permissions are used when an application acts on behalf of a signed-in user.
The application does not receive more authority than the combination of the permissions granted to the application and the user’s own access allows.
For example, suppose an application receives the Microsoft Graph delegated permission:
Files.Read.All
The application is acting on behalf of the signed-in user. The application can access files that the signed-in user is permitted to access.
The important idea is:
Delegated permission = application + signed-in user
The user is part of the authorization context.
Example
A user signs into a document-management application.
The application requests:
User.ReadFiles.Read
The user grants consent.
The application can then call Microsoft Graph on behalf of that user, subject to the permissions that were granted and the user’s own access.
Delegated permissions are commonly used by:
- Web applications
- Mobile applications
- Single-page applications (SPAs)
- Applications where a user is actively signed in
Microsoft refers to delegated permissions as scopes or OAuth2 permission scopes.
3. Application Permissions
Application permissions are used when an application accesses an API without a signed-in user.
This is commonly referred to as app-only access.
For example, a background service might need to periodically process files or retrieve organizational information without requiring a user to be logged in.
The application authenticates using its own identity and receives permissions assigned directly to the application.
The important idea is:
Application permission = application acting as itself
Application permissions can potentially provide very broad access. For example, an application permission that allows an application to read files across an organization can provide access to data that no individual user is currently accessing.
Application permissions are commonly used by:
- Daemon applications
- Background services
- Automation processes
- Server-to-server applications
Application permissions are also called app roles or app-only permissions. They require administrator consent.
4. Delegated vs. Application Permissions
This distinction is extremely important for the SC-500 exam.
| Characteristic | Delegated Permission | Application Permission |
|---|---|---|
| User signed in? | Yes | No |
| Application acts on behalf of user? | Yes | No |
| Application acts as itself? | No | Yes |
| Common application types | Web, mobile, SPA | Daemon, background service |
| Also called | Scopes | App roles |
| User can potentially consent? | Yes, depending on tenant settings and permission | No |
| Administrator consent required? | Sometimes | Yes |
| Typical risk | Access to user’s permitted data | Potentially organization-wide access |
A useful exam rule is:
If a user is present, think delegated permissions. If the application must operate without a user, think application permissions.
5. What Is OAuth Consent?
Consent is the process by which a user or administrator authorizes an application to access a protected resource.
Consider an application requesting:
“Read your email.”
The application has declared the permission it needs, but simply declaring the permission doesn’t automatically mean it can use it.
Consent establishes authorization for the requested access.
A typical user experience is:
- The user signs into the application.
- The application requests access to an API.
- Microsoft Entra evaluates the requested permissions.
- Microsoft Entra determines whether consent has already been granted.
- If consent is required, the user or administrator is presented with a consent experience.
- If consent is granted, the application can request tokens containing the appropriate permissions.
Microsoft Entra records the resulting authorization information.
6. User Consent
User consent allows a user to authorize an application to access resources on the user’s behalf.
Whether users can provide consent is controlled by the organization’s Microsoft Entra configuration.
By default, users may be allowed to consent to applications requesting permissions that don’t require administrator consent. However, administrators can restrict or disable user consent to reduce the risk of malicious or overly privileged applications.
Example
A user installs an application that requests:
Read your basic profile
If the organization’s consent policy permits the user to grant that permission, the user can approve the request.
The consent is generally associated with that user rather than automatically granting the permission to every user in the tenant.
7. Why User Consent Is a Security Concern
OAuth consent can create a significant security risk if users are allowed to authorize untrusted applications.
Consider a malicious application that appears to be a legitimate productivity application.
The application requests permission to:
- Read email
- Read files
- Read contacts
A user may approve the request without understanding the implications.
The application could then potentially access sensitive information available to that user.
This is why security administrators should consider:
- Which users can grant consent
- Which applications can receive consent
- Which permissions users can approve
- Whether the publisher is verified
- Whether the requested permissions are appropriate
- Whether the application actually requires the requested permissions
Microsoft recommends evaluating the application, publisher, requested permissions, and business justification before granting significant permissions.
8. Configuring User Consent Settings
Microsoft Entra administrators can configure how users are allowed to consent to applications.
Organizations can use consent settings to make the environment more restrictive.
Depending on the configuration, an organization can:
- Allow users to consent to applications
- Restrict user consent to specific permissions
- Allow consent only for applications from verified publishers
- Disable user consent so that administrators must approve applications
This provides an important security control.
For example, a highly regulated organization might decide:
“Users must never independently authorize applications to access organizational data.”
The organization can configure Microsoft Entra so that administrator approval is required.
Alternatively, an organization might allow users to consent to low-risk permissions from trusted or verified applications while requiring administrator approval for more sensitive permissions.
This is an example of balancing security with usability.
9. Permission Classifications
Organizations can further control which permissions users are allowed to consent to.
Permission classifications allow administrators to identify permissions as appropriate for user consent.
For example, an organization might allow users to consent to relatively low-risk permissions while requiring administrator approval for more sensitive permissions.
This supports a least-privilege approach:
Users should be able to grant only the permissions that the organization considers appropriate for self-service approval.
This is particularly useful in large organizations where completely disabling user consent would create unnecessary administrative overhead.
10. Administrator Consent
Some permissions require administrator consent.
This is especially important for:
- Application permissions
- High-privilege delegated permissions
- Permissions that expose organizational data beyond the user’s normal context
An administrator can grant consent on behalf of users.
For example, suppose an application requires:
User.ReadGroup.Read.All
An administrator can review the requested permissions and grant consent for the organization if the permissions are appropriate.
After tenant-wide administrator consent has been granted, users generally don’t have to individually approve those already-consented permissions.
However, if the application later requests additional permissions, additional consent may be required.
11. Tenant-Wide Administrator Consent
Tenant-wide admin consent grants an application permission on behalf of the organization.
This is significantly more powerful than an individual user granting consent.
For example:
An administrator grants an application the delegated permission
User.Read.Allfor all users in the tenant.
The consent applies organizationally rather than only to the administrator’s account.
This makes tenant-wide consent a significant security decision.
Before granting tenant-wide consent, administrators should verify:
- The application is legitimate.
- The publisher is trusted.
- The requested permissions are necessary.
- The permissions follow least privilege.
- The application’s business purpose justifies the access.
- The application is not requesting unrelated or excessive permissions.
Microsoft specifically recommends examining the requested permissions and publisher before granting tenant-wide consent.
12. Tenant-Wide Consent Does Not Necessarily Mean Every User Can Use the Application
A subtle but important security concept is that granting tenant-wide consent does not necessarily mean every user must be allowed to access the application.
An organization can still restrict application access by requiring users or groups to be assigned to the enterprise application.
For example:
- Tenant-wide consent is granted.
- User assignment is required.
- Only members of the Finance group are assigned.
- Only those users can access the application.
This allows administrators to separate:
“Has the organization authorized the application’s permissions?”
from:
“Which users are allowed to use the application?”
Microsoft Entra supports requiring user assignment to restrict access even when tenant-wide admin consent has been granted.
13. The Admin Consent Workflow
Organizations can configure an admin consent workflow to allow users to request administrator approval when they encounter an application that requires consent they cannot provide themselves.
The workflow provides a structured alternative to users simply receiving an error and having to figure out who to contact.
A typical process is:
- A user attempts to use an application.
- The application requests permissions.
- The user isn’t permitted to grant those permissions.
- The user submits an admin consent request.
- Designated reviewers receive the request.
- A reviewer evaluates the application and requested permissions.
- The reviewer approves or denies the request.
- The user is notified of the decision.
An important security point is that being designated as a reviewer does not automatically give the reviewer permission to grant administrator consent. The reviewer must already have the appropriate permissions to perform the consent operation.
14. Reviewing an OAuth Consent Request
When reviewing an application requesting consent, don’t simply ask:
“Do we recognize this application?”
Instead, evaluate the complete request.
1. Who published the application?
Determine whether the publisher is trusted.
Be cautious about applications that imitate well-known products or organizations.
2. What permissions are requested?
Review every permission.
Don’t approve an application simply because its name is familiar.
3. Why does the application need the permissions?
The requested permissions should support the application’s documented purpose.
For example, a reporting application might reasonably need access to reporting data.
That doesn’t automatically mean it needs access to every user’s mailbox.
4. Is the requested access excessive?
Apply least privilege.
If an application only needs read access, don’t grant write access.
If it only needs a subset of organizational data, avoid granting organization-wide access.
5. Is administrator consent actually required?
Determine whether the application could operate with lower-privilege delegated permissions instead.
15. Verified Publishers
A verified publisher provides additional information that can help administrators and users establish trust in an application.
However:
Verified publisher does not mean “automatically safe.”
Verification can increase confidence in the publisher’s identity, but administrators should still evaluate:
- Requested permissions
- Application purpose
- Data being accessed
- Business justification
- Least privilege
- Application behavior
Security decisions should never be based solely on the publisher verification status.
16. OAuth Permission Grants
A permission grant represents authorization for an application to access an API.
For delegated permissions, Microsoft Entra can record an OAuth2 permission grant.
A useful distinction is:
- Delegated permission grant → OAuth2 permission grant
- Application permission grant → app role assignment
For Microsoft Graph, for example, an OAuth2PermissionGrant represents delegated permission consent, while application permissions are represented through an appRoleAssignment.
This distinction can appear in advanced scenario questions involving Microsoft Graph or automation.
17. Managing Granted Permissions
Administrators should periodically review applications that have received OAuth permissions.
Look for:
- Applications no longer in use
- Excessive permissions
- Unexpected applications
- Permissions granted by users who should no longer have access
- Applications from untrusted publishers
- Permissions that are broader than the application’s business purpose
Unused or excessive permissions should be removed.
The security principle is straightforward:
Grant only what is necessary, and remove access when it is no longer necessary.
18. Revoking Consent
If an application is compromised, no longer trusted, or no longer required, administrators can revoke its previously granted permissions.
Revocation removes the authorization that allowed the application to access the protected resource.
Administrators can also limit application access through controls such as:
- Requiring user assignment
- Disabling user sign-in to the application
- Removing permissions
- Disabling or removing the enterprise application
Revoking consent should be considered part of the application’s lifecycle management, not simply an incident-response activity.
19. Updating Application Permissions
Application requirements can change.
Suppose an application originally requested:
User.Read
Later, the developer adds a requirement for:
Group.Read.All
Adding the new permission to the app registration does not automatically mean that existing users or administrators have already consented to the new permission.
The additional permission may require a new consent operation.
If the new permission requires administrator consent, an administrator must provide the required consent.
This is important when troubleshooting applications that suddenly begin displaying consent prompts or fail when requesting access tokens.
20. App Registration vs. Enterprise Application
Understanding the relationship between these two objects is important when managing OAuth permissions.
App registration
An app registration represents the application’s identity and configuration in Microsoft Entra.
It contains configuration such as:
- Application/client ID
- Redirect URIs
- API permissions
- Authentication configuration
- Credentials or certificates
- Exposed APIs
Enterprise application
An enterprise application is the service principal representation of an application in a particular tenant.
It is used for tenant-specific management such as:
- User and group assignment
- Application access
- Permissions and consent
- Sign-in controls
- Enterprise application properties
A useful mental model is:
App registration = definition of the application
Enterprise application/service principal = application’s presence and management representation in a tenant
OAuth consent is closely associated with the enterprise application/service principal because the actual authorization applies within a tenant.
21. Security Principle: Least Privilege
OAuth permission management should follow the principle of least privilege.
For example, if an application only needs to read calendar information, don’t approve permissions that allow it to:
- Modify calendars
- Read mailboxes
- Delete files
- Manage users
- Access all organizational data
The more powerful the permission, the more carefully it should be evaluated.
Application permissions deserve particular attention because they can allow an application to access organizational data without an interactive user.
22. Common SC-500 Scenarios
Scenario 1: Users should be able to authorize low-risk applications
Use appropriately configured user consent settings and permission classifications.
Scenario 2: Users must never authorize applications themselves
Configure user consent so that administrator approval is required.
Scenario 3: A user needs an application that requires admin approval
Configure the admin consent workflow so the user can submit an approval request.
Scenario 4: A background service must access Microsoft Graph without a user
Use application permissions and obtain administrator consent.
Scenario 5: A web application needs to access a user’s files
Use delegated permissions because the application is operating on behalf of a signed-in user.
Scenario 6: An application has excessive permissions
Review the application’s requested permissions and reduce them according to least privilege.
Scenario 7: An application is no longer trusted
Revoke its consent and, where appropriate, disable access to the enterprise application.
23. Important Exam Distinctions
Memorize these distinctions:
| If the question says… | Think… |
|---|---|
| “On behalf of the signed-in user” | Delegated permission |
| “Without a signed-in user” | Application permission |
| “Background service” | Application permission |
| “User’s files” | Delegated permission |
| “Organization-wide access” | Potentially application permission or tenant-wide admin consent |
| “Allow users to approve low-risk apps” | User consent settings |
| “Users cannot approve the requested permission” | Admin consent |
| “User requests administrator approval” | Admin consent workflow |
| “Approve for everyone in the organization” | Tenant-wide admin consent |
| “Limit who can access the application” | User/group assignment |
| “Remove previously granted authorization” | Revoke consent |
| “Excessive permissions” | Least privilege |
| “Who published the application?” | Publisher/trust evaluation |
| “No signed-in user” | Application permission |
| “Application acting on behalf of user” | Delegated permission |
24. Key Takeaways
For the SC-500 exam, remember the following:
- Delegated permissions allow an application to act on behalf of a signed-in user.
- Application permissions allow an application to act without a signed-in user.
- Application permissions generally require administrator consent.
- User consent can be controlled through Microsoft Entra user consent settings.
- Administrators can restrict consent based on application and permission characteristics.
- Tenant-wide admin consent authorizes requested permissions for the organization.
- Tenant-wide consent does not necessarily mean every user must be allowed to use the application; access can still be restricted.
- The admin consent workflow provides a structured mechanism for users to request approval.
- Reviewers in the admin consent workflow must have the appropriate permissions to grant consent.
- Always evaluate the application, publisher, permissions, and business justification before granting consent.
- Use least privilege when approving OAuth permissions.
- Regularly review and revoke unnecessary or suspicious application permissions.
- Adding new API permissions does not automatically mean those permissions have already been consented to.
- For Microsoft Graph, delegated OAuth authorization is represented by an OAuth2 permission grant, while application permissions are represented through app role assignments.
- Understanding the difference between an app registration and an enterprise application/service principal is important when managing application access.
Practice Exam Questions
Question 1
A company has a web application that allows employees to view documents stored in Microsoft Graph. Employees must sign in to the application, and the application should access only resources that the signed-in employee is authorized to access.
Which type of Microsoft Entra permission should the application primarily use?
A. Azure RBAC role
B. Application permission
C. Delegated permission
D. Managed identity role assignment
Answer: C. Delegated permission
Explanation
Delegated permissions are designed for applications that access resources on behalf of a signed-in user. The user’s identity is part of the authorization context.
Application permissions are intended for app-only scenarios where there is no signed-in user. Azure RBAC is used for Azure resource authorization and isn’t a replacement for Microsoft Graph OAuth delegated permissions.
Question 2
An organization wants a background service to access Microsoft Graph every night. The service must continue operating even when no users are signed in.
Which permission model should be used?
A. Delegated permissions
B. Application permissions
C. User consent permissions
D. Interactive authentication only
Answer: B. Application permissions
Explanation
The service needs to operate without a signed-in user, making this an app-only scenario. Application permissions are designed for background services, daemons, and other workloads that authenticate as the application itself.
Application permissions require administrator consent.
Question 3
A security administrator wants to prevent users from independently granting OAuth consent to applications because of concerns about malicious applications accessing organizational data.
What should the administrator configure?
A. Azure Policy
B. Azure RBAC
C. Microsoft Entra user consent settings
D. Network security groups
Answer: C. Microsoft Entra user consent settings
Explanation
Microsoft Entra user consent settings control whether and under what circumstances users can grant applications access to protected resources.
Azure Policy and Azure RBAC address different security areas and don’t control Microsoft Entra OAuth user consent.
Question 4
A user attempts to access an application that requires permissions for which the user isn’t authorized to provide consent. The organization wants the user to be able to submit the request to an administrator for review.
Which feature should be configured?
A. Application Proxy
B. Conditional Access
C. Privileged Identity Management
D. Admin consent workflow
Answer: D. Admin consent workflow
Explanation
The admin consent workflow allows users to submit requests for applications that require administrator approval.
Designated reviewers can evaluate the requests and approve or deny them. Being a reviewer does not automatically grant the reviewer permission to provide admin consent.
Question 5
An administrator is reviewing an application that requests tenant-wide permission to read organizational data. The administrator wants to determine whether the requested access is appropriate before approving it.
Which consideration should be the highest priority?
A. Whether the requested permissions follow least privilege and match the application’s business purpose
B. Whether the application has the most attractive user interface
C. Whether the application has the largest number of users
D. Whether the application was registered recently
Answer: A. Whether the requested permissions follow least privilege and match the application’s business purpose
Explanation
Tenant-wide consent can grant significant organizational access. Administrators should evaluate the requested permissions, publisher, application purpose, and whether the permissions are necessary.
The most important security principle is least privilege: grant only the access required for the application’s legitimate function.
Question 6
A company grants tenant-wide administrator consent to an application but wants only members of the Finance group to be able to use it.
What should the administrator configure?
A. Remove the tenant-wide consent
B. Require user assignment to the enterprise application
C. Convert application permissions to Azure RBAC
D. Disable all Microsoft Graph permissions
Answer: B. Require user assignment to the enterprise application
Explanation
Tenant-wide consent and application access are separate concerns.
The organization can grant the necessary consent while requiring users or groups to be assigned to the enterprise application. This allows the company to restrict application access to the Finance group.
Question 7
An application originally requested User.Read. Several months later, the developer adds Group.Read.All. Existing users begin seeing new consent requirements.
Why can this occur?
A. OAuth permissions automatically expire after six months
B. Microsoft Graph requires users to authenticate every time
C. The newly requested permission may not have been previously consented to
D. User assignment automatically removes all previous permissions
Answer: C. The newly requested permission may not have been previously consented to
Explanation
Adding a new API permission to an application does not automatically mean that users or administrators have already granted consent for that permission.
If the new permission requires consent, a new consent operation may be necessary. If it requires administrator consent, an administrator must provide the required authorization.
Question 8
A security team discovers that an application has been granted delegated permissions that are no longer required. The application is still used by the organization.
What is the best security action?
A. Grant additional permissions to ensure compatibility
B. Convert all delegated permissions to application permissions
C. Delete the Microsoft Entra tenant
D. Review and revoke unnecessary permissions
Answer: D. Review and revoke unnecessary permissions
Explanation
Unused permissions increase the application’s potential attack surface.
The correct approach is to review the permissions and remove those that are no longer necessary. This supports the principle of least privilege while allowing the application to remain in use.
Question 9
A security administrator is examining a Microsoft Graph authorization record and wants to determine whether it represents delegated OAuth consent rather than an application permission assignment.
Which object is associated with delegated OAuth permission grants?
A. OAuth2PermissionGrant
B. NetworkSecurityGroup
C. RoleAssignment
D. ConditionalAccessPolicy
Answer: A. OAuth2PermissionGrant
Explanation
For Microsoft Graph, an OAuth2PermissionGrant represents delegated permission consent.
Application permissions are represented through app role assignments.
This distinction is useful when reviewing Microsoft Graph data programmatically or troubleshooting application authorization.
Question 10
A company wants to allow users to provide consent for applications from trusted publishers when they request only specifically approved permissions. All other applications or permissions should require administrator approval.
Which approach best meets this requirement?
A. Give all users the Application Administrator role
B. Configure user consent settings and restrict which applications and permissions users can approve
C. Grant tenant-wide administrator consent to every application
D. Disable Microsoft Graph for the entire tenant
Answer: B. Configure user consent settings and restrict which applications and permissions users can approve
Explanation
Microsoft Entra user consent settings can be configured to control when users are allowed to provide consent. Organizations can use restrictive consent policies and permission classifications to permit appropriate self-service consent while requiring administrator approval for higher-risk scenarios.
Granting users administrative application-management privileges or granting consent to every application would substantially weaken the security model.
Go to the SC-500 Exam Prep Hub main page
