What is malicious OAuth access?¶
Malicious OAuth access is the unauthorised or deceptive use of permissions granted to an application. OAuth is the authority mechanism, not the verdict: the application may have been deceptive from the start, later compromised, over-permissioned or misused by an operator.
The application can act after Dave leaves¶
Dave connects Northstar Rota Helper to Microsoft 365 and grants delegated Mail.Read permission. At 09:12 he closes the helper. At 11:46, Microsoft Graph records a request associated with application ID APP-91D4 and Dave's delegated authority.
That request should not automatically be described as Dave reading the message at 11:46. OAuth lets an application present a token representing approved authority, including in some configurations when the user is no longer interacting with it.
Read the authority at the correct scope¶
Preserve the client/application and service-principal identifiers, publisher, tenant (the organisation's cloud environment), consenting actor, delegated or application permission, resource or audience, token timing, request identifier and target object. Permission names may distinguish reading from modification or a single user's authority from organisation-wide access.
The next comparison is between the stated purpose, the approved scope and actual behaviour. Application-host logs, infrastructure records, change history and provider resource events may distinguish a legitimate integration, a compromised application and an intentionally abusive one.
Consent phishing explains one deceptive route into the grant. This card answers the next question: what did the application do with the authority? Application consent and delegation supplies the wider mechanism.
Current Microsoft Entra example - checked 2 September 2026
Microsoft Entra currently records user consent, delegated permission grants and app-role assignments in application activity logs. Microsoft uses Consent to application, Add delegated permission grant and Add app role assignment to service principal for distinct grant scenarios, and recommends correlating permission records with application and user sign-in activity.
Product fields and permission strings are provider-specific. Export the contemporary record and retain the permission definition rather than relying on a dashboard summary.
The durable principle¶
OAuth separates a person's password from an application's continuing authority. The grant explains what the application could do; resource events explain what it did; application-control evidence addresses who caused that behaviour.
The point to remember
Do not translate delegated application activity into a fresh human action. Join the grant, token context, resource event and application-control evidence.
