📝 개요
현재 로그인은 휴대폰번호 + 6자리 간편비밀번호(PIN)만으로 인증되며, 서버에 기기 식별 정보가 없어 PIN만 알면 어떤 기기에서든 로그인이 가능하다. 거래소 API 키·이체 기능을 다루는 서비스 특성상, 유출된 PIN으로 낯선 기기에서 자산에 접근할 수 있는 위험이 있다.
핀테크 표준 방식인 기기 바인딩(신뢰 기기) 을 도입한다:
- 회원가입/최초 로그인 시 기기를 신뢰 기기로 등록한다.
- 신뢰 기기에서의 로그인 → PIN만으로 통과 (기존 UX 유지).
- 미등록(새) 기기에서의 로그인 → PIN이 맞아도 SMS 재인증(verificationToken) 강제, 성공 시 해당 기기를 신뢰 기기로 등록.
로그인 요청에 verificationToken을 받아 잠금/RT 만료를 해제하는 배관이 이미 존재하므로(AuthService.login), 이를 "새 기기" 케이스로 확장하는 형태로 구현한다.
✔️ To-Do
👀 ETC
- 프론트엔드의
deviceId 발급·영속화 방식 협의 선행 필요 (백엔드 단독 완결 불가)
- 관련 코드:
AuthService.login (verificationToken 처리부), AuthReqDTO.LoginRequest, Member 엔티티
- UX 옵션 비교: (a) 신뢰 기기(권장) / (b) 매 로그인 SMS(가장 안전, UX 최악) / (c) 현행 유지
📝 개요
현재 로그인은
휴대폰번호 + 6자리 간편비밀번호(PIN)만으로 인증되며, 서버에 기기 식별 정보가 없어 PIN만 알면 어떤 기기에서든 로그인이 가능하다. 거래소 API 키·이체 기능을 다루는 서비스 특성상, 유출된 PIN으로 낯선 기기에서 자산에 접근할 수 있는 위험이 있다.핀테크 표준 방식인 기기 바인딩(신뢰 기기) 을 도입한다:
로그인 요청에 verificationToken을 받아 잠금/RT 만료를 해제하는 배관이 이미 존재하므로(AuthService.login), 이를 "새 기기" 케이스로 확장하는 형태로 구현한다.
✔️ To-Do
deviceId(클라이언트 생성 UUID 등) 필드 추가 — 프론트 협의 필요smsRequired,reason=new_device) 정의👀 ETC
deviceId발급·영속화 방식 협의 선행 필요 (백엔드 단독 완결 불가)AuthService.login(verificationToken 처리부),AuthReqDTO.LoginRequest,Member엔티티