OAuth Consent Attacks: How to Audit Which Apps Have Access to Your Microsoft 365 Tenant
Multi-factor authentication is one of the most important protections you can put around Microsoft 365.
But MFA cannot protect you from every kind of account abuse.
An attacker does not always need to steal a password.
Instead, they may persuade an employee to approve an application that requests access to:
files
calendars
contacts
directory information
The employee signs in to the real Microsoft login page.
They complete genuine MFA.
They see a genuine Microsoft consent screen.
Then they click:
Accept.
The attacker has not bypassed authentication.
The user has authorised the application.
This technique is generally known as:
OAuth consent phishing
or:
an illicit consent grant.
That is why every Microsoft 365 security review should include more than users and passwords.
You should also be asking:
Which applications have access to our tenant, what permissions do they have, and do we still trust them?
What Is OAuth Consent?
OAuth allows an application to access another service without requiring the user to hand over their password directly.
That is extremely useful.
A legitimate business application might request permission to:
read your calendar
create meetings
access documents
view your profile
send email
Microsoft displays the permissions requested and asks the user or administrator whether to approve them.
Once consent is granted, the application can receive tokens allowing it to perform the approved actions.
The security problem occurs when the application is:
malicious
compromised
unnecessarily powerful
no longer required
The consent system is working exactly as designed.
The wrong application has simply been trusted.
Why MFA May Not Stop an OAuth Consent Attack
MFA answers:
“Is this really the user signing in?”
OAuth consent asks:
“Should this application be allowed to do these things?”
They are different security decisions.
A user can:
1. Enter the correct password.
2. Complete MFA successfully.
3. Reach Microsoft's legitimate consent screen.
4. Approve a malicious app.
No MFA bypass is required.
The failure happens after authentication, when inappropriate authorisation is granted.
That makes OAuth consent phishing particularly dangerous because the interaction can look considerably more legitimate than an ordinary fake login page.
Delegated vs Application Permissions
When auditing an app, first establish what type of permissions it holds.
Delegated permissions
The application normally acts on behalf of a signed-in user.
Its effective access is generally constrained by both:
what the application has been granted
what that user is already allowed to access
Examples might include:
reading the user's calendar
accessing the user's files
reading the user's profile
Application permissions
These allow an application to operate without a user being actively signed in.
They are commonly used by:
backup platforms
automation systems
reporting services
security tools
background integrations
These permissions can be extremely powerful because the application can continue operating independently.
Microsoft warns that tenant-wide admin consent is a sensitive operation because applications can potentially receive capabilities such as broad mailbox, site or directory access across the organisation.
Why Changing the Password May Not Be Enough
This is one of the most important points in the article.
Suppose an employee approves a malicious application.
You discover it and immediately change the employee's password.
Good.
But you have not necessarily removed the permission grant itself.
Microsoft provides separate mechanisms for reviewing and revoking permissions that have been granted to enterprise applications.
So incident response needs to consider:
user identity
and:
application authorisation.
A complete response may involve:
revoking application consent
disabling/removing the enterprise application
revoking affected sessions/tokens
resetting credentials where compromise is suspected
reviewing MFA methods
investigating mailbox/file activity
A password change alone is not the whole remediation.
Start With Enterprise Applications
In the Microsoft Entra admin centre, go to:
Entra ID > Enterprise applications > All applications
This should be one of the main places you audit.
Do not review only:
App registrations
because third-party applications used by your organisation may appear as Enterprise Applications even though their underlying app registration belongs to another organisation.
An enterprise application is essentially the local service-principal representation of that application in your tenant.
For every unfamiliar application, ask:
Who approved this?
Why do we use it?
What does it have access to?
Create an Application Inventory
For each important enterprise application, record:
Area Question
Application Do we recognise it?
Publisher Who produced it?
Owner Who inside the business is responsible for it?
Permissions What can it access or change?
Consent User-specific or organisation-wide?
Users/groups Who actually uses it?
Activity Has it been used recently?
Business purpose Do we still need it?
If nobody can explain why a powerful application exists, that is already a governance problem.
Old integrations should not survive indefinitely just because:
“Nobody knows what will happen if we remove it.”
Review the Permissions
Microsoft currently documents the portal path as:
Entra ID > Enterprise apps > All applications > [application] > Permissions
You can then review:
Admin consent
and:
User consent
where applicable.
For each permission, ask three questions:
1. What exactly does this permit?
2. Why does this application require it?
3. Could a narrower permission achieve the same business outcome?
Look particularly closely at access involving:
files
SharePoint
directory information
offline access
write/modify capability
tenant-wide access
The correct security principle is:
least privilege.
Applications should receive the minimum access required to perform their legitimate function.
Look for Permission Mismatches
Some combinations should immediately provoke questions.
For example:
Calendar scheduling app → requests organisation-wide file access
Why?
PDF signing app → requests mailbox write access
Why?
Reporting tool → requests directory modification
Why?
The app may have a perfectly legitimate technical explanation.
But somebody should be able to explain it.
Do not approve permissions simply because:
“The vendor says they're required.”
Ask what each one does.
Publisher Verification Helps — but Does Not Guarantee Safety
Microsoft publisher verification is a useful trust signal.
But it does not prove that:
the application is appropriate for your business
every requested permission is necessary
the supplier cannot be compromised
the application contains no security vulnerabilities
Microsoft recommends considering the application and publisher carefully before granting organisation-wide consent.
Treat:
verified publisher
as:
one piece of evidence
rather than:
automatic approval.
An unknown or unverified publisher requesting broad Microsoft 365 access deserves much closer investigation.
Every Application Should Have an Owner
One of the simplest governance improvements is assigning a business or technical owner.
That person or team should be able to answer:
Why do we use this?
Which department needs it?
What information can it access?
What would happen if it were removed?
When was it last reviewed?
Without ownership, applications tend to accumulate indefinitely.
A project finishes.
The employee who introduced the tool leaves.
The OAuth permissions remain.
That is how tenants quietly accumulate years of unnecessary access.
Review Who Can Use the Application
Application assignment and API permissions are separate concepts.
Restricting which users can launch an application does not automatically remove API permissions already granted to its service principal.
Still, limiting user assignment can reduce unnecessary exposure.
For sensitive applications, consider:
requiring assignment
using approved groups
removing former employees
reviewing guest access
applying Conditional Access where appropriate
Microsoft recommends user assignment as one way to limit access even where broader application consent exists.
Check Sign-In and Audit Activity
An application's permissions tell you what it can do.
Its activity helps tell you what it has been doing.
Look for:
unexpected locations
unusual access volumes
dormant apps suddenly becoming active
unexpected service-principal activity
suspicious consent events
admin consent without a documented request
Entra audit logs can also help identify when application consent or service-principal changes occurred.
That is particularly important after phishing.
You want to correlate:
phishing message → user activity → consent event → application activity
rather than looking at each in isolation.
Restrict User Consent
Allowing every employee to approve every OAuth application creates unnecessary risk.
But blocking every integration without providing an alternative can create another problem:
shadow IT.
Employees may simply move outside company-approved systems.
A better approach is to configure user-consent policy so users can approve only limited, low-risk scenarios while more sensitive applications require administrator review.
Microsoft specifically recommends restricting user consent to applications from verified publishers and selected permissions where appropriate.
The aim is not:
“Nobody may ever connect an app.”
It is:
“Sensitive access requires security review.”
Use the Admin Consent Workflow
Microsoft Entra provides an admin consent workflow for applications users cannot approve themselves.
That creates a much healthier process:
User needs application
↓
User requests approval
↓
Reviewer evaluates application and permissions
↓
Approve or deny
Before approving tenant-wide access, Microsoft recommends establishing that you trust both the application and its publisher for the level of access being requested.
That review should consider:
business need
publisher
requested permissions
privacy information
security documentation
application ownership
potential impact if compromised
“Marketing needs it urgently” is not a security assessment.
Review Consent Regularly
OAuth governance is not a one-time project.
Applications change.
Permissions change.
Employees leave.
Suppliers are replaced.
Projects finish.
I would include application-consent review in a regular Microsoft 365 security cycle.
For example, review:
newly added enterprise apps
powerful permissions
unowned applications
applications with no recent activity
recent consent grants
tenant-wide admin consent
The objective is simple:
remove access that no longer has a business justification.
What to Do When You Find an Unknown Application
Do not delete every unfamiliar app immediately unless you have evidence of active compromise.
First preserve enough information to understand what it is.
Record:
application name
application/service principal ID
publisher
permissions
users/groups
creation information
recent sign-ins
consent/audit events
Then identify:
Who introduced it?
What business function does it support?
Is it still used?
An application can have an unfamiliar technical name while still being legitimate.
But if nobody can justify it, leaving it with broad access indefinitely is not a sensible default.
Responding to a Confirmed OAuth Consent Attack
If the application is clearly malicious, treat it as a security incident.
The response should typically include:
1. Contain the application
Disable access where appropriate.
2. Revoke permissions
Microsoft allows administrators to revoke tenant-wide permissions from the application's Admin consent view. User-specific grants may require Microsoft Graph or PowerShell.
3. Remove the application where appropriate
After preserving relevant evidence.
4. Revoke sessions/tokens
Particularly for affected users.
5. Reset credentials if credential theft may also have occurred
Consent phishing and credential phishing can occur together.
6. Review authentication methods
Check for unexpected:
authenticator registrations
telephone numbers
passkeys/security keys
recovery methods
7. Investigate what the application accessed
Depending on its permissions, review:
mail activity
sent messages
OneDrive
SharePoint
directory activity
8. Find the original lure
Search for the phishing email, Teams message or other method used to persuade the user to approve the app.
Blocking one malicious application without removing the original campaign may leave other employees exposed.
Revoking Consent Does Not Automatically Prevent Re-consent
This is another useful Microsoft nuance.
Microsoft explicitly warns that revoking an existing permission grant does not necessarily stop users from approving the application again if your consent policy still allows them to do so.
So after containing a malicious app, ask:
Why was this consent allowed in the first place?
Review:
user-consent policy
permission classifications
admin-consent workflow
staff awareness
security monitoring
Incident response should close the underlying route as well as remove the immediate threat.
A Useful Quarterly OAuth Audit
For many SMEs, a sensible review can be reduced to six questions:
1. Which enterprise applications have been added since the last review?
2. Which applications hold the most powerful permissions?
3. Which applications have no identified owner?
4. Which applications have not been used recently?
5. Which user/admin consent events are unexpected?
6. Does every remaining application still have a business justification?
That will catch a large proportion of tenant application sprawl without turning the review into a 200-page compliance exercise.
The Key Principle
Microsoft 365 security should not end with:
password + MFA.
You also need to control:
what applications users are permitted to trust.
An employee can have:
a unique password
strong MFA
a fully patched laptop
and still grant a malicious app access to company information.
That is why OAuth permissions deserve the same kind of lifecycle management as:
user accounts
administrator roles
devices
guest access
Know what is connected, know what it can do and remove access when it is no longer justified.
How Hamilton Group Can Help
Hamilton Group can help businesses review and secure their Microsoft 365 and Microsoft Entra environments, including:
enterprise application audits
OAuth consent reviews
Microsoft Entra ID
Microsoft 365 security
MFA
Conditional Access
app consent policies
admin consent workflows
suspicious application investigations
Microsoft Defender
account compromise response
A Microsoft 365 tenant can contain perfectly legitimate integrations that nevertheless hold extremely powerful access.
The important question is not:
“Do we recognise most of these apps?”
It is:
“Can we justify every application that still has access to our business data?”
Visit hgmssp.com or call 0330 043 0069 to discuss Microsoft 365 and cyber-security support.