Notifications
Clear all
Topic starter
06/06/2026 2:34 am
TL;DR: Consent phishing turns legitimate OAuth consent prompts into persistent token-based access without stealing passwords, because users can approve scopes on the real identity provider and attackers then hold refresh tokens, according to WorkOS. The weak point is governance, not authentication: access review and password resets do not address delegated grants that outlive the session.
NHIMG editorial — based on content published by WorkOS: OAuth governance and consent phishing
By the numbers:
- 17 minutes, redentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams reduce consent phishing risk in OAuth environments?
A: Security teams should restrict end-user consent, require admin approval for sensitive scopes, and monitor new grants as high-value access events.
Q: Why do OAuth grants create more risk than many teams realise?
A: OAuth grants can outlive the original login and keep working through refresh tokens even after a password changes.
Q: What do security teams get wrong about consent phishing?
A: They often treat it like ordinary phishing and focus on user awareness or credential resets.
Practitioner guidance
- Restrict user consent by default Block broad end-user OAuth approvals and allow only tightly defined low-risk scopes, with admin workflow for anything sensitive or unverified.
- Inventory existing OAuth grants now Audit current grants for broad scopes, unverified publishers, stale refresh tokens, and user-granted apps that no longer have a business owner.
- Monitor consent events as security signals Alert on new grants for sensitive permissions, especially when a consent event follows delivery of a phishing message or unusual sign-in pattern.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step consent policy settings for Microsoft Entra ID and Google Workspace.
- Specific Graph API and admin console paths for auditing existing grants and refresh tokens.
- Detection logic examples for new OAuth grants and suspicious scope combinations.
- Incident response actions for revoking malicious app consent and token access.
👉 Read WorkOS's analysis of OAuth governance and consent phishing →
OAuth consent phishing: what IAM teams need to tighten now?
Explore further
06/06/2026 4:19 am
OAuth consent is an access control decision, not a user convenience feature. The article makes clear that the real control boundary sits at the consent prompt, where a user authorizes scopes on behalf of the organisation. That means delegated access governance belongs in identity policy, not in ad hoc user judgement. Teams that still treat consent as a low-risk productivity action are leaving persistent access outside their review model. Practitioners should manage consent with the same seriousness as privileged access.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
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: OAuth consent phishing exposes the governance gap in identity
