Baseline

Consent & Permissions

OAuth consent settings are one of the most commonly misconfigured areas of Entra ID. CONFIG365 enforces a consistent consent policy — blocking users from granting over-privileged access to third-party apps, and routing all risky requests through an admin approval workflow.

OAuthConsent PolicyAdmin Consent WorkflowPermission ClassificationsApp Governance

The OAuth Phishing Threat

OAuth phishing (also called consent phishing) tricks users into granting a malicious application access to their Microsoft 365 data — bypassing MFA entirely, because the attacker never needs the user's password.

Attack Flow (Without Protection) 

Attacker registers a malicious OAuth app
   → Sends phishing email with "Sign in with Microsoft" link
   → User clicks, redirected to legitimate Microsoft consent page
   → App requests Mail.Read + Files.Read permissions
   → Without CONFIG365: user clicks "Accept" → attacker has mailbox access
   → With CONFIG365: consent blocked, request sent to admin → attacker stopped

CONFIG365 Defence

  • • Unverified publisher apps are blocked at the consent page — users see a "Request access" dialog instead
  • • Admin consent workflow routes all blocked requests to designated reviewers
  • • Admins review the app, publisher, and requested permissions before approving
  • • Attacker's malicious app is denied — no data access granted

Configuration Reference

Deployed via deployConsentPermissions pipeline toggle.

User Consent

User consent for apps from verified publishers
Allowed (low-risk permissions only)

Users may consent to verified publisher apps requesting permissions classified as Low risk. All other requests require admin approval.

User consent for apps from unverified publishers
Blocked

Users cannot grant consent to applications whose publisher is not verified by Microsoft. Request routes to admin consent workflow.

Group owner consent for apps accessing group data
Disabled

Group owners cannot grant app access to group data on behalf of the group. All consent flows through the admin.

Admin Consent Workflow

Admin consent workflow
Enabled

When a user cannot grant consent, they are shown a request dialog. Their request is sent to designated reviewers for approval or denial.

Consent request reviewers
Configured per-tenant

One or more admins or groups are designated as reviewers. Reviewers receive email notifications for pending requests.

Request expiration
30 days

Consent requests that are not acted on within 30 days expire automatically. Users receive notification to re-request if needed.

Request reminders
Weekly

Reviewers receive weekly reminder emails for pending requests to prevent requests from going unnoticed.

Permission Classifications

Low risk permissions
User.Read, email, openid, profile, offline_access

These permissions can be granted by users to verified apps. They expose minimal personal data and are safe for general self-service consent.

Medium / High risk permissions
Require admin consent

All permissions not explicitly classified as Low risk require admin approval before being granted — protecting sensitive data from over-privileged apps.

How It's Deployed

Consent settings are deployed via the Microsoft Graph API using the Configure-ConsentPermissions.ps1 script. The script reads JSON definition files from the baseline repository and applies them using Policy.ReadWrite.PermissionGrant Graph permissions.

Graph Endpoints Used

  • GET/PATCH /policies/authorizationPolicy
  • GET/PATCH /policies/adminConsentRequestPolicy
  • GET/POST /permissionGrantPolicies
  • GET/POST /policies/permissionGrantPreApprovalPolicies

Required Permissions

  • Policy.ReadWrite.PermissionGrant
  • Policy.Read.All
  • AppRoleAssignment.ReadWrite.All
Back to Baseline Documentation