Should we consider device tokens?

[shadowbrush]

I just did atlas auth login, which is MongoDB Atlas' login. It requires me to enter a token into the website.

Is this safer than our OAuth login? If so, should we switch? What is best-practice today?

[shadowbrush]

Short answer: the Atlas-style device-token flow isn't inherently more secure than what we do — it's a UX trade-off for input-constrained devices, and OAuth already has a standard for it.

What Atlas does is the OAuth 2.0 Device Authorization Grant (RFC 8628): the CLI shows a short code + URL, you approve in a browser on any device, and the CLI polls for the token. It exists so devices with no browser or no keyboard (TVs, servers, SSH sessions) can still auth. Its security properties are essentially the same as the standard Authorization Code + PKCE flow — the browser is still the trust anchor.

How that compares to us: our hadron auth login uses authContext / an OAuth code flow with the token stored via the OS token store (internal/auth/store). That's the recommended flow for a CLI that can pop a local browser. The device grant is not an upgrade over PKCE; it's the fallback for when you can't.

Where the device grant would genuinely help us is the headless case — CI, a remote box over SSH, a container — where there's no local browser to redirect to. Today the answer there is HADRON_TOKEN (a pre-minted token), which works but means a long-lived secret is copied around.

Recommendation: keep the current browser/PKCE flow as the default (it's best-practice for an interactive CLI), and consider adding the device grant as a --device / headless fallback if and when hadron-server exposes the device-authorization endpoints. It's a real ergonomics win for SSH/CI, not a security fix. No change to the default login is warranted.

I'll leave this open as the decision record — flip it to a feat(auth): device-grant fallback issue if we want to pursue the headless path (it'd pair well with #64 headless chat and #65 CI usage flows).