Skip to content

✨ [Feat] 기기 바인딩 기반 신뢰 기기 로그인 (새 기기 로그인 시 SMS 재인증 강제) #141

Description

@komascode

📝 개요

현재 로그인은 휴대폰번호 + 6자리 간편비밀번호(PIN)만으로 인증되며, 서버에 기기 식별 정보가 없어 PIN만 알면 어떤 기기에서든 로그인이 가능하다. 거래소 API 키·이체 기능을 다루는 서비스 특성상, 유출된 PIN으로 낯선 기기에서 자산에 접근할 수 있는 위험이 있다.

핀테크 표준 방식인 기기 바인딩(신뢰 기기) 을 도입한다:

  • 회원가입/최초 로그인 시 기기를 신뢰 기기로 등록한다.
  • 신뢰 기기에서의 로그인 → PIN만으로 통과 (기존 UX 유지).
  • 미등록(새) 기기에서의 로그인 → PIN이 맞아도 SMS 재인증(verificationToken) 강제, 성공 시 해당 기기를 신뢰 기기로 등록.

로그인 요청에 verificationToken을 받아 잠금/RT 만료를 해제하는 배관이 이미 존재하므로(AuthService.login), 이를 "새 기기" 케이스로 확장하는 형태로 구현한다.

✔️ To-Do

  • 로그인/회원가입 요청 DTO에 deviceId(클라이언트 생성 UUID 등) 필드 추가 — 프론트 협의 필요
  • 신뢰 기기 저장 구조 설계 (member당 다중 기기, 기기별 식별자·등록일·마지막 사용일)
  • 로그인 시 기기 판별 로직: 등록 기기 → PIN만, 미등록 기기 → smsRequired 응답으로 SMS 재인증 유도
  • SMS 재인증(verificationToken) 성공 시 신규 기기 등록 처리
  • 기기 개수 상한/오래된 기기 정리 정책 정의
  • 신뢰 기기 목록 조회·삭제(로그아웃한 기기 해제) API 필요 여부 검토
  • 관련 에러코드·응답 페이로드(smsRequired, reason=new_device) 정의

👀 ETC

  • 프론트엔드의 deviceId 발급·영속화 방식 협의 선행 필요 (백엔드 단독 완결 불가)
  • 관련 코드: AuthService.login (verificationToken 처리부), AuthReqDTO.LoginRequest, Member 엔티티
  • UX 옵션 비교: (a) 신뢰 기기(권장) / (b) 매 로그인 SMS(가장 안전, UX 최악) / (c) 현행 유지

Metadata

Metadata

Assignees

Labels

✨ feat새로운 기능!

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions