[Feat] 인증 도메인 (AUTH-1~4, 6~8)

[DGAZA-max]

💡 개요

• 인증 도메인을 구현합니다. 회원가입부터 비밀번호 찾기까지, 토큰을 발급하고 회수하는 한 사이클이 전부 들어 있습니다.
• 머지되면 X-Dev-User-Id 헤더 우회를 실제 JWT로 바꿀 수 있습니다. 다른 도메인에서는 @AuthenticationPrincipal AuthenticatedUser로 현재 사용자를 꺼내 쓰시면 됩니다.
• 양이 많아 죄송합니다. 대신 커밋 13개를 순서대로 읽으면 되도록 잘라뒀습니다. 각 커밋은 그 시점의 코드만으로 말이 되고(예: 로그아웃이 없는 커밋에는 블랙리스트 검사도 없습니다), 왜 그렇게 했는지를 커밋 메시지에 적어뒀습니다. 파일 단위로 보시면 훨씬 어렵습니다.
• chore/jdk-21 위에 쌓여 있습니다. 그쪽이 머지되면 base가 dev로 자동 변경됩니다.

🛠️ 작업 내용

• AUTH-1 회원가입 — 가입 즉시 로그인 상태로 진입, 인증 메일 발송
• AUTH-2 로그인 — 계정 열거 방지(응답·응답시간 동일)
• AUTH-3 토큰 재발급 — RTR + Redis 화이트리스트 + 재사용 감지(전 기기 무효화)
• AUTH-4 로그아웃 — access 블랙리스트 + refresh 폐기 + 쿠키 삭제
• AUTH-6 이메일 인증 — 토큰 해시 저장, TTL 24시간, 1회용, 재발송
• AUTH-7 비밀번호 찾기 — TTL 30분, 1회용, 재설정 시 refresh 전체 무효화
• AUTH-8 브루트포스 잠금 — 계정+IP 기준 5회, 지수 백오프 1→15분
• 메일 발송 추상화 — 로컬은 콘솔 로그, 운영은 Resend (정책상 배포 후 SES 전환)
• 메일 유발 요청 호출 제한 — 재설정 요청 주소당 3회/시간, 재발송 계정당 3회/시간
• users 엔티티 — 인증에 필요한 최소 필드만 선점
• 에러코드 AUTH001 ~ AUTH010 (다음 기능은 AUTH011부터)
• 테스트 30개 — Testcontainers로 실제 MySQL·Redis를 띄운 통합 테스트

엔드포인트

메서드	경로	인증
POST	/api/v1/auth/signup	공개
POST	/api/v1/auth/login	공개
POST	/api/v1/auth/reissue	공개
POST	/api/v1/auth/logout	공개
POST	/api/v1/auth/email/verify	공개
POST	/api/v1/auth/email/verification	필요
POST	/api/v1/auth/password/reset-request	공개
POST	/api/v1/auth/password/reset	공개

토큰 전달 규칙 (프런트 연동 시 참고)

• access: 응답 바디 → 프런트가 메모리에만 보관 (localStorage 금지)
• refresh: httpOnly + Secure + SameSite=Lax 쿠키. 경로를 /api/v1/auth로 좁혀 일반 데이터 요청에는 실리지 않습니다
• access 30분 / refresh 3일 (정책)

💬 리뷰 포인트

1. users 엔티티 필드 선정 — @이중현

인증에 필요한 최소 필드만 먼저 만들었습니다. USR-1~3에 당장 필요한 필드가 빠졌는지만 봐주세요.

• 넣은 것: id · public_id(ULID) · email · password_hash · nickname · role · email_verified · status · trust_score · last_login_at · deleted_at
• 일부러 뺀 것: phone · previous_nickname · nickname_changed_at — USR 범위라 중현님이 추가하시는 게 맞다고 봤습니다
• reported_flag는 넣었습니다 — 신뢰도 TRS-3(하한 보호 해제)이 쓰는 값이라 제 도메인입니다

지금 ddl-auto=create-drop이라 필드 추가 비용은 없습니다. 편하게 말씀해 주세요.

2. 불친절해 보이는 응답은 대부분 의도한 것입니다

• 로그인에서 계정 없음과 비밀번호 틀림이 같은 코드·같은 메시지입니다. 다르면 응답만 보고 가입 여부를 알 수 있습니다. 같은 이유로 계정이 없어도 더미 해시와 BCrypt 비교를 한 번 수행합니다 — 건너뛰면 응답 시간(수십 ms)으로 구분됩니다
• 재설정 요청도 가입 여부와 무관하게 항상 같은 200입니다. "이 계정은 소셜 로그인입니다" 안내는 화면이 아니라 메일 본문으로 나갑니다
• 토큰 오류도 만료·이미 사용됨·존재하지 않음을 구분하지 않습니다

메시지를 친절하게 바꾸자는 의견 주시기 전에 한 번 물어봐 주시면 감사하겠습니다.

3. 로컬에서 직접 돌려보실 때

app.mail.provider=log가 기본이라 인증 링크가 콘솔에 그대로 찍힙니다. 메일 계정 없이 가입 → 인증 → 비밀번호 재설정까지 끝까지 확인하실 수 있습니다.

✅ 체크리스트

• deferred 이슈 영향 없음 / 갱신함
  • OAuth(AUTH-5)는 카카오 앱키 발급 대기 중입니다. 나오는 대로 바로 올립니다
  • 자체 점검에서 나온 2건은 논의가 필요해 이번 PR에 넣지 않았습니다
    • 비밀번호 변경 후 access 토큰이 만료까지(최대 30분) 살아 있습니다. refresh는 즉시 전부 끊깁니다. 막으려면 요청마다 Redis 읽기가 하나 늘어납니다
    • MAIL_PROVIDER를 배포에서 빠뜨리면 기본값 log로 조용히 기동돼 메일이 로그로만 나갑니다. 필수값으로 올릴지 결정이 필요합니다

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3fc31acd-8466-43f2-a156-2d8a5d34630c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[RootToApex]

🔴 1. 재사용 공격 대응이 조용히 실패한다 (High)

AuthCommandService.java (reissue) · RefreshTokenStore.java (revokeAll)

log.warn("refresh 재사용 감지 - 해당 유저의 모든 세션을 무효화한다. userId={}", claims.userId());
refreshTokenStore.revokeAll(claims.userId());
throw new BusinessException(AuthErrorCode.INVALID_TOKEN);

revokeAll이 내부에서 예외를 삼키고 경고만 남깁니다.

public void revokeAll(Long userId) {
    try { redisTemplate.delete(key(userId)); }
    catch (RuntimeException e) { log.warn("refresh 전체 무효화 실패 - reason={}", ...); }
}

재현 — Redis가 일시적으로 응답하지 않는 동안 탈취된 옛 refresh가 들어오는 경우

1. 화이트리스트 조회 실패 → entry == null → 재사용으로 판정
2. revokeAll 호출 → 삭제 실패 → 경고 로그만 남음
3. 호출자에겐 INVALID_TOKEN 하나만 반환

결과적으로 공격자의 나머지 기기 토큰은 그대로 살아 있는데, 로그를 보지 않는 한 무효화된 것으로 보입니다.

클래스 주석의 근거는 "삭제만 예외를 삼킨다 — 로그아웃은 쓰기가 실패해도 진행돼야 하기 때문"인데, 이 호출은 로그아웃이 아니라 공격 대응입니다. 정책도 두 경로를 나눠서 적고 있습니다.

• 로그아웃(쓰기)은 별개다: Redis 쓰기 실패와 무관하게 (…) 200을 반환한다
• 화이트리스트 저장(로그인)·조회(재발급)는 fail-closed 유지

재사용 감지는 화이트리스트 계열이라 fail-closed 쪽에 가깝다고 봅니다. revokeAll(userId, boolean failClosed)로 나누거나 공격 대응 전용 메서드를 따로 두는 건 어떨까요?

[RootToApex]

🟡 2. public_id 생성기가 둘이 된다 (Medium)

global/util/PublicId.java ↔ PR #16의 global/util/PublicIdGenerator.java

같은 일을 하는 클래스가 둘입니다. 먼저 머지되는 쪽이 남고 뒤엣것이 충돌을 풀어야 합니다.

구현을 검산했는데 경화님 것이 정확합니다 — Crockford Base32 32자(I·L·O·U 제외), 48비트 타임스탬프 10자 + 40비트씩 랜덤 16자 = 26자.

의존성이 0개인 쪽이 낫다고 봅니다. 다만 지금 제 것을 지우면 PublicId가 아직 머지되지 않아 #16 빌드가 깨집니다. #18이 먼저 머지되면 제가 #16에서 PublicIdGenerator와 ulid-creator 의존성을 걷어내겠습니다. 제 것이 먼저 머지되면 머지 직후 정리 PR을 따로 내겠습니다.

한 가지만 남깁니다 — static 메서드라 테스트에서 값을 고정할 수 없습니다. 지금은 필요 없지만 "특정 public_id로 저장된 상태"를 단정해야 하는 테스트가 생기면 그때 인터페이스로 감싸야 합니다.

[RootToApex]

🔵 3. 탈퇴한 계정의 닉네임이 영구 점유된다 (Low)

UserRepository.java (existsByNickname)

삭제 행까지 포함해 확인하므로 탈퇴자의 닉네임은 다시 쓸 수 없습니다. 정책상 "닉네임 마스킹은 표시 레벨"이라 DB에는 원래 값이 남고요.

주석에 "USR-3 소유라 여기서 정하지 않는다"고 하셨는데, 제 담당이라 제가 정하겠습니다. 다만 이메일과 성격이 다르다는 점만 남깁니다.

• 이메일 재가입 불허 → 신뢰도 세탁 방지가 목적이라 영구 점유가 맞습니다
• 닉네임 UNIQUE → 사칭 방지가 목적이라, 탈퇴 후 일정 기간이 지나면 풀어주는 것도 성립합니다

정하면 공유하겠습니다. 이 PR을 막지는 않습니다.

[RootToApex]

지적 1번(재사용 대응 fail-open)만 정리되면 승인하겠습니다. 2·3번은 제가 처리하거나 제 도메인 결정이라 이 PR을 막지 않습니다.

SecurityConfig를 저와 함께 고쳤습니다 — 경화님은 /api/v1/auth/* 추가와 JWT 필터 등록, 저는 #16에서 매물 경로를 /api/v1/listings → /api/listings로 맞췄습니다(API 명세서·이미 머지된 시세 조회가 v1 없는 경로라서요). auth 경로의 v1은 소유가 아니라 손대지 않았습니다. v1을 남길지 뺄지는 정해야 할 것 같습니다.