Add a --device-flow flag to force Device Code Flow on CLI

[andreasgerner]

Before posting

• I searched existing discussions and issues for similar requests.
• I checked the documentation to confirm this is not already supported.
• This is a product idea or enhancement request, not a support question.
• I removed or anonymized sensitive details from examples and screenshots.

Product area

CLI

Problem or use case

Our company WAF blocks requests containing localhost as an attack vector.
As the CLI prefers PKCE authorization code flow on MacOS and Windows, the PKCE callback never completes and interactive SSO login fails.

Proposed solution

The server side already supports the OAuth 2.0 Device Authorization Grant - including with the embedded IdP (Dex), which serves both GetPKCEAuthorizationFlow and GetDeviceAuthorizationFlow. The device flow needs no localhost callback, so it would work fine in these environments.

The blocker is purely client-side flow selection:

• client/internal/auth/oauth.go shouldUseDeviceFlow(force, isUnixDesktopClient) only returns true for headless Linux/FreeBSD, or when the forceDeviceCodeFlow argument is set.
• client/cmd/login.go calls auth.NewOAuthFlow(ctx, config, isUnixRunningDesktop(), false, hint), hardcoding forceDeviceCodeFlow=false.

So a desktop user has no way to opt into device flow, even though the server offers it.
--no-browser (#3608) does not help: it only suppresses the browser launch; the underlying flow is still PKCE and the localhost callback still has to fire.

Proposal: Add a CLI flag (e.g. --device-flow / --use-device-auth) to netbird login and netbird up that passes forceDeviceCodeFlow=true into NewOAuthFlow. This appears to be a small wiring change since the device-flow code path and server support already exist.

Alternatives or workarounds considered

• Setup keys: works, but loses per-user SSO identity/attribution.
• Headless Linux enrollment: device flow is auto-selected there, but forces users off their normal desktop machine.
• --no-browser: does not change the flow; localhost callback still blocked.

Community impact and priority

• Our entire team and all other developers preferring to use Device Code flow (which may be because of our use case, but also because of other reasons)
• Would work for all CLI users regarding deployment type
• No impact on server

Examples from other tools or products

No response

Security, privacy, and compatibility considerations

No response

Implementation ideas

client/cmd/login.go (illustrative)

oAuthFlow, err := auth.NewOAuthFlow(ctx, config, isUnixRunningDesktop(), deviceFlowFlag, hint)

Are you willing to help?

Yes, I can submit a PR if the approach is accepted.

Additional context

No response

[andreasgerner]

I have implemented this idea on a fork already. An approval would lead to an instant PR from my side.

[andreasgerner]

any update on approving this? PRs are ready on both docs and client.