🔀 Jwt Refresh

[ohyuchan123]

📌 관련 이슈

#33 Refresh Token 도입

✨ 과제 내용

리프레시 토큰 도입

📸 스크린샷(선택)

📚 레퍼런스 (또는 새로 알게 된 내용) 혹은 궁금한 사항들

Summary by CodeRabbit

• 새로운 기능

  • 액세스 토큰과 리프레시 토큰을 사용한 향상된 인증 시스템 도입
  • 새로 고침 토큰을 처리하는 컨트롤러 추가
  • 토큰 쿠키 관리 기능 개선
  • 토큰 유효 기간 세부 설정 추가

• 버그 수정

  • 이메일 인증 코드 검증 프로세스 안정성 개선
  • Redis 서비스의 이메일 확인 로직 강화

• 리팩토링

  • JWT 토큰 생성 및 관리 방식 최적화
  • 쿠키 처리 로직 세분화
  • 인증 필터에서 두 개의 토큰을 생성하도록 업데이트
  • 메일 서비스의 코드 검증 로직 간소화

[coderabbitai]

Walkthrough

이 풀 리퀘스트는 JWT 토큰 인증 시스템의 주요 리팩토링을 포함하고 있습니다. 주요 변경 사항은 단일 토큰에서 액세스 및 리프레시 토큰 시스템으로의 전환, JWT 속성 구성 변경, 쿠키 관리 개선 등입니다. 이러한 수정은 애플리케이션의 인증 메커니즘을 더욱 안전하고 유연하게 만들기 위한 포괄적인 접근 방식을 나타냅니다.

Changes

파일	변경 요약
JWTProperties.java	기본값 제거, 새 속성 추가 (리프레시 토큰 유효 시간, 액세스 및 리프레시 토큰 쿠키 이름)
RefreshController.java	새 컨트롤러 추가, 액세스 토큰 새로 고침 엔드포인트 구현
TokenResponse.java	새 레코드 생성, 액세스 토큰을 위한 정적 팩토리 메서드 추가
JWTFilter.java	쿠키 이름 확인 로직 업데이트
JWTUtil.java	액세스 및 리프레시 토큰 생성 메서드 추가, 에러 핸들링 개선
CookieUtil.java	리프레시 토큰용 쿠키 생성 및 만료 메서드 추가
LoginFilter.java	토큰 및 쿠키 생성 로직 이중 토큰 시스템으로 변경
AuthService.java	로그인 및 로그아웃에서 이중 토큰 시스템 구현
MailService.java	코드 검증 로직 단순화
RedisService.java	이메일 검증 로직 개선
LoginTest.java	JWTProperties 모의 추가 및 토큰 생성 검증 로직 수정

Sequence Diagram

sequenceDiagram
    participant Client
    participant LoginFilter
    participant JWTUtil
    participant CookieUtil
    participant Response

    Client->>LoginFilter: 로그인 요청
    LoginFilter->>JWTUtil: 액세스 토큰 생성
    JWTUtil-->>LoginFilter: 액세스 토큰
    LoginFilter->>JWTUtil: 리프레시 토큰 생성
    JWTUtil-->>LoginFilter: 리프레시 토큰
    LoginFilter->>CookieUtil: 액세스 토큰 쿠키 생성
    LoginFilter->>CookieUtil: 리프레시 토큰 쿠키 생성
    CookieUtil-->>Response: 쿠키 추가
    Response-->>Client: 로그인 응답

Loading

Possibly related PRs

• 🔀 Jwt Login #24: JWT 로그인 기능 구현
• 🔀 File Directory Refactor #30: JWT 속성 리팩토링
• 🔀 Redis Email Send #34: Redis를 활용한 이메일 인증 구현

Suggested labels

✅ Test

Poem

🐰 토큰의 춤, 보안의 노래
쿠키 속 비밀 두 개의 날개
액세스와 리프레시, 춤을 추네
안전한 문을 활짝 열어요
래빗의 보안 마법 🔒✨

---

📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f16eaec and c25e10d.

📒 Files selected for processing (1)

• src/main/java/com/mycom/socket/auth/service/AuthService.java (4 hunks)

🔇 Additional comments (1)

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

3-3: 토큰 설정의 중앙화가 잘 구현되었습니다!

JWTProperties를 통한 토큰 관련 설정의 중앙화는 좋은 접근 방식입니다.

Also applies to: 32-32

Finishing Touches

• 📝 Generate Docstrings (Beta)

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR. (Beta)
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 7

🔭 Outside diff range comments (2)

src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (2)

Line range hint 45-55: 토큰 생성 메서드 보안 강화 필요

토큰 생성 시 토큰 타입을 구분하고, 보안을 위한 추가 claim이 필요합니다.

다음과 같이 수정하는 것을 제안합니다:

-    public String createToken(String email, long validityInSeconds) {
+    private String createToken(String email, String tokenType, long validityInSeconds) {
         Date now = new Date();
         Date validity = new Date(now.getTime() + (validityInSeconds * 1000));
 
         return Jwts.builder()
                 .issuer(jwtProperties.getIssuer())
                 .subject(email)
+                .claim("type", tokenType)
+                .id(UUID.randomUUID().toString())
                 .issuedAt(now)
                 .expiration(validity)
                 .signWith(secretKey)
                 .compact();
     }

---

Line range hint 60-76: 토큰 검증 로직 강화 필요

토큰 검증 시 만료 시간과 토큰 타입을 확인하는 로직이 필요합니다.

다음과 같이 수정하는 것을 제안합니다:

-    public boolean validateToken(String token) {
+    public boolean validateToken(String token, String expectedTokenType) {
         try {
             if (!StringUtils.hasText(token)) {
                 return false;
             }
 
-            Jwts.parser()
+            var claims = Jwts.parser()
                     .verifyWith(secretKey)
                     .requireIssuer(jwtProperties.getIssuer())
                     .build()
-                    .parseSignedClaims(token);
+                    .parseSignedClaims(token)
+                    .getPayload();
+
+            String tokenType = claims.get("type", String.class);
+            if (!expectedTokenType.equals(tokenType)) {
+                return false;
+            }
+
+            return !claims.getExpiration().before(new Date());
-            return true;
         } catch (Exception e) {
             log.warn("JWT 토큰 검증 실패", e);
             return false;
         }
     }

🧹 Nitpick comments (9)

src/main/java/com/mycom/socket/global/service/RedisService.java (2)

93-93: null 체크 로직이 잘 개선되었습니다!

null 안전성을 위해 verified 객체에 대한 명시적인 null 체크를 추가한 것이 좋습니다. 이는 잠재적인 NullPointerException을 방지하고 더 안정적인 코드를 만듭니다.

하지만 몇 가지 제안사항이 있습니다:

1. 메서드에 JavaDoc 주석을 보강하여 null 처리 동작을 문서화하면 좋을 것 같습니다.
2. 상수로 "true" 값을 추출하는 것을 고려해보세요.

+ private static final String VERIFICATION_TRUE_VALUE = "true";

  public boolean isEmailVerified(String email) {
      Object verified = redisTemplate.opsForValue().get(VERIFIED_EMAIL_PREFIX + email);
-     return verified != null && "true".equals(verified.toString());
+     return verified != null && VERIFICATION_TRUE_VALUE.equals(verified.toString());
  }

---

Line range hint 16-19: 보안 관련 구현이 잘 되어있습니다.

다음과 같은 보안 관련 구현사항들이 잘 적용되어 있습니다:

• 키 접두사를 통한 네임스페이스 분리
• 적절한 TTL 설정으로 민감한 데이터의 수명 관리
• 이메일 인증 및 속도 제한 메커니즘

추가 보안 강화를 위한 제안:

1. 키 접두사를 환경 변수나 설정 파일로 분리하는 것을 고려해보세요.
2. Redis 연결에 대한 SSL/TLS 설정 검토가 필요합니다.

Also applies to: 21-24

src/main/java/com/mycom/socket/auth/service/MailService.java (1)

98-99: 이메일 인증 상태 저장의 원자성 보장이 필요합니다.

여러 요청이 동시에 처리될 때 발생할 수 있는 레이스 컨디션을 방지하기 위해, Redis 작업의 원자성을 보장하는 것이 좋습니다.

RedisService에서 다음과 같은 원자적 작업을 구현하는 것을 고려해보세요:

public boolean verifyAndSaveEmailStatus(String email, String code) {
    return redisTemplate.execute(new SessionCallback<Boolean>() {
        @Override
        public Boolean execute(RedisOperations operations) throws DataAccessException {
            operations.multi();
            String savedCode = getCode(email);
            if (savedCode != null && savedCode.equals(code)) {
                saveVerifiedEmail(email);
                operations.exec();
                return true;
            }
            operations.discard();
            return false;
        }
    });
}

src/main/java/com/mycom/socket/auth/controller/RefreshController.java (3)

31-32: BadRequestException 대신 UnauthorizedException 사용을 권장합니다.

현재 리프레시 토큰이 유효하지 않을 때 BadRequestException을 발생시키고 있습니다. 이 경우 인증이 필요한 상황이므로 보다 적절한 HTTP 상태 코드를 반환하기 위해 UnauthorizedException으로 변경하는 것이 좋습니다.

---

45-45: 액세스 토큰을 응답 본문과 쿠키에 중복 전달하고 있습니다.

액세스 토큰을 쿠키로 설정하면서 응답 본문으로도 반환하고 있습니다. 보안 및 중복 전송을 피하기 위해 하나의 방법으로 통일하는 것이 좋습니다.

---

49-59: 예외 메시지를 구체화하여 사용자 경험을 향상시킬 수 있습니다.

extractRefreshToken 메서드에서 쿠키가 없거나 리프레시 토큰 쿠키가 없을 때 동일한 예외 메시지를 반환하고 있습니다. 정확한 원인을 파악하기 위해 예외 메시지를 구체적으로 구분하는 것이 좋습니다.

예를 들어:

• 쿠키가 없을 경우: "쿠키가 존재하지 않습니다. 로그인 상태를 확인해주세요."
• 리프레시 토큰 쿠키가 없을 경우: "리프레시 토큰이 없습니다. 다시 로그인해주세요."

src/main/java/com/mycom/socket/auth/security/LoginFilter.java (1)

54-55: JWTUtil의 토큰 생성 메서드 사용 일관성을 유지하십시오.

현재 createAccessToken과 createRefreshToken 메서드를 사용하고 있습니다. 다른 클래스에서는 createToken(email, validityInSeconds) 형태의 메서드를 사용하고 있으므로, 메서드 사용을 일관되게 통일하는 것이 유지보수에 도움이 됩니다.

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

51-61: 토큰 생성 및 쿠키 설정 로직의 중복을 개선할 수 있습니다.

login 메서드에서 토큰 생성과 쿠키 설정 로직이 LoginFilter 클래스의 successfulAuthentication 메서드와 유사하게 중복되어 있습니다. 이러한 중복 코드를 공통 메서드로 추출하여 코드의 재사용성과 유지보수성을 높일 수 있습니다.

src/main/java/com/mycom/socket/auth/dto/response/TokenResponse.java (1)

3-8: 토큰 유효성 검증 추가 필요

액세스 토큰의 null 또는 빈 문자열 검증이 필요합니다. 팩토리 메서드에서 이를 처리하면 좋을 것 같습니다.

다음과 같이 수정하는 것을 제안합니다:

 public record TokenResponse(
         String accessToken
 ) {
     public static TokenResponse of(String accessToken) {
+        if (accessToken == null || accessToken.trim().isEmpty()) {
+            throw new IllegalArgumentException("액세스 토큰은 null이거나 빈 값일 수 없습니다.");
+        }
         return new TokenResponse(accessToken);
     }
 }

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5ef4d93 and 49b9c5f.

📒 Files selected for processing (11)

• src/main/java/com/mycom/socket/auth/config/JWTProperties.java (1 hunks)
• src/main/java/com/mycom/socket/auth/controller/RefreshController.java (1 hunks)
• src/main/java/com/mycom/socket/auth/dto/response/TokenResponse.java (1 hunks)
• src/main/java/com/mycom/socket/auth/jwt/JWTFilter.java (1 hunks)
• src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (1 hunks)
• src/main/java/com/mycom/socket/auth/security/CookieUtil.java (1 hunks)
• src/main/java/com/mycom/socket/auth/security/LoginFilter.java (1 hunks)
• src/main/java/com/mycom/socket/auth/service/AuthService.java (4 hunks)
• src/main/java/com/mycom/socket/auth/service/MailService.java (1 hunks)
• src/main/java/com/mycom/socket/global/service/RedisService.java (1 hunks)
• src/test/java/com/mycom/socket/member/service/LoginTest.java (4 hunks)

🔇 Additional comments (4)

src/main/java/com/mycom/socket/auth/service/MailService.java (1)

95-97: 코드 비교 로직이 적절합니다.

인증 코드 비교와 예외 처리가 명확하게 구현되어 있습니다.

src/main/java/com/mycom/socket/auth/security/LoginFilter.java (1)

58-61: 쿠키 설정 시 보안 속성을 확인하십시오.

쿠키를 생성할 때 HttpOnly, Secure, SameSite 등의 보안 옵션이 적절하게 설정되어 있는지 확인하는 것이 좋습니다. 이는 쿠키 탈취 및 CSRF 공격 등을 예방하는 데 도움이 됩니다.

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

115-115: 로그아웃 시 리프레시 토큰 쿠키 무효화 처리가 적절합니다.

로그아웃 처리 시 리프레시 토큰 쿠키를 만료시키는 로직이 추가되어 있습니다. 이는 보안 강화를 위해 필요한 조치이며, 올바르게 구현되었습니다.

src/main/java/com/mycom/socket/auth/jwt/JWTFilter.java (1)

49-51: 쿠키 이름 변경이 올바르게 구현되었습니다.

액세스 토큰을 위한 쿠키 이름이 명확하게 구분되어 있습니다.

리프레시 토큰 처리 로직 추가 검토가 필요합니다.

현재 필터는 액세스 토큰만 처리하고 있습니다. 리프레시 토큰 갱신 로직을 위한 별도의 엔드포인트나 필터 구현을 고려해보세요.

다음 스크립트로 리프레시 토큰 관련 엔드포인트 구현 여부를 확인할 수 있습니다:

[coderabbitai]

⚠️ Potential issue

Redis에서 가져온 코드의 null 체크가 필요합니다.

savedCode가 null인 경우 (코드가 만료되었거나 존재하지 않는 경우) NullPointerException이 발생할 수 있습니다.

다음과 같이 null 체크를 추가하는 것을 권장합니다:

 String savedCode = redisService.getCode(email);  // Redis에서 코드를 가져옴
+if (savedCode == null) {
+    throw new BaseException("만료되었거나 존재하지 않는 인증 코드입니다.", HttpStatus.BAD_REQUEST);
+}

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	String savedCode = redisService.getCode(email); // Redis에서 코드를 가져옴
	String savedCode = redisService.getCode(email); // Redis에서 코드를 가져옴
	if (savedCode == null) {
	throw new BaseException("만료되었거나 존재하지 않는 인증 코드입니다.", HttpStatus.BAD_REQUEST);
	}

[coderabbitai]

🛠️ Refactor suggestion

필수 속성에 대한 유효성 검증 추가 필요

토큰 유효 기간과 쿠키 이름은 필수 값이므로, 이에 대한 유효성 검증이 필요합니다.

다음과 같이 수정하는 것을 제안합니다:

+import jakarta.validation.constraints.NotBlank;
+import jakarta.validation.constraints.Positive;

 @Getter
 @Setter
 @Component
 @ConfigurationProperties(prefix = "jwt")
 public class JWTProperties {
     private String secret;
-    private long accessTokenValidityInSeconds;
-    private long refreshTokenValidityInSeconds;
-    private String accessTokenCookieName;
-    private String refreshTokenCookieName;
+    @Positive(message = "액세스 토큰 유효 기간은 양수여야 합니다")
+    private long accessTokenValidityInSeconds;
+    @Positive(message = "리프레시 토큰 유효 기간은 양수여야 합니다")
+    private long refreshTokenValidityInSeconds;
+    @NotBlank(message = "액세스 토큰 쿠키 이름은 필수입니다")
+    private String accessTokenCookieName;
+    @NotBlank(message = "리프레시 토큰 쿠키 이름은 필수입니다")
+    private String refreshTokenCookieName;
     private String issuer = "go_socket";
     private boolean secureCookie = false;
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	private long accessTokenValidityInSeconds;
	private long refreshTokenValidityInSeconds;
	private String accessTokenCookieName;
	private String refreshTokenCookieName;
	import jakarta.validation.constraints.NotBlank;
	import jakarta.validation.constraints.Positive;
	@Getter
	@Setter
	@Component
	@ConfigurationProperties(prefix = "jwt")
	public class JWTProperties {
	private String secret;
	@Positive(message = "액세스 토큰 유효 기간은 양수여야 합니다")
	private long accessTokenValidityInSeconds;
	@Positive(message = "리프레시 토큰 유효 기간은 양수여야 합니다")
	private long refreshTokenValidityInSeconds;
	@NotBlank(message = "액세스 토큰 쿠키 이름은 필수입니다")
	private String accessTokenCookieName;
	@NotBlank(message = "리프레시 토큰 쿠키 이름은 필수입니다")
	private String refreshTokenCookieName;
	private String issuer = "go_socket";
	private boolean secureCookie = false;
	}

[coderabbitai]

🛠️ Refactor suggestion

쿠키 생성 로직 중복 제거 필요

인증 쿠키와 리프레시 쿠키 생성 로직이 중복되어 있습니다. 공통 메서드로 추출하면 코드 유지보수가 더 쉬워질 것 같습니다.

다음과 같이 수정하는 것을 제안합니다:

+    private Cookie createCookie(String name, String value, long maxAgeInSeconds) {
+        Cookie cookie = new Cookie(name, value);
+        cookie.setHttpOnly(true);
+        cookie.setSecure(jwtProperties.isSecureCookie());
+        cookie.setPath("/");
+        cookie.setMaxAge((int) maxAgeInSeconds);
+        return cookie;
+    }

     public Cookie createAuthCookie(String token) {
-        Cookie cookie = new Cookie(jwtProperties.getAccessTokenCookieName(), token);
-        cookie.setHttpOnly(true);
-        cookie.setSecure(jwtProperties.isSecureCookie());
-        cookie.setPath("/");
-        cookie.setMaxAge((int) jwtProperties.getAccessTokenValidityInSeconds());
-        return cookie;
+        return createCookie(
+            jwtProperties.getAccessTokenCookieName(),
+            token,
+            jwtProperties.getAccessTokenValidityInSeconds()
+        );
     }

     public Cookie createRefreshCookie(String token) {
-        Cookie cookie = new Cookie(jwtProperties.getRefreshTokenCookieName(), token);
-        cookie.setHttpOnly(true);
-        cookie.setSecure(jwtProperties.isSecureCookie());
-        cookie.setPath("/");
-        cookie.setMaxAge((int) jwtProperties.getRefreshTokenValidityInSeconds());
-        return cookie;
+        return createCookie(
+            jwtProperties.getRefreshTokenCookieName(),
+            token,
+            jwtProperties.getRefreshTokenValidityInSeconds()
+        );
     }

Also applies to: 29-34

[coderabbitai]

🛠️ Refactor suggestion

⚠️ Potential issue

만료된 쿠키 생성 로직 중복 제거 및 보안 설정 강화 필요

만료된 쿠키 생성 로직도 중복되어 있으며, SameSite 속성 설정이 누락되어 있습니다.

다음과 같이 수정하는 것을 제안합니다:

+    private Cookie createExpiredCookie(String name) {
+        Cookie cookie = new Cookie(name, null);
+        cookie.setHttpOnly(true);
+        cookie.setSecure(true);
+        cookie.setPath("/");
+        cookie.setMaxAge(0);
+        cookie.setAttribute("SameSite", "Strict");
+        return cookie;
+    }

     public Cookie createExpiredAuthCookie() {
-        Cookie cookie = new Cookie(jwtProperties.getAccessTokenCookieName(), null);
-        cookie.setHttpOnly(true);
-        cookie.setSecure(true);
-        cookie.setPath("/");
-        cookie.setMaxAge(0);
-        return cookie;
+        return createExpiredCookie(jwtProperties.getAccessTokenCookieName());
     }

     public Cookie createExpiredRefreshCookie() {
-        Cookie cookie = new Cookie(jwtProperties.getRefreshTokenCookieName(), null);
-        cookie.setHttpOnly(true);
-        cookie.setSecure(true);
-        cookie.setPath("/");
-        cookie.setMaxAge(0);
-        return cookie;
+        return createExpiredCookie(jwtProperties.getRefreshTokenCookieName());
     }

Also applies to: 54-59

[coderabbitai]

⚠️ Potential issue

토큰 타입 구분을 위한 claim 추가 필요

액세스 토큰과 리프레시 토큰을 구분할 수 있는 claim이 없어 토큰 유형을 확인할 수 없습니다.

다음과 같이 수정하는 것을 제안합니다:

     public String createAccessToken(String email) {
-        return createToken(email, jwtProperties.getAccessTokenValidityInSeconds());
+        return createToken(email, "ACCESS", jwtProperties.getAccessTokenValidityInSeconds());
     }

     public String createRefreshToken(String email) {
-        return createToken(email, jwtProperties.getRefreshTokenValidityInSeconds());
+        return createToken(email, "REFRESH", jwtProperties.getRefreshTokenValidityInSeconds());
     }

Also applies to: 38-40

[coderabbitai]

🛠️ Refactor suggestion

리프레시 토큰 테스트 케이스 보완이 필요합니다.

현재 테스트는 리프레시 토큰 생성만 검증하고 있습니다. 다음 시나리오에 대한 테스트를 추가해주세요:

• 리프레시 토큰 만료 시나리오
• 리프레시 토큰을 통한 액세스 토큰 갱신
• 잘못된 리프레시 토큰 처리

테스트 케이스 구현에 도움이 필요하시다면 말씀해 주세요.

Also applies to: 88-89

[coderabbitai]

Actionable comments posted: 6

♻️ Duplicate comments (1)

src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (1)

50-75: ⚠️ Potential issue

토큰 타입 구분이 필요합니다.

액세스 토큰과 리프레시 토큰을 구분할 수 있는 claim이 없어 보안상 위험할 수 있습니다.

다음과 같이 수정하는 것을 제안합니다:

-    public String createToken(String email, long validityInSeconds) {
+    public String createToken(String email, String tokenType, long validityInSeconds) {
         try {
             return Jwts.builder()
                     .issuer(jwtProperties.getIssuer())
                     .subject(email)
+                    .claim("type", tokenType)
                     .issuedAt(now)
                     .expiration(validity)
                     .signWith(secretKey)
                     .compact();

🧹 Nitpick comments (3)

src/main/java/com/mycom/socket/auth/security/CookieUtil.java (1)

55-62: 리프레시 토큰 쿠키의 보안 설정 강화 검토

리프레시 토큰은 액세스 토큰보다 더 민감하므로, 다음과 같은 추가 보안 설정을 고려해보세요:

• 더 제한적인 쿠키 경로 설정 (예: /api/auth/refresh)
• 별도의 보안 도메인 사용

src/main/java/com/mycom/socket/auth/security/LoginFilter.java (1)

Line range hint 1-93: 전체 아키텍처 개선 제안

현재 구현된 JWT 리프레시 토큰 메커니즘에 대해 다음과 같은 개선사항을 제안드립니다:

1. 리프레시 토큰 저장소 구현

   • 발급된 리프레시 토큰을 데이터베이스나 Redis에 저장하여 추적
   • 토큰 재사용 탐지 및 차단 가능

2. 토큰 회전(Rotation) 정책 도입

   • 리프레시 토큰 사용 시 새로운 리프레시 토큰 발급
   • 이전 리프레시 토큰 무효화

3. 토큰 취소(Revocation) 메커니즘 구현

   • 사용자 로그아웃 또는 보안 위협 시 토큰 무효화 가능

src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (1)

Line range hint 109-142: 중복 코드 제거가 필요합니다.

createParser() 메소드가 있음에도 여러 메소드에서 파서를 중복 생성하고 있습니다. 코드 재사용성을 높이기 위해 createParser()를 활용하세요.

다음과 같이 수정하는 것을 제안합니다:

     private Date getExpirationFromToken(String token) {
-        return Jwts.parser()
-                .verifyWith(secretKey)
-                .build()
+        return createParser()
                 .parseSignedClaims(token)
                 .getPayload()
                 .getExpiration();
     }

     public String getEmail(String token) {
-        return Jwts.parser()
-                .verifyWith(secretKey)
-                .requireIssuer(jwtProperties.getIssuer())
-                .build()
+        return createParser()
                 .parseSignedClaims(token)
                 .getPayload()
                 .getSubject();
     }

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 49b9c5f and 230cb35.

📒 Files selected for processing (5)

• src/main/java/com/mycom/socket/auth/controller/RefreshController.java (1 hunks)
• src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (2 hunks)
• src/main/java/com/mycom/socket/auth/security/CookieUtil.java (1 hunks)
• src/main/java/com/mycom/socket/auth/security/LoginFilter.java (3 hunks)
• src/main/java/com/mycom/socket/auth/service/AuthService.java (4 hunks)

🔇 Additional comments (7)

src/main/java/com/mycom/socket/auth/security/CookieUtil.java (2)

39-46: 구현이 깔끔하고 적절합니다!

공통 메서드를 활용하여 중복 코드를 제거하고, 명확한 매개변수 전달로 가독성이 좋습니다.

---

71-72: 만료된 쿠키 처리가 적절합니다!

보안 플래그를 강제로 true로 설정하고 공통 메서드를 활용하여 안전하게 구현되었습니다.

src/main/java/com/mycom/socket/auth/service/AuthService.java (2)

32-32: 의존성 주입이 올바르게 구현되었습니다!

final 키워드와 생성자 주입 방식을 사용하여 불변성을 보장하고 있습니다.

---

51-61: 토큰 만료 시간 검증이 필요합니다.

리프레시 토큰과 액세스 토큰의 구현이 잘 되어있으나, 보안을 위해 다음 사항들을 확인해주세요:

1. 리프레시 토큰의 유효 기간이 액세스 토큰보다 길게 설정되어 있는지 확인
2. 토큰 만료 시간이 보안 정책에 부합하는지 검토

src/main/java/com/mycom/socket/auth/security/LoginFilter.java (1)

32-32: 의존성 주입이 올바르게 구현되었습니다!

JWTProperties를 통한 토큰 유효 기간 설정이 잘 구현되었습니다.

src/main/java/com/mycom/socket/auth/controller/RefreshController.java (2)

19-25: 의존성 주입이 적절히 구성되었습니다!

필요한 모든 의존성이 생성자 주입을 통해 올바르게 주입되었습니다.

---

51-60: 리프레시 토큰 추출 로직이 잘 구현되었습니다!

Optional을 활용한 null 처리와 함수형 프로그래밍 스타일이 잘 적용되었습니다.

[coderabbitai]

🛠️ Refactor suggestion

보안 강화를 위한 SameSite 속성 추가 필요

쿠키 생성 시 CSRF 공격 방지를 위해 SameSite 속성을 추가하는 것이 좋습니다.

    private Cookie createCookie(String name, String value, long maxAge, boolean secure) {
        Cookie cookie = new Cookie(name, value);
        cookie.setHttpOnly(true);
        cookie.setSecure(secure);
        cookie.setPath("/");
        cookie.setMaxAge((int) maxAge);
+       cookie.setAttribute("SameSite", "Strict");
        return cookie;
    }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	private Cookie createCookie(String name, String value, long maxAge, boolean secure) {
	Cookie cookie = new Cookie(name, value);
	cookie.setHttpOnly(true);
	cookie.setSecure(jwtProperties.isSecureCookie());
	cookie.setSecure(secure);
	cookie.setPath("/");
	cookie.setMaxAge((int) jwtProperties.getAccessTokenValidityInSeconds());
	cookie.setMaxAge((int) maxAge);
	return cookie;
	}
	private Cookie createCookie(String name, String value, long maxAge, boolean secure) {
	Cookie cookie = new Cookie(name, value);
	cookie.setHttpOnly(true);
	cookie.setSecure(secure);
	cookie.setPath("/");
	cookie.setMaxAge((int) maxAge);
	cookie.setAttribute("SameSite", "Strict");
	return cookie;
	}

[coderabbitai]

🛠️ Refactor suggestion

로그아웃 보안 강화가 필요합니다.

토큰 무효화 구현이 잘 되어있으나, 다음과 같은 보안 개선사항을 고려해주세요:

1. 쿠키 속성 검증 (Secure, HttpOnly, SameSite)
2. 서버 측 토큰 블랙리스트 관리 추가

 public void logout(HttpServletResponse response) {
+    // 서버 측 토큰 블랙리스트에 추가하는 로직
+    tokenBlacklistService.addToBlacklist(getCurrentAccessToken());
+    tokenBlacklistService.addToBlacklist(getCurrentRefreshToken());
+
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getAccessTokenCookieName()));
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getRefreshTokenCookieName()));
 }

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

🛠️ Refactor suggestion

토큰 보안 강화가 필요합니다.

현재 액세스 토큰과 리프레시 토큰이 동일한 클레임을 사용하고 있습니다. 보안 강화를 위해 다음 사항들을 고려해주세요:

1. 리프레시 토큰에는 최소한의 클레임만 포함
2. 토큰 타입을 구분하는 클레임 추가
3. 리프레시 토큰의 식별자를 데이터베이스에 저장하여 추적

 String accessToken = jwtUtil.createToken(
         member.getEmail(),
-        jwtProperties.getAccessTokenValidityInSeconds()
+        jwtProperties.getAccessTokenValidityInSeconds(),
+        Map.of("type", "ACCESS_TOKEN")
 );
 String refreshToken = jwtUtil.createToken(
         member.getEmail(),
-        jwtProperties.getRefreshTokenValidityInSeconds()
+        jwtProperties.getRefreshTokenValidityInSeconds(),
+        Map.of("type", "REFRESH_TOKEN")
 );

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

💡 Codebase verification

쿠키 보안 설정이 불완전합니다.

다음과 같은 보안 문제가 발견되었습니다:

• SameSite 속성이 설정되어 있지 않아 CSRF 공격에 취약할 수 있습니다.
• Path가 "/"로 설정되어 있어 필요 이상으로 넓은 범위에 쿠키가 노출됩니다.

수정이 필요한 파일:

• src/main/java/com/mycom/socket/auth/security/CookieUtil.java

권장 사항:

1. SameSite=Strict 또는 Lax 속성 추가
2. 애플리케이션의 실제 요구사항에 맞게 Path 범위 축소
3. 운영 환경에서 Secure 플래그가 반드시 활성화되도록 설정 검토

🔗 Analysis chain

쿠키 보안 설정을 확인해주세요.

쿠키 생성 시 다음 보안 속성들이 올바르게 설정되어 있는지 확인이 필요합니다:

• HttpOnly
• Secure
• SameSite
• Path

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# CookieUtil의 구현을 확인하여 보안 설정 검증
rg -A 10 "createAuthCookie|createRefreshCookie" --type java

Length of output: 8548

---

Script:

#!/bin/bash
# Check createCookie implementation and JwtProperties
echo "=== CookieUtil.createCookie implementation ==="
ast-grep --pattern 'createCookie($$$) { $$$ }'

echo -e "\n=== JwtProperties configuration ==="
rg -A 5 "class JwtProperties" --type java

Length of output: 282

---

Script:

#!/bin/bash
# 쿠키 생성 메소드와 설정 파일 검색
echo "=== Cookie creation implementation ==="
rg -A 15 "private.*createCookie" --type java

echo -e "\n=== Security and JWT configuration ==="
fd -e yml -e properties -e yaml | xargs rg -l "jwt|cookie|secure"

Length of output: 1755

[coderabbitai]

⚠️ Potential issue

보안 개선이 필요합니다.

다음 보안 관련 사항들을 고려해주세요:

1. CSRF 보호가 필요합니다. @CrossOrigin 설정이나 CSRF 토큰 검증을 추가하세요.
2. 토큰 재발급 엔드포인트에 대한 rate limiting이 필요합니다.
3. 토큰 재발급 시도 실패에 대한 감사(audit) 로깅이 필요합니다.

다음과 같이 rate limiting을 추가하는 것을 제안합니다:

+    @RateLimiter(name = "refreshToken", fallbackMethod = "refreshTokenFallback")
     @PostMapping("/refresh")
     public TokenResponse refreshAccessToken(...)

그리고 실패한 시도에 대한 로깅을 추가하세요:

     } catch (JwtException e) {
+        log.warn("Failed refresh token attempt for IP: {}", request.getRemoteAddr());
         response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getRefreshTokenCookieName()));
         throw new BadRequestException("유효하지 않은 리프레시 토큰입니다. 다시 로그인해주세요.");
     }

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

🛠️ Refactor suggestion

토큰 검증 로직 강화가 필요합니다.

현재 구현은 기본적인 검증만 수행하고 있습니다. 다음 검증 항목들을 추가하는 것을 권장합니다:

1. 토큰 타입 검증
2. NBF (Not Before) 클레임 검증
3. 토큰 블랙리스트 확인

다음과 같이 수정하는 것을 제안합니다:

     public boolean validateToken(String token) {
         try {
-            Jwts.parser()
+            var claims = Jwts.parser()
                     .verifyWith(secretKey)
                     .requireIssuer(jwtProperties.getIssuer())
                     .build()
-                    .parseSignedClaims(token);
+                    .parseSignedClaims(token)
+                    .getPayload();
+
+            // 토큰 타입 검증
+            String tokenType = claims.get("type", String.class);
+            if (tokenType == null) {
+                return false;
+            }
+
+            // NBF 검증
+            Date nbf = claims.getNotBefore();
+            if (nbf != null && nbf.after(new Date())) {
+                return false;
+            }

Committable suggestion skipped: line range outside the PR's diff.

[coderabbitai]

Actionable comments posted: 6

♻️ Duplicate comments (1)

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

109-115: ⚠️ Potential issue

로그아웃 보안 강화가 필요합니다.

이전 리뷰에서 제기된 보안 문제가 아직 해결되지 않았습니다. 현재 구현은 클라이언트 측 쿠키만 무효화하고 있어, 탈취된 토큰의 악용 가능성이 있습니다.

다음 보안 개선사항을 반드시 구현해주세요:

1. 서버 측 토큰 블랙리스트 관리
2. 쿠키 보안 속성 설정 (Secure, HttpOnly, SameSite)

 public void logout(HttpServletResponse response) {
+    // 서버 측 토큰 블랙리스트에 추가
+    String currentAccessToken = getCurrentAccessToken();
+    String currentRefreshToken = getCurrentRefreshToken();
+    
+    if (currentAccessToken != null) {
+        tokenBlacklistService.addToBlacklist(currentAccessToken);
+    }
+    if (currentRefreshToken != null) {
+        tokenBlacklistService.addToBlacklist(currentRefreshToken);
+    }
+
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getAccessTokenCookieName()));
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getRefreshTokenCookieName()));
 }

🧹 Nitpick comments (4)

src/main/java/com/mycom/socket/auth/security/CookieUtil.java (1)

23-31: 쿠키 보안 설정 개선 필요

보안성 강화를 위해 다음 사항들을 고려해주세요:

1. 쿠키의 도메인을 명시적으로 설정하는 것이 좋습니다.
2. 프로덕션 환경에서는 secure 플래그를 항상 true로 설정하는 것이 권장됩니다.

    private Cookie createCookie(String name, String value, long maxAge, boolean secure) {
        Cookie cookie = new Cookie(name, value);
        cookie.setHttpOnly(true);
        cookie.setSecure(secure);
        cookie.setPath("/api/auth");
+       cookie.setDomain(jwtProperties.getCookieDomain());
        cookie.setMaxAge((int) maxAge);
        cookie.setAttribute("SameSite", "Strict");
        return cookie;
    }

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

Line range hint 1-117: JWT 리프레시 구현을 위한 추가 기능이 필요합니다.

현재 구현에서 다음과 같은 중요한 기능들이 누락되어 있습니다:

1. 토큰 리프레시 엔드포인트
2. 토큰 만료 확인 및 처리
3. 리프레시 토큰 재사용 감지

다음과 같은 메소드들의 추가 구현을 제안드립니다:

/**
 * 액세스 토큰 갱신
 * 유효한 리프레시 토큰을 사용하여 새로운 액세스 토큰 발급
 */
public String refreshAccessToken(String refreshToken) {
    // 리프레시 토큰 유효성 검증
    // 토큰 재사용 확인
    // 새로운 액세스 토큰 발급
}

/**
 * 토큰 유효성 검증
 * 토큰의 서명, 만료 여부, 블랙리스트 여부 확인
 */
public boolean validateToken(String token, String tokenType) {
    // 토큰 유효성 검증 로직
}

src/main/java/com/mycom/socket/auth/dto/response/TokenResponse.java (1)

3-11: 불필요한 필드 제거 권장

success 필드는 accessToken이 null인지 여부로 판단할 수 있어 중복됩니다. 다음과 같이 수정하는 것을 제안합니다:

public record TokenResponse(
        String accessToken,
-       String message,
-       boolean success
+       String message
) {
    public static TokenResponse of(String message) {
-       return new TokenResponse(null, message, false);
+       return new TokenResponse(null, message);
    }
}

src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (1)

123-130: 토큰 만료 시간 추출 메서드 개선 필요

getExpirationFromToken 메서드가 createParser()를 사용하지 않아 일관성이 떨어집니다. 다음과 같이 수정하는 것을 제안합니다:

 private Date getExpirationFromToken(String token) {
-    return Jwts.parser()
-            .verifyWith(secretKey)
-            .build()
+    return createParser()
             .parseSignedClaims(token)
             .getPayload()
             .getExpiration();
 }

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 230cb35 and 608a2e9.

📒 Files selected for processing (7)

• src/main/java/com/mycom/socket/auth/controller/RefreshController.java (1 hunks)
• src/main/java/com/mycom/socket/auth/dto/response/TokenResponse.java (1 hunks)
• src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java (2 hunks)
• src/main/java/com/mycom/socket/auth/security/CookieUtil.java (1 hunks)
• src/main/java/com/mycom/socket/auth/security/LoginFilter.java (3 hunks)
• src/main/java/com/mycom/socket/auth/service/AuthService.java (4 hunks)
• src/test/java/com/mycom/socket/member/service/LoginTest.java (4 hunks)

🔇 Additional comments (8)

src/main/java/com/mycom/socket/auth/security/LoginFilter.java (3)

4-4: 구조적 변경이 잘 이루어졌습니다!

JWT 속성 관리를 위한 의존성 주입이 깔끔하게 구현되었습니다.

Also applies to: 32-32

---

69-72: 쿠키 보안 설정이 불완전합니다.

이전 리뷰에서 지적된 쿠키 보안 문제가 아직 해결되지 않았습니다:

• SameSite 속성 미설정
• Path가 너무 광범위하게 설정됨

다음 보안 설정을 추가해주세요:

1. SameSite=Strict 설정
2. Path 범위 최소화
3. Secure 플래그 활성화

---

56-66: ⚠️ Potential issue

토큰 생성 로직 개선이 필요합니다.

다음과 같은 개선사항을 제안드립니다:

1. 토큰 타입을 문자열 리터럴 대신 상수나 enum으로 정의
2. 액세스 토큰과 리프레시 토큰의 클레임을 분리하여 보안 강화

다음과 같이 수정해주세요:

+private static final String TOKEN_TYPE_ACCESS = "ACCESS_TOKEN";
+private static final String TOKEN_TYPE_REFRESH = "REFRESH_TOKEN";

 String accessToken = jwtUtil.createToken(
         member.getEmail(),
         jwtProperties.getAccessTokenValidityInSeconds(),
-        "ACCESS_TOKEN"
+        TOKEN_TYPE_ACCESS,
+        Map.of("roles", member.getRoles())  // 액세스 토큰에만 권한 정보 포함
 );
 String refreshToken = jwtUtil.createToken(
         member.getEmail(),
         jwtProperties.getRefreshTokenValidityInSeconds(),
-        "REFRESH_TOKEN"
+        TOKEN_TYPE_REFRESH
 );

Likely invalid or redundant comment.

src/main/java/com/mycom/socket/auth/security/CookieUtil.java (2)

34-47: 구현이 잘 되었습니다!

메소드가 잘 문서화되어 있고, 공통 로직을 적절히 재사용하고 있습니다.

---

65-73: 구현이 적절합니다!

만료된 쿠키 생성 시 보안 설정이 적절하게 되어있고, 문서화도 잘 되어있습니다.

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

32-32: 의존성 주입이 올바르게 구현되었습니다.

JWTProperties를 통한 토큰 설정 관리가 잘 구조화되어 있습니다.

src/main/java/com/mycom/socket/auth/controller/RefreshController.java (2)

35-39: ⚠️ Potential issue

토큰 검증 실패 시 로깅 추가 필요

보안 감사를 위해 실패한 토큰 검증 시도를 로깅해야 합니다:

 String refreshToken = refreshTokenOpt.get();
 if (!jwtUtil.validateToken(refreshToken, "REFRESH_TOKEN")) {
+    log.warn("Invalid refresh token attempt from IP: {}", request.getRemoteAddr());
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getRefreshTokenCookieName()));
     return TokenResponse.of("유효하지 않은 리프레시 토큰입니다. 다시 로그인해주세요.");
 }

Likely invalid or redundant comment.

---

28-29: ⚠️ Potential issue

보안 강화 필요

다음 보안 기능들을 추가해야 합니다:

1. CSRF 보호
2. Rate limiting
3. 실패한 토큰 갱신 시도에 대한 감사 로깅

+@Slf4j
+@RateLimiter(name = "refreshToken")
 @PostMapping("/refresh")
 public TokenResponse refreshAccessToken(...)

Likely invalid or redundant comment.

[coderabbitai]

💡 Codebase verification

토큰 유효기간 검증 로직 구현 방안

리프레시 토큰의 유효 기간이 액세스 토큰보다 길도록 보장하기 위해 다음과 같은 검증 로직 추가를 제안드립니다:

• @PostConstruct를 사용하여 초기화 시점에 토큰 유효기간을 검증
• Bean Validation을 활용하여 각 필드의 최소값 검증 (@Min)
• refreshTokenValidityInSeconds가 accessTokenValidityInSeconds보다 큰지 확인하는 커스텀 유효성 검사 추가

🔗 Analysis chain

리프레시 토큰 유효 기간 검증 추가 고려

리프레시 토큰의 유효 기간이 액세스 토큰보다 길게 설정되었는지 확인하는 검증 로직 추가를 고려해보세요.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# JWTProperties에서 토큰 유효 기간 설정을 확인
rg "tokenValidityInSeconds|refreshTokenValidityInSeconds" -A 2

Length of output: 383

---

Script:

#!/bin/bash
# Get complete JWTProperties class
cat src/main/java/com/mycom/socket/auth/config/JWTProperties.java

# Check application properties/yaml files
fd -e yml -e yaml -e properties --exec cat {}

Length of output: 1162

[coderabbitai]

⚠️ Potential issue

토큰 생성 로직에 중요한 보안 문제가 있습니다.

다음과 같은 문제점들이 발견되었습니다:

1. 리프레시 토큰의 타입이 잘못 설정되어 있습니다 ("ACCESS_TOKEN" 대신 "REFRESH_TOKEN" 사용 필요)
2. 토큰 생성 순서가 보안에 취약할 수 있습니다 (액세스 토큰을 먼저 생성하는 것이 권장됨)

다음과 같이 수정해주세요:

-        String refreshToken = jwtUtil.createToken(member.getEmail(),
-                jwtProperties.getRefreshTokenValidityInSeconds(), "ACCESS_TOKEN");
-
-        Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
-        response.addCookie(refreshTokenCookie);
-
-        String accessToken = jwtUtil.createToken(member.getEmail(),
-                jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
-
-        Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
-        response.addCookie(accessTokenCookie);
+        // 먼저 액세스 토큰 생성
+        String accessToken = jwtUtil.createToken(member.getEmail(),
+                jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
+        Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
+        
+        // 그 다음 리프레시 토큰 생성
+        String refreshToken = jwtUtil.createToken(member.getEmail(),
+                jwtProperties.getRefreshTokenValidityInSeconds(), "REFRESH_TOKEN");
+        Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
+        
+        // 쿠키 설정
+        response.addCookie(accessTokenCookie);
+        response.addCookie(refreshTokenCookie);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	String refreshToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getRefreshTokenValidityInSeconds(), "ACCESS_TOKEN");
	Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
	response.addCookie(refreshTokenCookie);
	String accessToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
	Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
	response.addCookie(accessTokenCookie);
	// 먼저 액세스 토큰 생성
	String accessToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
	Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
	// 그 다음 리프레시 토큰 생성
	String refreshToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getRefreshTokenValidityInSeconds(), "REFRESH_TOKEN");
	Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
	// 쿠키 설정
	response.addCookie(accessTokenCookie);
	response.addCookie(refreshTokenCookie);

[coderabbitai]

💡 Codebase verification

토큰 관리 보안 취약점 확인됨

현재 구현에서 다음과 같은 보안 취약점이 발견되었습니다:

• 이전 리프레시 토큰이 무효화되지 않아 재사용 가능
• Redis가 구성되어 있으나 토큰 관리에 활용되지 않음
• 동시 토큰 갱신 요청에 대한 처리 로직 부재

권장 사항:

1. Redis를 활용한 토큰 블랙리스트 구현
2. 리프레시 토큰 재발급 시 이전 토큰 즉시 무효화
3. 토큰 발급 이력 추적을 위한 저장소 구현
4. 동시성 제어를 위한 락(Lock) 메커니즘 도입

🔗 Analysis chain

토큰 재발급 로직 검증 필요

새로운 토큰 발급 시 다음 사항들을 확인해야 합니다:

1. 이전 리프레시 토큰 무효화
2. 토큰 발급 이력 추적
3. 동시 토큰 갱신 요청 처리

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for token revocation implementation
rg -l "TokenRevocationService|BlacklistService|InvalidatedTokenRepository"

Length of output: 76

---

Script:

#!/bin/bash
# Search for token-related implementations with broader patterns
rg -l "token.*repository|token.*service|token.*cache|token.*store"

# Search for security configurations
rg -l "SecurityConfig|WebSecurityConfig|JwtConfig"

# Search for Redis or cache configurations
rg -l "RedisConfig|CacheConfig|TokenCache"

Length of output: 364

---

Script:

#!/bin/bash
# Check Redis configuration implementation
cat src/main/java/com/mycom/socket/global/config/RedisConfig.java

# Check security configuration for token handling
cat src/main/java/com/mycom/socket/auth/config/SecurityConfig.java

# Search for Redis usage in token operations
rg -g "!*.{test,spec}.*" "redisTemplate|StringRedisTemplate" -A 3

Length of output: 7750

[coderabbitai]

🛠️ Refactor suggestion

리프레시 토큰 테스트 케이스 보완 필요

다음 테스트 케이스들을 추가해야 합니다:

1. 리프레시 토큰 만료 시나리오
2. 리프레시 토큰을 통한 액세스 토큰 갱신
3. 잘못된 리프레시 토큰 처리
4. 토큰 타입 검증

@Test
void 리프레시토큰_만료() {
    // given
    String expiredToken = "expired.refresh.token";
    when(jwtUtil.validateToken(expiredToken, "REFRESH_TOKEN")).thenReturn(false);
    
    // when & then
    assertThrows(BadRequestException.class, 
        () -> authService.refreshAccessToken(expiredToken));
}

Also applies to: 76-76, 88-89

[coderabbitai]

🛠️ Refactor suggestion

토큰 생성 보안 강화 필요

토큰 생성 시 다음 보안 기능들을 추가해야 합니다:

1. 토큰 ID (jti) 클레임 추가
2. Not Before (nbf) 클레임 추가
3. 토큰 용도별 청중(aud) 구분

 return Jwts.builder()
     .issuer(jwtProperties.getIssuer())
     .subject(email)
     .issuedAt(now)
     .expiration(validity)
     .claim("type", accessToken)
+    .id(UUID.randomUUID().toString())
+    .notBefore(now)
+    .audience()
+        .add(accessToken.toLowerCase())
+        .and()
     .signWith(secretKey)
     .compact();

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	public String createToken(String email, long validityInSeconds, String accessToken) {
	Date now = new Date();
	Date validity = new Date(now.getTime() +
	(jwtProperties.getAccessTokenValidityInSeconds() * 1000));
	return Jwts.builder()
	.issuer(jwtProperties.getIssuer())
	.subject(email)
	.issuedAt(now)
	.expiration(validity)
	.signWith(secretKey)
	.compact();
	Date validity = new Date(now.getTime() + (validityInSeconds * 1000));
	try {
	return Jwts.builder()
	.issuer(jwtProperties.getIssuer())
	.subject(email)
	.issuedAt(now)
	.expiration(validity)
	.claim("type", accessToken)
	.signWith(secretKey)
	.compact();
	} catch (JwtException e) {
	log.error("토큰 생성 중 오류가 발생했습니다.", e);
	throw new IllegalStateException("토큰 생성 중 오류가 발생했습니다.", e);
	}
	public String createToken(String email, long validityInSeconds, String accessToken) {
	Date now = new Date();
	Date validity = new Date(now.getTime() + (validityInSeconds * 1000));
	try {
	return Jwts.builder()
	.issuer(jwtProperties.getIssuer())
	.subject(email)
	.issuedAt(now)
	.expiration(validity)
	.claim("type", accessToken)
	.id(UUID.randomUUID().toString())
	.notBefore(now)
	.audience()
	.add(accessToken.toLowerCase())
	.and()
	.signWith(secretKey)
	.compact();
	} catch (JwtException e) {
	log.error("토큰 생성 중 오류가 발생했습니다.", e);
	throw new IllegalStateException("토큰 생성 중 오류가 발생했습니다.", e);
	}

[coderabbitai]

💡 Codebase verification

토큰 보안 강화 권장사항 확인

리뷰 의견에서 제시된 보안 강화 항목들이 현재 구현되어 있지 않음을 확인했습니다. 다음 사항들의 구현을 권장드립니다:

1. Redis를 활용한 토큰 블랙리스트 구현

   • 기존 RedisService에 토큰 무효화 기능 추가
   • 로그아웃 시 토큰 블랙리스트 등록

2. NBF (Not Before) 클레임 추가

   • JWTUtil의 토큰 생성 시 .notBefore() 설정
   • validateToken() 메소드에서 자동 검증됨

3. 토큰 ID (jti) 클레임 추가 및 추적

   • 토큰 생성 시 고유 ID 부여
   • Redis를 활용해 사용된 토큰 ID 추적

🔗 Analysis chain

토큰 검증 로직 강화 필요

다음 검증 항목들을 추가해야 합니다:

1. 토큰 블랙리스트 확인
2. NBF (Not Before) 클레임 검증
3. 토큰 ID 중복 사용 확인

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check for token blacklist implementation
rg -l "TokenBlacklist|RevokedToken|InvalidatedToken"

Length of output: 54

---

Script:

#!/bin/bash
# Search for Redis/Cache configurations and JWT-related security implementations
rg -l "Redis|Cache|TokenStore"

# Search for JWT claim handling
rg -A 5 "\.claim\(|\.getClaim|jti|nbf" 

# Search for security configuration files
fd -e java -e xml -e properties -e yml "Security|Auth|JWT" --type f

Length of output: 1424

---

Script:

#!/bin/bash
# Check Redis service implementation for token operations
cat src/main/java/com/mycom/socket/global/service/RedisService.java

# Check security configuration
cat src/main/java/com/mycom/socket/auth/config/SecurityConfig.java

Length of output: 5402

[coderabbitai]

Actionable comments posted: 2

♻️ Duplicate comments (1)

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

113-119: 🛠️ Refactor suggestion

로그아웃 보안 강화가 필요합니다.

토큰 무효화 구현이 잘 되어있으나, 다음과 같은 보안 개선사항을 고려해주세요:

1. 쿠키 속성 검증 (Secure, HttpOnly, SameSite)
2. 서버 측 토큰 블랙리스트 관리 추가

 public void logout(HttpServletResponse response) {
+    // 서버 측 토큰 블랙리스트에 추가하는 로직
+    tokenBlacklistService.addToBlacklist(getCurrentAccessToken());
+    tokenBlacklistService.addToBlacklist(getCurrentRefreshToken());
+
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getAccessTokenCookieName()));
     response.addCookie(cookieUtil.createExpiredCookie(jwtProperties.getRefreshTokenCookieName()));
 }

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d2e5305 and f16eaec.

📒 Files selected for processing (1)

• src/main/java/com/mycom/socket/auth/service/AuthService.java (4 hunks)

🔇 Additional comments (1)

src/main/java/com/mycom/socket/auth/service/AuthService.java (1)

3-3: 의존성 주입이 적절히 구현되었습니다.

JWT 설정을 관리하기 위한 JWTProperties 의존성 주입이 잘 되어있습니다.

Also applies to: 32-32

[coderabbitai]

⚠️ Potential issue

심각한 토큰 생성 로직 오류가 발견되었습니다.

다음과 같은 치명적인 문제점들이 있습니다:

1. 액세스 토큰이 리프레시 토큰의 유효 기간을 사용하고 있습니다
2. 리프레시 토큰이 액세스 토큰의 유효 기간을 사용하고 있습니다
3. 쿠키 생성 시 토큰이 잘못 전달되고 있습니다
4. 토큰 타입이 잘못 지정되어 있습니다

다음과 같이 수정해주세요:

-        // 먼저 액세스 토큰 생성
-        String accessToken = jwtUtil.createToken(member.getEmail(),
-                jwtProperties.getRefreshTokenValidityInSeconds(), "ACCESS_TOKEN");
-
-        Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(accessToken);
-
-        // 그 다음 리프레시 토큰 생성
-        String refreshToken = jwtUtil.createToken(member.getEmail(),
-                jwtProperties.getAccessTokenValidityInSeconds(), "REFRESH_TOKEN");
-
-        Cookie accessTokenCookie = cookieUtil.createAuthCookie(refreshToken);
-
-        // 쿠키 설정
-        response.addCookie(refreshTokenCookie);
-        response.addCookie(accessTokenCookie);
+        // 액세스 토큰 생성
+        String accessToken = jwtUtil.createToken(member.getEmail(),
+                jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
+        Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
+
+        // 리프레시 토큰 생성
+        String refreshToken = jwtUtil.createToken(member.getEmail(),
+                jwtProperties.getRefreshTokenValidityInSeconds(), "REFRESH_TOKEN");
+        Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
+
+        // 쿠키 설정
+        response.addCookie(accessTokenCookie);
+        response.addCookie(refreshTokenCookie);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// // 먼저 액세스 토큰 생성
	String accessToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getRefreshTokenValidityInSeconds(), "ACCESS_TOKEN");
	Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(accessToken);
	// 그 다음 리프레시 토큰 생성
	String refreshToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getAccessTokenValidityInSeconds(), "REFRESH_TOKEN");
	Cookie accessTokenCookie = cookieUtil.createAuthCookie(refreshToken);
	// 쿠키 설정
	response.addCookie(refreshTokenCookie);
	response.addCookie(accessTokenCookie);
	// 액세스 토큰 생성
	String accessToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getAccessTokenValidityInSeconds(), "ACCESS_TOKEN");
	Cookie accessTokenCookie = cookieUtil.createAuthCookie(accessToken);
	// 리프레시 토큰 생성
	String refreshToken = jwtUtil.createToken(member.getEmail(),
	jwtProperties.getRefreshTokenValidityInSeconds(), "REFRESH_TOKEN");
	Cookie refreshTokenCookie = cookieUtil.createRefreshCookie(refreshToken);
	// 쿠키 설정
	response.addCookie(accessTokenCookie);
	response.addCookie(refreshTokenCookie);

---

💡 Codebase verification

🛠️ Refactor suggestion

리프레시 토큰 보안 취약점이 확인되었습니다.

현재 구현에서 다음과 같은 보안 취약점이 발견되었습니다:

1. 리프레시 토큰 재사용 감지 메커니즘이 없습니다.

   • 탈취된 리프레시 토큰의 악용을 방지할 수 없습니다.

2. 토큰 교체(Rotation) 시 이전 토큰의 무효화가 이루어지지 않습니다.

   • Member 엔티티의 updateRefreshToken만으로는 충분한 보안을 제공하지 않습니다.

3. 리프레시 토큰 블랙리스트나 토큰 계보 추적이 구현되어 있지 않습니다.

   • /refresh 엔드포인트에서 새로운 토큰 발급 시 이전 토큰의 추적이 불가능합니다.

다음 보안 기능의 추가를 권장드립니다:

• 리프레시 토큰 사용 시 이전 토큰 즉시 무효화
• 토큰 계보(family) 추적을 통한 재사용 감지
• 리프레시 토큰 블랙리스트 관리

🔗 Analysis chain

리프레시 토큰 보안 강화가 필요합니다.

리프레시 토큰의 보안을 강화하기 위해 다음 기능들의 구현을 고려해주세요:

1. 리프레시 토큰 교체 (Rotation)
2. 리프레시 토큰 재사용 감지
3. 리프레시 토큰 만료 시간 검증

리프레시 토큰 구현이 적절한지 확인하기 위해 다음 검증을 실행합니다:

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify refresh token implementation completeness

# Check for token rotation implementation
echo "Checking for token rotation..."
rg -l 'refreshToken.*rotation|rotateRefreshToken|updateRefreshToken'

# Check for token reuse detection
echo "Checking for reuse detection..."
rg -l 'tokenReuse|detectReuse|validateRefreshToken'

# Check for proper token validation
echo "Checking for token validation..."
rg -l 'validateToken|verifyToken|checkToken'

Length of output: 628

---

Script:

#!/bin/bash
# Check the actual implementation details

echo "=== Member.java refresh token handling ==="
rg -A 10 -B 10 'refreshToken' src/main/java/com/mycom/socket/go_socket/entity/Member.java

echo -e "\n=== RefreshController implementation ==="
cat src/main/java/com/mycom/socket/auth/controller/RefreshController.java

echo -e "\n=== JWTUtil token validation ==="
rg -A 5 'validateToken|verifyToken|checkToken' src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java

Length of output: 4082

---

Script:

#!/bin/bash
# Get complete JWTUtil implementation
echo "=== Complete JWTUtil implementation ==="
cat src/main/java/com/mycom/socket/auth/jwt/JWTUtil.java

Length of output: 4497