Skip to main content

OAuth Consent Grants

Surface Security monitors and controls third-party application authorizations made via Microsoft sign-in, protecting your organization against one of the most effective account-takeover techniques in use today: OAuth consent phishing.

When an employee signs in with their Microsoft account, they sometimes see a consent screen asking them to allow a third-party app access to their mail, calendar, contacts, or files. Attackers craft malicious or over-privileged apps that look legitimate and target employees with these consent prompts.

Unlike credential phishing, the attacker never needs the employee's password. Once the employee clicks Accept, the app receives an access token that:

  • Persists as long as the app is active — it does not expire with the session.
  • Survives a password reset. Changing the employee's password does not revoke existing token grants.
  • Gives the attacker ongoing, quiet access to read mail, download files, or access contacts — from any location, using the app's own sign-in.

Surface Security intercepts this attack at the consent screen, before the employee clicks Accept. It can warn the employee to think twice, or block the consent screen entirely, based on the permissions the app is requesting and the policies you configure.

The OAuth Consent Grants page​

Navigate to Dashboard > OAuth > Consent Grants to see a complete inventory of every third-party app your employees have encountered via Microsoft sign-in.

Each row in the roster represents one app and shows:

ColumnWhat it tells you
AppDisplay name and application identifier
PublisherWhether the app is a Microsoft first-party app, a Surface-verified app, or unverified
Scopes (risk)A count of the permissions requested and their highest risk level
RiskThe overall risk rating for the app: Critical, High, Medium, or Low
UsersHow many employees have encountered this app's consent prompt
Last seenWhen the most recent consent event was recorded
PolicyYour current decision for the app: Allow, Warn, Block, or no decision yet

The roster defaults to showing the highest-risk apps first.

Risk levels​

Surface classifies the permissions (scopes) an app requests into four levels:

LevelWhat it means
CriticalAccess to mail, files, contacts, or calendar — the permissions attackers most commonly seek. Apps at this level warrant immediate review.
HighWrite access to directory, user accounts, or group membership — typically sought in targeted privilege-escalation attacks.
MediumRead-only access to shared calendars, all files (read), or similar broad-read scopes.
LowBasic identity scopes like name, email address, and sign-in confirmation. These are normal for legitimate sign-in integrations.

An app's overall risk rating reflects the most serious scope it requested. An app that asks for offline_access plus Mail.Read is rated Critical, regardless of how benign the other scopes are.

Publisher labels​

  • Microsoft — a first-party Microsoft application (Office, Teams, Exchange, etc.). These are always permitted and do not generate alerts.
  • Verified — an app on Surface's curated allowlist of known legitimate third-party apps. Verified apps are permitted by default.
  • Unverified — an app that is not on either list. Most unverified apps are legitimate, but they require scrutiny when requesting high-risk permissions.

Note on "Verified": The Verified label reflects Surface's internal allowlist, not a live check against Microsoft's own publisher-verification program. A third-party app that holds Microsoft's "Verified Publisher" badge may still appear as Unverified here in cases where it has not been added to the Surface curated list.

How to investigate an app​

Quick triage on the roster​

Sort by Risk (the default) and scan for:

  • Unverified apps with Critical or High risk — these are the highest priority.
  • Apps with a large Users count you do not recognize — wide adoption of an unknown app may indicate an active phishing campaign.
  • Apps with a Block or Warn policy that you haven't set — someone else on your team may have flagged it already.
  • Apps seen recently that you don't recognize.

Drilling into a specific app​

Click any row to open the app detail page. There you will find:

  • Full scope list — every permission the app requested, each with its risk level and a description of what that permission allows (for example, "Mail.Read — allows reading all messages in the user's mailbox").
  • Redirect destination — the domain the app redirected employees to after the consent screen. An unfamiliar or external domain on a high-risk app is a strong signal.
  • User and event timeline — a paginated record of which employees encountered the consent prompt, when, and what happened (whether Surface warned them, blocked the screen, or allowed it to proceed).
  • Quick-action buttons — shortcuts to create a scope rule for common permission families directly from the detail view.

Key signals to look for on the detail page:

  • offline_access scope — this means the app requested a long-lived refresh token. Access granted by a user who had offline_access authorized will persist even after a password reset. Treat any unverified app with offline_access plus mail or files as high priority.
  • External redirect domain — a legitimate productivity app usually redirects to a domain you recognize. An unfamiliar domain is a phishing indicator.
  • High user count for an unrecognized app — the consent prompt may have been distributed to many employees simultaneously.

Setting policy​

You have two complementary tools: per-app decisions and per-scope rules.

Per-app policy​

From the roster or the app detail page, use the Policy dropdown to set a decision for a specific app:

ActionWhat happens
AllowThe app is permitted for all users with no warning. Use this once you have reviewed an app and confirmed it is legitimate.
WarnEmployees see a warning banner on the Microsoft consent screen before they can approve. They may still proceed, but they are advised to check with IT first.
BlockThe consent screen is replaced with a block page. Employees cannot approve the app.

A per-app policy is the strongest control. It overrides all scope rules, including rules that would otherwise apply to the permissions the app requests.

To remove a per-app decision and return to scope-rule evaluation, clear the policy from the same dropdown.

Per-scope rules (Scope Rules tab)​

The Scope Rules tab lets you set a default action for any app requesting a given permission pattern. For example, you can configure:

  • Warn any unverified app that requests Mail.*
  • Block any unverified app that requests Files.Read.All

To add a rule:

  1. Click Add Rule.
  2. Enter a scope pattern (e.g., Mail.*, Files.*, *.Read.All).
  3. Choose an action: Allow, Warn, or Block.
  4. Add an optional reason for your records.
  5. Save. The rule is pushed to extensions within minutes.

Scope rules apply to all unverified apps that request a matching permission. They do not apply to Microsoft first-party apps or apps you have marked as Verified or explicitly Allowed — those are always permitted.

When multiple scope rules match a single app, the most restrictive action wins.

Policy precedence (simplified)​

  1. Per-app policy wins if one exists — the app is allowed, warned, or blocked as you specified, regardless of the scopes it requests.
  2. Microsoft and Verified apps are always allowed — scope rules never apply to them.
  3. Scope rules apply to all other apps. The most restrictive matching rule determines the action.
  4. No match — if no scope rule applies and no per-app policy is set, the app is logged silently (you see it in the roster; no warning is shown to the employee).

Day-one defaults​

Out of the box, Surface pre-configures warning rules for critical and high-risk permission families (mail, files, contacts, directory write access, and others). On day one, employees who encounter unverified apps requesting these permissions will see a warning — not a block. This means no legitimate workflows are disrupted immediately.

After reviewing the roster and identifying any apps you want to restrict further, you can escalate specific apps or scope families to Block.

What employees see​

Warn — a banner appears over the Microsoft consent screen. It explains that the app is requesting sensitive permissions and advises the employee to confirm with their IT team before proceeding. The employee can dismiss the banner and approve the app if they choose to.

Block — the consent screen is replaced with a Surface block page. The page explains that the app has been blocked by your organization's security policy and provides a message to contact the IT team. The employee cannot complete the authorization.

No action — if the app is allowed (explicitly or by default), the employee sees only the normal Microsoft consent screen with no Surface overlay.

Enforcement mode​

OAuth consent grant controls follow your tenant's overall enforcement mode:

  • Learning / monitoring mode — Surface observes and records consent events but does not show warnings or block pages. All events are still logged and alerts are still generated. Use this mode to build your baseline understanding of which apps are in use before enforcing.
  • Enforcement mode — Warn and Block rules take effect for users. Employees see the warning banner or block page as configured.

You can review your current mode under Settings > General Settings (Extension Mode section).

Alerts​

When an employee encounters an unverified app that matches a Warn or Block scope rule, Surface also raises an OAuth Consent Grant alert in your alert feed (Dashboard > Alerts). This happens even in learning mode, so your security operations team has full visibility regardless of enforcement state.

The alert includes the app name, the permissions requested, the risk level, and whether the employee was warned, blocked, or allowed to proceed.

Alert routing: OAuth Consent Grant alerts flow through your existing alert destinations. To forward them to a SIEM, webhook, or other destination, add an alert route under Dashboard > Org > Alert Routing and filter by alert type "OAuth Consent Grant."

If an alert shows a grant was completed (the employee approved the app after a warning, or in learning mode), and the app is one you do not recognize:

  1. Open the alert detail and click through to the app roster entry to see all affected users.
  2. Set the app to Block to prevent further authorizations.
  3. To revoke access already granted, use Microsoft Entra ID to revoke the app's token grants — this requires Microsoft Graph access outside of Surface.
  4. Check for mail or file access in your Microsoft audit logs.

Current limits​

These are honest boundaries of what the feature covers today.

Microsoft sign-in only. OAuth consent monitoring currently covers Microsoft (Entra ID / Azure AD) sign-in flows. Google, GitHub, and other OAuth providers are not yet included.

Consent-screen detection. Surface detects and acts on the consent request at the moment the employee reaches the Microsoft consent screen — before they click Accept. It also tracks likely-completed grants when the follow-up redirect is observed. Surface does not read Microsoft's own audit logs or the Entra directory, so it cannot report on:

  • Application permissions granted by an administrator out-of-band (admin consent flows that bypass the per-user consent screen).
  • Grants made before Surface was deployed.
  • Current grant state if an employee's browser was not open at the time of authorization.

"Verified" is a Surface curated list. The Verified label does not query Microsoft Entra's publisher-verification status in real time. A future update may add that enrichment as an additional signal.

No cross-tenant rollup (single tenant view). The roster shows apps and events for your individual tenant. If you manage multiple tenants through the Surface MSSP panel, each tenant's roster is reviewed separately.

Getting started​

  1. Review the roster. Go to Dashboard > OAuth > Consent Grants and look at what is already there. Sort by Risk and check the Critical and High entries first.

  2. Approve what you know. For apps your organization uses intentionally (for example, a productivity app you rolled out), set the policy to Allow.

  3. Escalate what concerns you. For apps you do not recognize that request mail, files, or contacts, set them to Block or Warn immediately.

  4. Review your scope rules. On the Scope Rules tab, check the pre-configured warn defaults and decide whether any should be escalated to Block for your environment.

  5. Set up alert routing. If you use a SIEM or incident-response platform, configure an alert route for OAuth Consent Grant alerts so your team is notified in real time.