Understanding OAuth Risks: From Device Code Phishing to Token Abuse

(Image generated by generative AI and reviewed under professional human supervision.)

OAuth (Open Authorisation) forms a fundamental basis of modern authentication and authorisation mechanisms, allowing users to grant applications access to specific resources without sharing their account passwords. This design greatly enhances usability and service integration, and is widely adopted across cloud platforms, enterprise collaboration tools, and various third-party services.

However, recent threat intelligence indicates that attackers are increasingly exploiting the legitimate mechanisms of OAuth to launch attacks, particularly through the abuse of access tokens, refresh tokens, and authorisation flows. These attacks do not necessarily rely on traditional credential theft, nor do they always involve fake login pages, making them more capable of bypassing conventional security controls such as phishing detection, link scanning, and multi-factor authentication (MFA).

Trends in OAuth-related Attacks

Unlike traditional phishing, OAuth-related attacks do not always focus on stealing passwords, but rather on obtaining unauthorised access through abuse of authorisation or token mechanisms.

One notable and increasingly prevalent attack technique is device code phishing. This attack exploits the device code flow, originally designed for devices with limited input capabilities, to trick victims into completing authentication on legitimate login pages, thereby allowing attackers to obtain valid access tokens. Microsoft has reported that such attacks can grant attackers tokens immediately after successful user login, and large-scale AI-assisted campaigns observed in 2026 further demonstrate how attackers leverage automation and real-time code generation to improve success rates, indicating continued evolution of this threat.

Another type of OAuth-related attack involves the abuse of redirection. Attackers redirect victims from seemingly trusted identity provider pages to infrastructure under their control, thereby bypassing conventional email and browser protections.

These developments highlight a shift in identity attacks, from traditional credential theft towards the abuse of legitimate authorisation flows and session mechanisms.

Device Code Phishing

The device code flow was originally designed for devices such as smart TVs, printers, IoT devices, and other systems with limited input capabilities. The flow requires users to open a specific webpage on another device and enter a short code to complete authentication.

In this attack scenario, the attacker initiates a legitimate device authentication request to obtain a valid code. The attacker then sends phishing messages via email or messaging platforms, tricking the victim into entering the code on a legitimate website. Once the victim completes authentication and multi-factor authentication (MFA), the attacker obtains the corresponding access token and refresh token, enabling access to the victim’s account and associated resources.

Such attacks have been observed using social engineering techniques that mimic Microsoft Teams invitations. More recent campaigns have adopted highly personalised themes, including quotation requests, invoices, and job-related communications, increasing the likelihood of user interaction. This reflects a shift from mass phishing campaigns to more structured and targeted exploitation of legitimate workflows.

Token Abuse

In a standard OAuth process, once a user successfully authenticates and grants consent, the system issues an access token and, in some cases, a refresh token, which applications use to access resources on behalf of the user.

In a token abuse attack, attackers do not necessarily steal account passwords directly. Instead, they leverage phishing, malicious applications, or manipulated consent flows to trick users into completing a legitimate authorisation process without their awareness. Once this is done, attackers can obtain valid tokens and use them to continuously access systems in the background.

For example, in a typical scenario, a user may complete authentication and multi-factor authentication through what appears to be a normal application login process. However, the authorisation request has already been pre-configured and controlled by the attacker. After authorisation is granted, the attacker can use the resulting access token to perform actions such as reading emails, downloading documents, or accessing cloud resources, without triggering further login prompts.

If the attacker also obtains a refresh token, they may continue issuing new access tokens after the original token expires, prolonging unauthorised access. As these activities occur under valid authorisation contexts, they may appear as legitimate application behaviour, making detection more challenging.

Redirection Abuse

Within OAuth authorisation flows, redirection mechanisms are used to transfer authentication results and authorisation data between identity providers and applications. After a user completes login or grants consent, they are redirected to a predefined application endpoint along with authorisation-related information.

In redirection abuse attacks, attackers exploit this legitimate mechanism to redirect victims to unintended destinations. For example, attackers may distribute phishing links that lead users to seemingly legitimate authentication pages, while triggering a series of legitimate redirections in the background.

After the user completes authentication, the system may redirect them to what appears to be a normal application page. However, the redirection chain has been manipulated, ultimately directing the victim to attacker-controlled infrastructure or delivery platforms. During this process, the user may only observe trusted pages, making the attack difficult to detect.

Such attacks may be used for further phishing activities or malware delivery, such as presenting fake enterprise portals or prompting the download of malicious files. Since parts of the process rely on legitimate authorisation mechanisms, these attacks can evade email gateways and browser security protections.

Why OAuth-related Attacks Are Harder to Detect

The danger of OAuth-related attacks lies in their exploitation of legitimate authentication and authorisation mechanisms, rather than traditional fake login pages. From a user perspective, the login interface and verification process may appear entirely legitimate, making anomalies difficult to identify. From an organisational standpoint, monitoring focused solely on password anomalies or basic MFA states may be insufficient to detect token-based attacks.

In addition, if attackers obtain valid access tokens, they can access resources within their validity period. If refresh tokens are also compromised, unauthorised access may be prolonged. Microsoft has also noted that redirection abuse campaigns can leverage seemingly legitimate authorisation flows to deliver malicious content or payloads, further increasing detection complexity.

The IETF has also highlighted in RFC 9700 that the latest best current practices for OAuth 2.0 security expand the threat model and deprecate certain less secure implementation patterns.

Impact

Based on official documentation and public research, the risks posed by OAuth-related attacks should not be viewed as isolated authentication events. If attackers successfully obtain tokens or abuse authorisation flows, the impact may extend to email, documents, cloud services, and other protected resources, potentially affecting business processes and data security.

For organisations, these risks highlight that identity protection should not rely solely on password and basic MFA management. Instead, it should incorporate token governance, authorisation activity monitoring, application consent management, and secure OAuth implementation practices to more effectively mitigate modern identity threats.

Security Recommendations

1. Restrict or block device code flow

If there is no clear business requirement, organisations should consider restricting or blocking device code flow by using Conditional Access. Microsoft documentation states that device code flow is a higher-risk authentication method that can be used in phishing attacks or to access corporate resources from unmanaged devices. Where its use is genuinely necessary, it should be limited to clearly defined and controlled scenarios.

2. Use Report-only mode before enforcing blocking policies

Microsoft recommends that organisations first use Report-only mode to assess the impact before turning a blocking policy on. This helps identify any legitimate scenarios that still depend on device code flow. Exception lists, such as emergency access or break-glass accounts, should also be managed carefully and reviewed regularly.

3. Strengthen monitoring of sign-ins that use device code flow

Organisations should treat sign-ins that use device code flow as a high-value monitoring signal and review unusual IP addresses, suspicious geographic locations, abnormal sign-in patterns and subsequent token usage. Microsoft has reported that attackers can use this method to obtain valid access tokens and refresh tokens, allowing continued access to compromised accounts and related resources.

4. Tighten application consent and approval governance

Because OAuth attacks can involve malicious applications or manipulated authorisation flows, organisations should review how application consent and approvals are managed. Users should not be able to grant high-risk or unnecessary third-party applications access to enterprise resources without appropriate oversight. Higher-privilege consent requests should be subject to stricter approval and governance measures.

5. Strengthen token governance and apply least privilege

The security risk posed by OAuth does not end at sign-in. Once a token is abused, an attacker may continue to access resources without needing to enter a password again. Organisations should treat token governance as part of their identity protection strategy and apply the principle of least privilege by limiting token permissions, scope and accessible resources wherever possible.

6. Prefer more secure OAuth implementation practices

According to Microsoft and the IETF’s latest security guidance, organisations should prefer stronger OAuth implementation choices and safeguards. For example, Microsoft recommends the authorisation code flow with PKCE for relevant application types, while the IETF’s current best practice for OAuth 2.0 states that some older or less secure operating modes are no longer recommended.

7. Review redirect settings and related authorisation activity

Microsoft research published in 2026 shows that attackers can abuse OAuth’s legitimate redirection behaviour to move victims from a trusted identity provider page to attacker-controlled infrastructure. Organisations should therefore review OAuth-related application settings, redirect arrangements and abnormal authorisation activity to reduce the risk of phishing and malware delivery disguised within legitimate flows.

8. Improve staff awareness of authorisation-based phishing

Organisations should strengthen staff awareness of device code phishing and other OAuth-related authorisation phishing techniques. Staff should be reminded not to lower their guard simply because they see an official sign-in page, and not to enter verification codes provided by third parties or authorise unknown applications without proper verification. Users should understand that a genuine sign-in page does not automatically mean that the overall process is safe.

Reference Links:

• Microsoft Security Blog：Storm-2372 conducts device code phishing campaign [Microsoft]
• Microsoft Security Blog：Inside an AI-enabled device code phishing campaign [Microsoft]
• Microsoft Security Blog：OAuth redirection abuse enables phishing and malware delivery [Microsoft]
• Microsoft Learn：Authentication flows as a condition in Conditional Access policy [Microsoft Learn]
• Microsoft Learn：Block authentication flows with Conditional Access policy [Microsoft Learn]
• Microsoft Learn：Microsoft identity platform and the OAuth 2.0 device authorization grant flow [Microsoft Learn]
• IETF Datatracker：RFC 9700 - Best Current Practice for OAuth 2.0 Security [IETF]