Notifications
Clear all
Topic starter
15/08/2026 6:07 pm
TL;DR: Consent phishing abuses OAuth 2.0 delegated authorisation by getting users to approve malicious apps, then using legitimate tokens for standing access, according to SlashID. MFA still works, but the real failure is that organisations often treat authentication as the control boundary when the abuse happens after sign-in.
NHIMG editorial — based on content published by SlashID: consent phishing, OAuth token theft, and CoPhish workflow abuse
By the numbers:
- NHIs outnumber human identities by 25x to 50x in modern enterprises.
- Only 5.7% of organisations have full visibility into their service accounts.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
Questions worth separating out
Q: How should security teams govern OAuth 2.0 in enterprise environments?
A: Security teams should govern OAuth 2.0 as a delegated access model with lifecycle controls.
Q: Why do AiTM phishing kits still succeed against MFA?
A: AiTM kits succeed because they capture the authenticated session, not just the password.
Q: What breaks when organisations only monitor sign-in events and ignore consent grants?
A: They miss the event that actually creates delegated access.
Practitioner guidance
- Inventory all OAuth apps and service principals Map every app that can request delegated access, especially those with mail, files, chat, offline_access, or admin-consent scopes.
- Restrict application registration and user consent Remove broad user consent where possible, require admin approval for sensitive scopes, and monitor tenant settings that let ordinary users register applications.
- Revoke grants, not just sessions Build a revocation workflow that disables the service principal, removes the OAuth grant, rotates any exposed credentials, and terminates active sessions when suspicious consent is detected.
What's in the full article
SlashID's full research covers the operational detail this post intentionally leaves for the source:
- The full consent-phishing chain from authorize request to token exchange, including the scopes and token types involved.
- The Copilot Studio abuse path, including editable system topics and the post-auth HTTP Request action.
- Detection and remediation workflows for suspicious grants, risky service principals, and active token abuse.
- Operational guidance on how browser extension visibility can surface dangerous OAuth approvals before tokens are misused.
👉 Read SlashID's analysis of OAuth consent phishing and token abuse →
Consent phishing and OAuth tokens: where IAM controls fail?
Explore further
15/08/2026 6:15 pm
Consent is not a side effect of authentication, it is an identity control point. OAuth abuse works because many programmes treat the login event as the end of security review. In reality, the approval of a third-party application is a separate governance decision that can create standing delegated access. IAM teams that do not review consent flows, app registration privileges, and scope grants are leaving a parallel access path outside normal certification.
A few things that frame the scale:
- NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a malicious OAuth application is approved by a user?
A: Accountability sits with the organisation that allowed user-granted access to sensitive scopes without sufficient policy control, review, or monitoring. The user made the click, but the governance model defined the blast radius. Security, IAM, and application owners all need clear ownership for approval policy and token revocation.
👉 Read our full editorial: Consent phishing exposes the authorization gap in OAuth identity models
