콘솔에 표시한 QR이나 짧은 코드를 휴대폰에서 승인해 로그인시키려 합니다. 다른 사람의 기기가 연결되지 않도록 무엇을 확인해야 하나요?

QR이나 짧은 user code는 사용자가 어느 요청을 승인할지 찾기 위한 식별자이지, 신원이나 승인 의도를 스스로 증명하지 않습니다. Device Authorization Grant에서는 콘솔 같은 입력 제한 장치가 아직 로그인되지 않았어도 서버에서 device_code와 사람이 입력할 user_code를 발급받고, 사용자는 별도 브라우저나 휴대폰에서 인증·승인합니다. 따라서 최초 콘솔 계정이나 같은 브라우저 세션을 전제로 하지 않고, 승인자의 계정과 서버에 대기 중인 대상 장치를 정확히 연결하는 것이 핵심입니다.

비밀 device_code와 표시용 user_code를 분리합니다

콘솔은 서버에서 예측하기 어려운 device_code와 짧은 user_code를 받아 사용자에게 user_code나 QR을 보여 줍니다. device_code는 콘솔이 token endpoint를 polling할 때 쓰는 비밀 자격이고, user_code는 사람이 승인 화면에서 대상 요청을 찾는 표시·입력 값이므로 둘을 같은 값으로 만들지 않습니다. QR에 device_code를 그대로 담으면 QR을 촬영한 사람이 token polling을 시도할 수 있으므로 전송·보관·로그·화면 캡처에서 device_code를 비밀처럼 다룹니다. user_code는 추측 가능성이 크고 피싱에 이용될 수 있으므로 짧은 만료, 시도 횟수 제한, 사용자 확인을 둡니다.

휴대폰이나 브라우저에서 승인할 때는 사용자가 먼저 자신의 계정으로 인증하고, 화면에 어느 장치·어느 서비스·어떤 목적의 로그인 요청인지 보여 줍니다. user_code가 맞는다는 것만으로 승인하지 않고 사용자가 명시적으로 승인하게 합니다. 서버는 대기 요청의 상태, 만료 시각, 승인자 계정, 대상 device 세션을 하나의 승인 객체로 기록합니다. 승인자의 계정은 대상 기기의 새 로그인 주체가 되지만, 콘솔이 처음부터 같은 계정에 로그인돼 있었다고 가정하지 않습니다. 이 흐름은 authorization code와 PKCE를 사용하는 브라우저 로그인과 다른 Device Authorization Grant (기기 승인 부여)입니다.

polling과 승인 소비를 원자적으로 처리합니다

콘솔은 device_code로 상태를 polling하며, pending·approved·denied·expired를 구분합니다. polling 간격과 최대 대기 시간을 서버가 지키게 하고, 너무 빠른 요청에는 backoff를 적용합니다. user_code 입력 endpoint도 인증되지 않은 공격자가 대량으로 추측할 수 있으므로 계정·IP·코드별 rate limit을 둡니다. 승인 응답이 유실돼 콘솔이 다시 조회해도 같은 승인 객체에서 결과를 확인해야 하며, 매번 새 device credential을 발급해 중복 세션을 만들지 않도록 결과 교환을 제한합니다.

승인은 원자적으로 한 번만 완료돼야 합니다. 두 휴대폰의 동시 승인에서는 pending에서 approved로 가는 상태 전이를 하나만 허용합니다. 승인 뒤 토큰 교환은 별도의 소비 단계이며, 동시 polling이 중복 세션을 발급하지 않도록 서버 계약에 따라 한 번만 확정합니다. 사용자가 거절한 요청은 승인하지 않고, 승인 전에 계정을 바꾸었다면 실제로 선택한 계정과 대상을 다시 확인하며, 만료·재사용된 user_code와 device_code는 거절합니다. 승인 후 발급되는 장기 기기 자격은 user_code와 분리해 안전한 저장 공간에 보관하고, 분실 신고·로그아웃·원격 회수·재인증 정책을 별도로 둡니다.

검증은 다른 사람의 user_code를 입력하게 유도하는 피싱 화면, device_code 유출, 만료·재사용, 두 승인자의 경합, 응답 유실, polling 폭주, 승인 뒤 콘솔 연결 단절을 재현합니다. 로그인 성공률만 보지 않고 승인 대상 표시의 정확성, 오인 승인률, 승인 객체가 정확히 한 대상 장치와 한 계정에 연결되는지, 장기 자격이 회수되는지를 확인하겠습니다.