OAuth Consent and Enterprise Application Permissions

Manage OAuth Consent and Permission Grants

Understanding Permission Types

Enterprise applications in Microsoft Entra ID use OAuth permission grants to control how apps access data. There are two main types of permissions that serve different purposes. Delegated permissions allow an application to act on behalf of a signed-in user, meaning the app can access resources as if the user were doing it themselves. Application permissions let an application run with its own identity without any user context, which is common for background services or automated tasks. Delegated permissions require either user consent or admin consent before an app can use them, while application permissions always require an administrator to grant consent because they give broader access.

Configuring Consent Settings

Administrators control how consent works across the tenant through several settings that work together. User consent settings determine whether regular users can approve permissions for themselves or whether every permission request needs administrator approval. The admin consent workflow routes permission requests to designated approvers when users cannot grant them directly, which helps balance security with user productivity. Tenant-wide admin consent allows an administrator to grant an application access for all users at once, which is useful for approved business applications but carries significant risk if misused. These settings form a layered approach where administrators can lock down consent entirely, allow limited user consent, or delegate approval authority to specific users.

Auditing Granted Permissions

Organizations must regularly review which permissions have been granted to detect over-privileged access. Azure AD activity logs record consent events and permission grants, showing who approved what and when. The Microsoft Graph API provides programmatic access to permission data: administrators query the oauth2PermissionGrants endpoint to review delegated permissions and appRoleAssignments to review application permissions. These logs reveal which applications and users have access to which data scopes, making it possible to identify permissions that no longer serve a business purpose. Regular auditing ensures that granted permissions align with the principle that users and apps should have only the minimum access needed to perform their jobs.

Revoking Unnecessary Access

When an application or user no longer needs a permission, administrators can revoke consent to immediately stop access. To remove a delegated permission grant, administrators use the Microsoft Entra admin center or call DELETE /oauth2PermissionGrants/{grant-id} through Microsoft Graph. To remove an application permission, they call DELETE /servicePrincipals/{id}/appRoleAssignedTo/{assignment-id}. After revocation, the application can no longer use that grant to access resources. However, if dynamic consent settings remain enabled, applications might immediately request consent again, so administrators should lock down consent settings once unnecessary access is identified to prevent re-consent.

Maintaining Least-Privilege Security

A secure environment requires ongoing attention to permission grants through a least-privilege model. Organizations should implement permission grant policies that restrict which scopes users can approve, blocking high-risk permissions from being granted without administrator review. Access reviews periodically validate that granted permissions remain necessary, removing any that are no longer needed. These reviews work alongside Conditional Access policies and continuous monitoring to ensure that consent and permission grants align with organizational security requirements. The combination of preventive controls, regular auditing, and automated monitoring creates a defense-in-depth approach to managing enterprise application access.