OAuth App Consent Audit: The Microsoft 365 Backdoor People Miss

Not every identity problem starts with a password. In Microsoft 365, an OAuth application with the wrong permissions can create a long-lived access path — a backdoor — that users barely notice and admins often forget to review.

That is why app consent audits matter. They are less dramatic than a compromised admin account, but in many tenants they are also less mature.

The messy version usually happens like this: a user signs into a helpful-looking third-party app, grants access, nobody records the business owner, and later the tenant cannot easily explain which apps can read mail, files, chats, or directory data.

What to review

Area	Question
User consent	Can users grant apps access without review?
Admin consent	Who can approve high-risk permissions?
Enterprise apps	Which apps have broad permissions?
App owners	Does every app have a real owner?
Publisher status	Are apps verified and expected?

That review needs both configuration and inventory. Settings alone do not tell you whether a risky grant already exists.

The permission patterns worth challenging first

Certain patterns deserve early attention:

• mail read or send permissions that are broader than the use case
• file read or write access across SharePoint or OneDrive where ownership is vague
• directory read or write permissions granted without a strong reason
• long-lived offline access combined with wide scopes
• application permissions approved at tenant level with no named owner

The key question is simple: if this app was challenged during an incident review, could you explain why it still needs the permissions it has?

A sensible control model for most SMEs

Open user consent for anything broadly powerful is usually too loose.

A more defensible position is:

Control	Practical stance
User consent	Limited to lower-risk permission sets, or restricted further where needed
Admin consent workflow	Enabled so requests can be reviewed instead of bypassed
Reviewers	Small, named set of people who understand the implications
App inventory review	Scheduled, especially for high-permission apps
Ownership	Every important app has a business and technical owner

Microsoft's current admin consent workflow documentation is worth reading carefully. Reviewers can block or deny requests, but only Global Administrators can approve requests for apps asking for Microsoft Graph application permissions. That is a useful boundary to understand before you assume "reviewers" means "anyone on the list can approve anything".

Verified publisher status helps, but it is not the whole answer

Verified publisher status is useful context. It is not a substitute for reviewing the permissions and the business case.

Plenty of questionable access decisions were made through legitimate apps solving real short-term problems. The issue is not always malware. Sometimes it is just overreach that was never tidied up.

Evidence worth keeping

For this area, a lightweight evidence pack goes a long way:

• current user consent settings
• admin consent workflow settings and reviewer list
• exported inventory of higher-risk enterprise apps
• list of removed or reduced grants
• named owners for the apps that remain

That gives you something concrete to use during internal reviews, customer due diligence, or incident response.

What "good" looks like

You do not need to ban every third-party application to be in control.

You do need to reach a point where:

• users are not freely granting risky access
• admins understand what the approval path is
• broad permissions are rare and deliberate
• every important app has an owner

That is the standard. If no one can say why an app still has mail or file access across the tenant, the control is weaker than it looks.

References

• Microsoft detect and remediate illicit consent grants
• Configure user consent settings
• Configure the admin consent workflow