Look for excessive polling, repeated expired or denied authorisations, users entering codes into unexpected pages, and tokens persisting beyond the task that requested them. Those signals usually point to weak approval hygiene, poor client behaviour, or token handling that outlives the session.
What a device code flow should look like when it is behaving normally
device code flow is designed for constrained devices and CLI-style sign-in, so the healthy pattern is short-lived, user-driven approval followed by a clean token handoff. The device should ask for consent once, the user should complete approval on a separate browser page, and the CLI should stop prompting as soon as the authorization state changes.
A normal flow has a narrow window between code issuance and approval, limited polling, and tokens that are tied to the task that requested them. OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful here because it explains the device code grant, token handling, and the approval mechanics that make the flow work safely.
When the flow is healthy, you should not see repeated approval attempts for the same device, users should not be asked to re-enter the code after a successful grant, and tokens should not linger once the CLI session or job is over. That baseline matters because the signs of misuse are usually deviations from this rhythm, not a single failed login.
Behaviour patterns that point to misuse
The clearest warning sign is polling behaviour that looks machine-driven rather than user-driven. Excessive token polling, fast retries after denial, or loops that continue long after the user should have been able to approve the request suggest the client is ignoring normal backoff or trying to brute-force a consent state.
Another signal is approval friction that does not match a legitimate user journey. Repeated expired or denied authorisations, codes that are entered into an unexpected page, or instructions that push the user to a site that does not clearly belong to the requesting application all point to approval hygiene problems or social engineering. NIST SP 800-63 Digital Identity Guidelines is relevant because it reinforces the importance of phishing-resistant, user-verifiable authentication journeys rather than ambiguous approval steps.
A third pattern is token behaviour that outlives the task. If access tokens, refresh tokens, or session artifacts remain valid after the requested CLI operation is finished, or if the same token appears to service unrelated actions, the flow may be being abused as a persistence path rather than a one-time delegation step. That is especially suspicious when the CLI is supposed to be ephemeral or single-purpose.
How misuse changes the security posture
Misuse of device code flow is not just a usability problem, because it can become an access path that survives beyond the intended interaction. A weak client can turn approval into a waiting room for abuse: the attacker gains time to keep polling, the user becomes habituated to approving prompts, and the resulting token can be reused for actions that were never part of the original task.
The practical risk is a combination of authorization drift and token abuse. RFC 8693: OAuth 2.0 Token Exchange helps frame the issue because it distinguishes delegated access from uncontrolled token reuse, which is exactly where misuse becomes dangerous. If the CLI can keep or exchange tokens beyond the approved scope, the original approval no longer bounds the resulting access.
That is why persistent tokens, unexpected approval destinations, and abnormal retry patterns should be treated as indicators of access-path weakness, not just client bugs. The same signals can also indicate that a device flow is being used to bypass normal login controls, especially when the client is headless, scripted, or operating at scale.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Device code flow signs depend on user-verifiable authentication and phishing resistance. |
| Recommendation — Require a user-verifiable approval journey and reject ambiguous authorization prompts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token persistence and misuse are lifecycle issues for authenticators and delegated access material. |
| Recommendation — Enforce token expiry, rotation, and revocation when the device task ends. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Abnormal polling and token reuse can indicate broken authentication handling in the device flow. |
| Recommendation — Validate the device flow authentication state and block repeated unauthorised token attempts. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | CLI device flows can leak or retain tokens beyond the intended approval window. |
| NHI-07 — Long-Lived Secrets | Tokens persisting after the task finishes are a long-lived secret risk. | |
| Recommendation — Rotate or revoke tokens immediately when they are exposed or persist beyond the job. Shorten token lifetimes and bind them to the minimum necessary task duration. | ||
Practitioner Guidance
What to prioritise: Treat polling frequency, token lifetime, and approval destination as the three highest-value signals. If any one of them looks wrong, investigate the whole flow rather than the single request.
What to verify: Confirm that the user-facing approval page matches the expected issuer, that the CLI stops polling promptly after success or denial, and that tokens are scoped to the specific operation rather than a broader session.
Common mistake: Teams often focus on whether the user “approved” the request and miss the more important question of whether the approval path and token handling were bounded tightly enough to prevent reuse, replay, or prompt abuse.
Practitioner takeaway: In device code flow, the sign of misuse is usually not a failed grant, it is a flow that keeps asking for trust after the legitimate user interaction should already be over.
Related resources from NHI Mgmt Group
- What are the signs that device flow is the wrong default for a CLI?
- What breaks when device code login is treated like a normal CLI convenience feature?
- How should security teams choose between API keys, Device Flow, and Client Credentials for CLI apps?
- How can organisations decide whether device flow is appropriate for a CLI application?