OAuth Consent Attacks: Auditing Which Apps Have Access to Your Tenant

Passwords and multi-factor authentication are not the only ways an attacker can gain access to Microsoft 365.

An attacker may instead persuade a user or administrator to approve a malicious application. Once consent is granted, that application can receive permissions to read email, access files, view contacts or perform other actions through Microsoft Graph and connected services.

This technique is known as an OAuth consent attack, consent phishing or an illicit consent grant.

The user may never reveal their password. MFA may work correctly. The attacker gains access because the victim authorises the application through a genuine Microsoft consent screen.

That makes application permissions an essential part of every Microsoft Entra security review.

What Is OAuth Consent?

OAuth allows an application to access a protected service without receiving the user’s password directly.

For example, a legitimate application might request permission to:

• Read a user’s calendar
• Create meetings
• Access selected files
• Send an email
• View profile information

Microsoft Entra displays a consent prompt explaining the permissions requested. When the user or administrator approves it, the application receives authorisation to access the relevant resources. 

This model supports thousands of useful business integrations, but it also creates a security risk when the application is malicious, compromised or given more access than it genuinely requires.

What Is an OAuth Consent Attack?

An OAuth consent attack occurs when a threat actor tricks someone into granting permissions to an attacker-controlled application.

A typical attack works like this:

1. The attacker registers an application.
2. The application requests access to Microsoft 365 data.
3. The victim receives a phishing message or misleading link.
4. The victim opens Microsoft’s genuine sign-in and consent process.
5. The consent page lists the requested permissions.
6. The victim selects Accept.
7. The application receives an access or refresh token.
8. The attacker uses the application to access permitted resources.

Microsoft recommends treating suspicious consent grants as a potential identity compromise and investigating both the application and the account that authorised it. 

Why MFA May Not Stop a Consent Attack

MFA protects the sign-in process.

It does not automatically determine whether an application deserves the permissions the user grants afterward.

The user may:

• Enter the correct password
• Complete legitimate MFA
• See a real Microsoft consent screen
• Approve the requested permissions

The authentication succeeds because the real user completed it. The security failure occurs when the user authorises an unsafe application.

This is why businesses need controls covering both:

• Authentication: Who is signing in?
• Authorisation: What is the application allowed to do?

Delegated Permissions vs. Application Permissions

Understanding the permission type is essential when auditing applications.

Delegated Permissions

Delegated permissions allow an application to act on behalf of a signed-in user.

The application is generally limited by:

• The permissions granted to the app
• The permissions already held by the user
• Applicable access policies

Examples might include reading the signed-in user’s profile or accessing their files.

Application Permissions

Application permissions allow an application to operate without a signed-in user.

These are commonly used by:

• Background services
• Automated integrations
• Backup tools
• Reporting systems
• Security platforms

Application permissions can be especially powerful because the app may access data across the organisation continuously and without user interaction.

High-impact application permissions normally require administrator consent. Microsoft recommends reviewing tenant-wide consent carefully because it can authorise access on behalf of the entire organisation. 

Why OAuth Access Can Outlive a Password Reset

A password reset changes the user’s password.

It does not necessarily remove every application permission that the user or an administrator previously granted.

Depending on the application, token state and remediation performed, the app may retain authorised access until:

• The consent grant is revoked
• The application is disabled
• Tokens are revoked or expire
• The service principal is removed
• The relevant credentials are invalidated

This is why responding to an OAuth consent attack requires more than changing the user’s password. Microsoft’s incident-response guidance includes reviewing and revoking suspicious consent grants and investigating related application activity. 

What Could a Malicious App Access?

The impact depends entirely on the permissions granted.

A malicious application may be able to:

• Read email
• Send email
• Access OneDrive files
• Access SharePoint content
• Read calendars
• View contacts
• Read directory information
• Change mailbox settings
• Maintain offline access
• Access data without a user being actively signed in

Permissions involving mail, files, directory data or offline access deserve particular attention.

The Microsoft Graph permissions reference should be used to confirm precisely what each permission allows and whether administrator consent is required. 

Warning Signs of a Suspicious OAuth Application

Investigate applications with one or more of these characteristics:

• The publisher is unknown.
• The application was added recently.
• Nobody can identify a business owner.
• The name imitates Microsoft or another trusted service.
• The application requests broad permissions.
• The permissions are unrelated to its stated purpose.
• It requests offline access without a clear reason.
• It asks to read or send email.
• It requests organisation-wide file access.
• It has not been used recently.
• It was approved after a suspicious email.
• Its sign-in activity comes from unusual locations.
• It uses newly created or unexpected credentials.

Microsoft’s app-governance detections can flag OAuth applications with suspicious permission combinations, unusual behaviour or risky publisher characteristics. 

Where to Find Enterprise Applications

In the Microsoft Entra admin centre:

1. Open Microsoft Entra ID.
2. Select Enterprise applications.
3. Open All applications.
4. Review the application list.
5. Select an application to inspect its properties, owners, permissions, users and sign-in activity.

An enterprise application is the service principal representing an application inside your tenant.

Do not review only App registrations. Third-party applications used in your tenant may appear as enterprise applications even when the underlying app registration belongs to another organisation.

Start With an Application Inventory

Export or document the applications in your tenant.

For each application, record:

An unexplained application should not remain trusted simply because it has existed for several years.

Review the Application’s Permissions

To inspect an application in the Entra admin centre:

1. Open Enterprise applications.
2. Select the application.
3. Open Permissions.
4. Review the Admin consent and User consent tabs where available.
5. Record each resource and permission.
6. Determine whether the app genuinely needs that access.

The admin-consent view shows permissions applying across the tenant, while user-consent details show permissions granted for particular users or groups. 

Ask three questions for every permission:

1. What exactly does this permission allow?
2. Why does the application require it?
3. Could a narrower permission achieve the same result?

Look for Excessive Permissions

An application should receive only the minimum access required for its purpose.

Examples of questionable combinations include:

• A simple calendar tool requesting access to all files
• A document-signing application requesting mailbox write access
• A reporting tool requesting directory modification permissions
• A single-user utility receiving tenant-wide administrator consent
• An application retaining broad permissions after a project ended

Permissions may have been reasonable when originally granted but become unnecessary after the application changes.

Review permissions after:

• Application upgrades
• Supplier changes
• Mergers
• Project completion
• Security incidents
• Permission-scope changes
• Administrator departures

Check Publisher Verification

Publisher verification can help confirm that an application is associated with a verified Microsoft partner identity.

However, verification does not prove that:

• The application is appropriate for your business
• The requested permissions are necessary
• The supplier cannot be compromised
• The app is free from security flaws

Treat verification as one trust signal rather than an automatic approval.

An unverified application requesting sensitive access should receive much closer examination.

Review Application Owners

Every approved enterprise application should have a documented owner.

The owner should be able to explain:

• Why the application exists
• Which department uses it
• Which data it accesses
• Which permissions it requires
• Who supports it
• When it should be reviewed
• What happens if it is removed

Applications without owners tend to remain in tenants indefinitely because nobody feels authorised to remove them.

Avoid assigning ownership exclusively to one employee. Use an appropriate team or maintain at least two responsible owners for important applications.

Review Users and Groups

Check who can access the application.

When user assignment required is disabled, any eligible user may be able to access the application, subject to other policies.

For sensitive applications, consider:

• Requiring assignment
• Assigning approved security groups
• Removing former employees and contractors
• Reviewing guest access
• Applying Conditional Access
• Scheduling access reviews where supported

Application assignment and API permission are different controls. Limiting who can launch an application does not automatically reduce the API access already granted to the service principal.

Review Sign-In Activity

Check application sign-ins for:

• Recent usage
• Unexpected countries
• Unfamiliar IP addresses
• Unusual volumes
• Access outside normal hours
• Dormant applications suddenly becoming active
• Authentication from unexpected clients
• Failures followed by successful access

Microsoft’s security operations guidance recommends monitoring application activity because service principals often run without direct human interaction and can be harder to detect when compromised. 

An unused application with powerful permissions should normally be removed or disabled rather than left available indefinitely.

Review the Audit Logs for Consent Events

Microsoft Entra audit logs record changes to identities and applications, including consent-related activity.

In the Entra admin centre:

1. Open Monitoring & health.
2. Select Audit logs.
3. Filter the activity for consent-related events.
4. Look for activities such as Consent to application.
5. Open the event.
6. Review the initiating user, target application and modified properties.
7. Record the permissions granted.

Microsoft’s investigation guidance recommends reviewing Consent to application events and examining the recorded permission values to identify suspicious grants. 

Look for:

• Consent by unexpected users
• Consent outside normal hours
• Broad permissions
• Consent immediately following phishing activity
• Repeated consent attempts
• Consent to newly created applications
• Administrator consent without a documented request

Search Microsoft Purview Audit

Microsoft Purview Audit can provide additional evidence of consent activity across Microsoft 365.

Search for operations associated with application consent and correlate them with:

• Email delivery
• User sign-ins
• Application creation
• Service-principal creation
• Mailbox activity
• File access
• Administrative changes

Microsoft specifically recommends searching the audit log for suspicious Consent to application events when investigating illicit consent grants. 

Log retention depends on licensing and configuration, so export important evidence promptly during an investigation.

Review Service-Principal Creation

When an external application first becomes available in the tenant, Microsoft Entra creates a service principal representing that application.

Review unexpected Add service principal events.

Microsoft added audit information that can help administrators understand why a service principal was created and which action caused it to appear in the tenant. 

Investigate when:

• No administrator recognises the application
• It appeared alongside a suspicious consent event
• It immediately received powerful permissions
• It was created by an unexpected account
• It has no owner or business justification

Restrict User Consent

Allowing every user to approve any application creates unnecessary risk.

Microsoft Entra provides user-consent settings that control when users may grant permissions to applications. 

A safer configuration may allow users to consent only when:

• The application is from a verified publisher
• The requested permissions are classified as low impact
• The permission set is approved by the organisation
• The user and application meet defined conditions

Applications outside those boundaries should go through an administrator approval process.

The objective is not necessarily to prohibit every integration. It is to prevent users from granting broad access without security review.

Configure Permission Classifications

Microsoft Entra allows administrators to classify selected delegated permissions as low impact.

This can help create a user-consent policy where users may approve limited, low-risk permissions while requests involving sensitive access require administrator review.

Treat classifications carefully.

A permission that appears low risk in isolation may become more significant when combined with other permissions or used by an untrusted application.

Review classifications regularly rather than accepting default assumptions indefinitely.

Use the Admin Consent Workflow

Blocking user consent entirely can create a new problem: employees may use unsanctioned applications outside the company identity system.

The admin consent workflow lets users request approval for applications they cannot consent to directly.

A controlled process can:

1. Block unauthorised consent.
2. Allow the user to submit an approval request.
3. Notify assigned reviewers.
4. Let a qualified administrator inspect the app and permissions.
5. Approve or deny the request.
6. Preserve a record of the decision.

Microsoft Entra supports configuring reviewers and request-expiry settings through the admin consent workflow. Reviewers still need the administrative permissions required to grant consent; being listed as a reviewer does not automatically provide that authority. 

Review Admin Consent Requests Properly

Before approving an application, verify:

• The requester
• Business need
• Publisher
• Application homepage
• Privacy policy
• Terms of service
• Redirect domains
• Requested permissions
• Data residency
• Security documentation
• Contractual controls
• Supplier contact
• Application owner

Microsoft provides a review process for pending admin-consent requests, including inspection of the application and requested permissions before approval or denial. 

Do not approve an application merely because the user says it is urgent.

Apply Conditional Access to Applications

Conditional Access can reduce the risk associated with approved enterprise applications.

Depending on the application and licensing, policies may require:

• MFA
• Phishing-resistant authentication
• Compliant devices
• Approved applications
• Trusted network conditions
• Session restrictions
• Additional controls for administrators

Conditional Access does not make excessive API permissions safe, but it can control how users access the application.

Machine-to-machine application activity requires separate workload-identity controls and monitoring.

Use App Governance Where Available

Microsoft Defender for Cloud Apps app governance can help organisations:

• Inventory OAuth applications
• Review permission levels
• Identify suspicious behaviour
• Detect anomalous activity
• Create app policies
• Disable or investigate risky applications

Microsoft provides templates and custom app-governance policies for monitoring OAuth applications connected to supported services. 

App governance complements—not replaces—manual ownership, permission reviews and consent controls.

What to Do When You Find an Unknown App

Do not immediately delete it without understanding the business impact, unless active compromise requires urgent containment.

First:

1. Record the application name and ID.
2. Capture the publisher and creation information.
3. Review permissions.
4. Review users and groups.
5. Review sign-ins.
6. Review audit and consent events.
7. Identify the owner or requesting user.
8. Check whether the supplier and business purpose are legitimate.
9. Determine whether the application is actively accessing data.

When the app cannot be justified, disable or remove its access through a controlled process.

For a clearly malicious application, containment should take priority over business convenience.

Responding to a Confirmed Consent Attack

Treat a malicious consent grant as an account and application compromise.

Disable the Application

Prevent further sign-in or token use where possible.

Revoke Consent

Remove delegated and tenant-wide permissions granted to the application.

Microsoft documents using Microsoft Graph and PowerShell to review and revoke application permissions where necessary. 

Remove the Service Principal

When the application has no legitimate tenant use, remove its enterprise application object after preserving required evidence.

Revoke Sessions and Tokens

Revoke relevant user sessions and refresh tokens.

Reset Credentials

Reset the affected user’s password when credential compromise is possible.

Review Authentication Methods

Check for newly added:

• Authenticator registrations
• Phone numbers
• Passkeys
• Security keys
• Temporary access methods

Review Mailbox and File Activity

Look for:

• Mail read or sent
• Inbox rules
• Forwarding
• OneDrive downloads
• SharePoint access
• External sharing
• Deleted content

Investigate Other Users

Search for additional users who granted consent to the same application or opened the original phishing message.

Preserve Evidence

Retain:

• Consent logs
• Application details
• Permission lists
• Sign-in events
• IP addresses
• Email messages
• Audit events
• Token and session information

Microsoft’s incident-response playbook recommends identifying the consenting account, application permissions, related service principals and subsequent resource activity. 

Do Not Rely Only on Deleting the Application

Removing the enterprise application may stop its normal access, but the incident may have caused additional damage.

The attacker may already have:

• Downloaded files
• Read sensitive email
• Sent phishing messages
• Learned internal contacts
• Added another authentication method
• Created mailbox rules
• Targeted other employees
• Exfiltrated data

Complete the wider account and data investigation.

How Often Should You Audit OAuth Applications?

There is no single frequency suitable for every organisation.

A practical approach is:

• Monthly: Review new applications and consent grants.
• Quarterly: Review high-permission and tenant-wide applications.
• Annually: Complete a full inventory and ownership review.
• Immediately: Review after suspicious sign-ins, phishing reports or supplier incidents.

High-risk applications should be reviewed more often.

Also trigger a review when:

• An application owner leaves
• A supplier is acquired
• A contract ends
• Permissions change
• The app becomes inactive
• A security advisory affects the supplier

A Practical OAuth Application Audit Checklist

Inventory

• Export all enterprise applications.
• Identify recently added applications.
• Identify applications without owners.
• Identify inactive applications.
• Identify applications assigned to all users.

Permissions

• Review delegated permissions.
• Review application permissions.
• Review tenant-wide admin consent.
• Identify mail, file and directory access.
• Check offline-access permission.
• Remove unnecessary permissions.

Trust

• Verify the publisher.
• Confirm the business owner.
• Review supplier documentation.
• Confirm redirect domains.
• Confirm that the app is still supported.

Activity

• Review sign-in activity.
• Review consent audit events.
• Review service-principal creation.
• Review credential additions.
• Investigate unexpected locations and volumes.

Controls

• Restrict user consent.
• Configure permission classifications.
• Enable admin consent requests.
• Apply Conditional Access.
• Use app governance where licensed.
• Alert on high-risk application changes.

Removal

• Disable unused apps.
• Revoke unnecessary consent.
• Remove obsolete service principals.
• Revoke sessions after compromise.
• Document all actions.

Common OAuth Security Mistakes

Allowing Users to Consent to Any App

One successful phishing message can create persistent data access.

Approving Every Admin Consent Request

The workflow becomes a rubber stamp rather than a security control.

Trusting Verified Publishers Automatically

Verification is helpful, but it does not prove the requested access is appropriate.

Reviewing Only App Registrations

Third-party applications may exist only as enterprise applications in your tenant.

Ignoring Delegated Permissions

Delegated applications can still access sensitive information on behalf of users.

Ignoring Application Permissions

App-only access can operate continuously without an interactive user.

Leaving Inactive Apps Enabled

Dormant access provides risk without business value.

Resetting the Password but Not Revoking Consent

The malicious application may retain authorised access.

Having No Application Owners

Nobody accepts responsibility for reviewing or removing the integration.

Granting Broad Permissions for Convenience

Excess privilege increases the impact of supplier compromise and application abuse.

Final Thoughts

OAuth makes modern cloud applications more useful by allowing them to access Microsoft 365 data without handling user passwords directly.

That same flexibility can be abused.

In an OAuth consent attack, the attacker may not need to steal the password or bypass MFA. The victim signs in legitimately and grants the malicious application access themselves.

Your defence should therefore extend beyond user authentication.

Maintain an inventory of enterprise applications. Review delegated and application permissions. Restrict user consent. Introduce a controlled admin-consent workflow. Monitor new service principals and consent events. Remove applications that no longer have a clear owner or business purpose.

When malicious consent is discovered, do not stop at a password reset. Revoke the application’s permissions, disable or remove the service principal, revoke affected sessions and investigate what data the application accessed.

Every application with tenant access should have a reason, an owner and the minimum permissions necessary.

Anything else is unnecessary exposure.

Unsure Which Applications Can Access Your Microsoft 365 Tenant?

Hamilton Group can help you audit Microsoft Entra enterprise applications and OAuth permissions.

Our experts can help you:

• Inventory enterprise applications
• Review delegated and application permissions
• Identify excessive or suspicious access
• Configure user-consent restrictions
• Implement an admin consent workflow
• Review publisher and application trust
• Investigate illicit consent grants
• Configure Microsoft Defender app governance
• Remove obsolete enterprise applications
• Strengthen Conditional Access
• Build an OAuth incident-response process

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to review which applications have access to your Microsoft 365 environment.