CLI 인증, 왜 아직도 2009년 방식인가?

논의에서는 SSH 세션, 컨테이너 환경 등 브라우저가 없는 호스트(Browserless Host)에서 CLI 인증 시 발생하는 문제를 집중적으로 다룬다. CLI가 로컬 루프백 서버에 바인딩하고 브라우저를 여는 방식은 원격 접속(Remote Access) 시 실패하며, 이는 개발자 경험(Developer Experience)을 저해하는 주요 요인으로 지적된다. `xdg-open` 오류나 X 포워딩 문제 등이 구체적인 사례로 언급된다.

RFC 8628은 입력 제약 장치(Input-Constrained Devices)를 위해 설계되었으며, CLI와 같이 브라우저가 없는 환경에 이상적이다. 사용자는 별도의 장치에서 인증하고, CLI는 포트를 바인딩할 필요 없이 폴링(Polling) 방식으로 토큰을 획득한다. 이는 다양한 환경(Diverse Environments)에서의 일관된 인증 경험을 제공하며, 특히 CI/CD 파이프라인에서의 활용성이 높다고 평가된다.

커뮤니티에서는 RFC 8628 흐름이 사회 공학적 공격(Social Engineering Attack)에 취약할 수 있다는 우려가 제기된다. 공격자가 실제 인증 엔드포인트와 코드를 사용하여 사용자를 속일 수 있다는 것이다. 이에 대한 완화 방안으로 짧은 사용자 코드 만료 시간(Short User Code Expiry), 클라이언트 이름 및 위치 표시(Client Name and Location Display), 조건부 액세스 정책(Conditional Access Policies) 등이 논의된다.

일부 사용자는 로컬 머신에서 작동할 때 상호작용이 거의 없는(Zero Interaction) 브라우저 기반 흐름을 선호한다. 반면, 다른 사용자들은 SSH 환경에서의 명시적인 코드 입력(Explicit Code Entry) 방식이 더 안정적이라고 주장한다. 이는 사용자 환경(User Environment)에 따른 선호도 차이를 보여주며, CLI 개발 시 기본값 설정에 대한 고민이 필요함을 시사한다.

글에서는 Go 언어로 약 30줄의 코드로 RFC 8628 구현이 가능함을 보여준다. `gh auth login`, `aws sso login` 등 일부 CLI는 이미 이 표준을 채택했지만, `gcloud`, `wrangler`, `claude` 등 많은 주요 도구는 여전히 구식 루프백 방식(Legacy Loopback Method)을 기본으로 사용하고 있다. 이는 개발자 도구(Developer Tooling) 생태계 전반의 개선 필요성을 강조한다.