Not automatically. The better decision is to narrow which applications can be consented to, restrict high-risk client IDs, and review where legitimate browser-based authorisation is actually required. Blanket blocking can disrupt business workflows, but ungoverned consent paths leave a large abuse surface.
Why orgs should not default to blocking every OAuth device and consent flow
OAuth device and consent flows are not inherently phishing tools. They are mechanisms for user-granted delegated access, and in some products they are the only practical way to sign in on constrained devices or authorise legitimate SaaS integrations. The real control question is whether the application, client ID, scope set, and consent pathway are governed tightly enough to prevent abuse without breaking valid business use.
Blanket blocking treats every browser-based or device-based authorisation as equivalent, but the abuse surface is usually narrower: high-risk clients, risky consent scopes, unmanaged third-party apps, and weak consent governance. A better control strategy is to distinguish approved flows from unreviewed ones, especially where users can grant persistent access or where a token can be reused outside the intended session.
OAuth itself is a standard authorisation framework, and the device code flow is one grant type among several in RFC 6749: The OAuth 2.0 Authorization Framework. The practical issue is not that the grant exists, but that attackers can socially engineer users into approving access that looks routine. That is why consent policy, app registration governance, and token handling matter more than an across-the-board ban.
What actually makes OAuth device and consent flows risky
The risk comes from trust abuse, not from OAuth alone. Device flows can be abused when a user is asked to enter a code on a legitimate-looking page while the attacker races the victim to complete authorisation. Consent flows can be abused when a malicious or overbroad app requests access that users do not understand, then uses that approval to obtain durable access to mail, files, or SaaS data.
Microsoft verified publisher OAuth phishing 2022 shows how a trusted-looking OAuth app can still be malicious, while CoPhish OAuth phishing via Copilot Studio shows how consent workflows can be chained into token theft. The common failure mode is not weak encryption, it is over-permissive user authorisation combined with insufficient app governance and weak review of what the user is being asked to approve.
Where browser-based authorisation is legitimate, the control objective is to reduce the set of apps and scopes that can be approved, not to pretend all approvals are equally safe. Where device flow is needed, the safer pattern is to constrain it to approved clients and to make the user verify the code, the app identity, and the requested scope before approval.
RFC 9700: Best Current Practice for OAuth 2.0 Security is relevant because it reflects the modern view that OAuth deployments should reduce token theft, tighten client handling, and prefer stronger sender-constrained approaches where possible. For the same reason, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession matters when tokens might otherwise be replayed after phishing or interception.
How to decide what to block and what to govern instead
The sensible decision is to block or restrict by risk class, not by flow name. High-risk public clients, unverified apps, broad delegated scopes, and clients that request offline access or persistent tokens deserve the strongest friction. Approved internal applications, managed SaaS integrations, and workflows that truly require device sign-in may remain allowed, but only under reviewable consent rules and with clear ownership.
SaaS-to-SaaS and OAuth App Governance Guide supports the practical governance pattern: review connected apps, scope requests, and revocation paths rather than treating every consent event as equally acceptable. In the same spirit, OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful when teams need to distinguish grant types, client types, and token behaviour before deciding what should be permitted in production.
If the organisation uses human approval for machine or agent-like workflows, the consent step needs extra scrutiny because a user may not understand the downstream authority being delegated. That is where approval design, scope naming, and app inventory become part of security control, not just user experience.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API2 — Broken Authentication | OAuth abuse often exploits weak or misused authentication and consent paths |
| API5 — Broken Function Level Authorization | Overbroad consent can grant functions or data beyond intended access | |
| Recommendation — Harden auth flows and restrict clients that can obtain tokens. Restrict delegated permissions to the minimum functions each app needs. | ||
Practitioner Guidance
What to prioritise: Start with the apps and client IDs that can request persistent access, broad scopes, or access to high-value mail, file, or collaboration data. Those are usually higher value to attackers than low-impact browser sign-ins.
What to verify: Confirm that every allowed consent path has an owner, an approval standard, and a revocation process. If you cannot quickly answer who approved the app, why it was approved, and how access is removed, the control is too loose.
Decision rule: If a flow is needed for business continuity, keep it but narrow the app set and scopes. If the flow is not clearly required, remove it from the default path rather than relying on user judgement at the moment of consent.
Practitioner takeaway: The right control is selective governance, not universal prohibition, because OAuth abuse is usually enabled by excessive trust in specific apps and approvals, not by the existence of OAuth flows themselves.