Dev.to Security πŸ” Cybersecurity πŸ‘ 1 πŸ“– 1 min read

Stop Spawning Localhost Servers From Your CLI

Most CLIs still ship a broken login flow. When you run gcloud auth login, wrangler login, or claude on a fresh dev box, the CLI binds an HTTP server on localhost, opens your browser, and waits for a redirect. Works fine

Most CLIs still ship a broken login flow.

When you run gcloud auth login, wrangler login, or claude on a fresh dev box, the CLI binds an HTTP server on localhost, opens your browser, and waits for a redirect. Works fine on a laptop. The moment you SSH into a server or jump into a container, the whole thing falls over. The "paste this code" escape hatch every one of them ships is a manual device flow in disguise. It exists because the real flow does not work where the CLI is actually being used.

RFC 8628, the OAuth 2.0 Device Authorization Grant, fixed this back in 2019. The CLI prints a short code, you authenticate on whatever device you want, and the CLI polls the token endpoint until you approve. Same code path on a laptop, on a server, in a container, in a CI job that pauses for a human to approve. gh, aws sso, and Vercel already default to it. Google's gcloud, Cloudflare's wrangler, and Anthropic's own claude still don't.

The escape hatch is the tell. If the "real" flow needs a manual paste-the-code fallback every time the CLI leaves a laptop, the real flow is the fallback.

Originally published on abgeo.dev: https://www.abgeo.dev/blog/cli-authentication-the-right-way/

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.