많은 CLI(명령줄 인터페이스) 도구들이 사용자 인증을 위해 로컬 브라우저를 활용하는 OAuth 리다이렉트 방식을 기본으로 사용해왔습니다. 이는 노트북과 같이 CLI와 브라우저가 동일한 환경에 있을 때는 빠르고 편리하지만, SSH 세션, 컨테이너, WSL(Windows Subsystem for Linux)과 같은 원격 또는 가상화된 개발 환경에서는 브라우저가 없거나 포트 바인딩 문제로 인해 인증 흐름이 중단되는 문제가 빈번하게 발생했습니다. 이로 인해 사용자들은 수동적인 우회 방법을 찾아야 하는 불편함을 겪어왔습니다.
기존 방식은 CLI가 127.0.0.1에 임시 HTTP 서버를 열고 시스템 브라우저를 인증 URL로 보낸 뒤, 인증 제공자가 authorization code를 로컬 콜백으로 돌려주는 구조입니다. gcloud auth login, wrangler login 등 여러 벤더 CLI가 이 방식을 사용합니다. 하지만 이러한 방식은 CLI가 실행되는 머신과 브라우저가 실행되는 머신이 같다는 전제에 의존하며, 이 전제가 깨질 경우 인증이 실패합니다. 예를 들어, SSH 환경에서는 원격 호스트에 브라우저가 없어 xdg-open 같은 명령이 실패하고, 컨테이너 환경에서는 브라우저가 아예 없는 경우가 많습니다. WSL에서는 리눅스 서브시스템과 윈도우즈 브라우저 간의 포트 포워딩 문제가 발생하기도 합니다.
이러한 문제를 해결하기 위해 2019년 표준화된 RFC 8628 디바이스 권한 부여(Device Authorization Grant) 방식이 새로운 대안으로 떠오르고 있습니다. 이 방식은 토큰을 요청하는 CLI 장치와 사용자가 인증하는 브라우저 장치를 분리하는 것이 핵심입니다. CLI는 인증 제공자에게 디바이스 코드를 요청하고, 사용자에게는 짧은 코드와 함께 인증 URL을 제공합니다. 사용자는 별도의 장치(예: 스마트폰이나 다른 PC의 웹 브라우저)에서 해당 URL에 접속하여 코드를 입력하고 인증을 완료합니다. CLI는 일정 간격으로 토큰 엔드포인트를 폴링하여 인증 완료 여부를 확인하고 토큰을 발급받습니다.
디바이스 플로우(Device flow)는 CLI가 포트를 바인딩하거나 실행 호스트에 브라우저가 있다고 가정하지 않으므로, 노트북, 컨테이너, 심지어 CI/CD 파이프라인과 같은 다양한 환경에서 동일한 로그인 방식을 사용할 수 있게 합니다. 이는 개발자 경험을 크게 개선하고, 복잡한 환경 설정 없이도 일관된 인증 프로세스를 제공합니다. 또한, OpenID Connect Discovery를 지원하는 인증 제공자의 경우, CLI는 .well-known/openid-configuration에서 필요한 엔드포인트를 자동으로 발견하여 URL 하드코딩을 없앨 수 있습니다.
물론 디바이스 플로우에도 피싱 위험이 존재합니다. 공격자가 디바이스 인증 엔드포인트를 호출하여 user_code와 device_code를 받은 뒤 피해자에게 입력을 유도하는 방식입니다. 하지만 이러한 피싱 방어는 CLI가 아닌 인증 제공자 측에서 이루어져야 합니다. 짧은 user_code 만료 시간, 인증 페이지에 클라이언트 이름과 요청 위치 명시, 코드 입력 시도에 대한 속도 제한, 그리고 고가치 테넌트(tenant)에 대한 조건부 접근 정책 등이 주요 완화책입니다. CLI의 역할은 명세를 따르고 사용자 편의를 위한 단축키를 만들지 않는 것입니다. 이미 GitHub CLI(gh auth login)와 AWS SSO 로그인(aws sso login) 등은 디바이스 플로우를 기본값으로 사용하고 있으며, 이는 업계의 새로운 표준으로 자리 잡을 것으로 예상됩니다.