Auth (인증 및 인가)

0. 검증 및 보안

• 토큰 유효성 검증
• Access Token 서명 및 만료 여부 검증
• Refresh Token 유효성 검증
• 사용자 자격 증명 검증
• account-api 연동을 통한 아이디/비밀번호 검증
• 탈퇴 및 휴면 계정 로그인 차단
• 토큰 보안 전달
• Access Token: Response Body 전달
• Refresh Token: HttpOnly 쿠키로 전달
  • 현재 Secure는 개발 환경을 위해 비활성화되어 있고 SameSite는 명시하지 않아 브라우저 기본값(Lax)이 적용된다. 운영 배포 전 Secure=true 설정이 필요하다.

1. 사용자 로그인 및 토큰 발급

• 사용자 인증 및 토큰 최초 발급
• 로그인 아이디/비밀번호 수신
• account-api 와 통신하여 사용자 자격 증명(비밀번호 일치 여부) 검증
• 검증 성공 시 JWT 토큰 쌍(Access Token, Refresh Token)생성
• Refresh Token은 HttpOnly 쿠키로 응답 헤더에 설정 후 전달

2. 토큰 재발급(Refresh)

• Access Token갱신
• 요청 쿠키에서 Refresh Token 추출 및 서명/만료일 검증
• Redis에 저장된 Refresh Token과 대조 (키가 refreshToken:{userId}이므로 새 로그인 시 이전 토큰이 덮어써져 사용자당 단일 세션이 유지된다)
• 재발급 전 account-api에서 계정 상태·역할을 다시 조회하여, ACTIVE가 아니면 재발급을 거부
• 유효한 Refresh Token 확인 시 신규 Access Token 생성 및 반환
• 만료되었거나 변조된 Refresh Token일 경우 재로그인 예외 처리
• Refresh Token 자체는 회전(rotation)하지 않고 기존 토큰을 그대로 반환한다. (재사용 탐지 없음)

Auth 서비스는 자체 사용자 DB를 갖지 않는다. 자격 증명 검증과 계정 정보는 모두 account-api에 위임하며, Redis만 상태 저장소로 사용한다.

3. 로그아웃

• 인증 상태 해제 및 쿠키 파기
• 로그아웃 요청 시 Client의 Refresh Token 쿠키 만료 처리
• Redis에 저장된 Refresh Token 삭제
• 남은 만료 시간만큼 Access Token을 Redis 블랙리스트(blacklist:{token})에 등록

⚠️ 현재 블랙리스트는 조회하는 곳이 없다. 게이트웨이를 포함해 어떤 서비스도 이 키를 확인하지 않으므로, 로그아웃한 Access Token도 자연 만료(1시간) 전까지는 계속 유효하다. 실질적인 로그아웃 차단을 위해서는 게이트웨이에 블랙리스트 검사 필터가 필요하다.

4. 예외 및 에러 처리

• 인증 실패 처리 — 존재하지 않는 계정 또는 비밀번호 불일치 (LoginFailException)
• Refresh Token 검증 실패 처리 (RefreshTokenValidateException)
• 토큰 파싱 예외는 개별 타입이 아니라 JwtException으로 일괄 처리한다. (MalformedJwtException, SignatureException을 따로 다루는 코드는 없다)

⚠️ 만료 토큰 처리에 결함이 있다. 토큰 파싱 시 ExpiredJwtException을 잡은 뒤 예외를 다시 던지지 않고 클레임을 그대로 반환하기 때문에, 만료된 Access Token으로도 사용자 정보 추출이 성공하며 로그아웃 요청이 통과된다.