로그인 및 JWT 관리를 어떻게 해야할까요?

[f1v3-dev]

현재 상황

현재 구현되어있는 방식

• Refresh Token: Cookie
• Access Token: Authorization Header로 클라이언트 측으로 전달

현재 재발급("/api/v1/auth/reissue") 과정에서, AT만 새로 발급을 하고 RT는 그대로 사용하는 방식으로 구현이 되어있습니다.
이러한 경우에 문제가 발생할 것 같은데 어떠한 보안상 결함이 있을까요?

[RTUnu12]

    @GetMapping("/reissue")
    public ResponseEntity<Void> reissueToken(@CookieValue(value = "refresh_token", required = false) String refreshToken,
                                             HttpServletResponse response) {

        if (Strings.isEmpty(refreshToken) || blacklistService.isTokenBlacklisted(refreshToken)) {
            return ResponseEntity.status(HttpStatus.UNAUTHORIZED).build();
        }

        String newAccessToken = authService.reissueToken(refreshToken);
        response.setHeader("Authorization", newAccessToken);
        return ResponseEntity.ok().build();
    }

현재 코드를 보면

1. RT가 유효하고 블랙리스트인지를 검사한다.
2. AT를 재발급하고 보낸다.

RT를 재발급하지 않을 경우 문제가 발생할 것 같다고 하셨는데, 블랙리스트인지를 검사하니까 괜찮지 않나라고 생각했는데,
블랙리스트 등재 기준이 로그아웃 시일 경우 하나라, 탈취 위험이 있기는 하네요.

해커가 블랙리스트 등재되지 않은 토큰을 탈취 후 사용해도 그 토큰은 로그아웃 하지 않는 이상 블랙리스트가 아니니 이 부분에 대해서 RT의 재발급이 필요해 보입니다.

[f1v3-dev]

문제 상황

A 사용자의 RT를 B 해커가 탈취한 상황이라고 가정해본다면,
JWT 형태의 Refresh Token은 만료가 될 때 가지 B가 마음대로 사용할 수 있다는 문제점이 존재합니다.

1. A가 재발급 요청을 시도해도 성공
2. B가 재발급 요청을 시도하더라도 성공

해결 방안

재발급 요청시, 다음과 같은 로직으로 변경하면 어떨까 싶어요!

1. 쿠키에 저장되어있는 기존 RT는 블랙리스트화 시킨다.
2. 새로운 AT를 발급함과 동시에, RT도 발급한다.
3. 응답으로 Authorization Header에는 AT를 Cookie에는 RT를 보내준다.

토큰 로테이션 (token rotation) 이라고 부르는 것 같아요

이러한 경우, B(해커)가 탈취한 RT로 재발급 요청을 하더라도 문제가 없어보이긴 합니다.

문제가 없는가?

걱정되는게 있다면, B가 A보다 먼저 재발급 요청을 한다면? 정상 유저의 재발급 요청이 거절될인데 문제가 되지 않을까?

[RTUnu12]

1. 재발급 요청 상황을 자주 만든다. (단순히 어떠한 동작을 했을 때 등등)
2. RT가 그전까지 탈취될 수 없게 만든다.

이긴 한데 1일 경우엔 리이슈 요청이 너무 자주 들어와 서버가 뻗을 가능성이 높고
2일 경우엔 그 방법이 있을까? 싶긴 합니다.

[f1v3-dev]

1번의 상황을 혹시 자세하게 알려주실 수 있나요?

[RTUnu12]

단순히 어떤 정보를 조회했을 때부터 수정/삭제 시에도 계속 리이슈를 하는 방식입니다.

[RTUnu12]

혹시 지금 리이슈의 발생 조건이 무엇인지를 알 수 있나요?

[RTUnu12]

제가 생각할 때 탈취당했다는 트리거가 발생 시 재발급을 즉시 해버리는 게 가장 나은 방안이긴 한데
탈취를 감지하는 트리거를 어떻게 만들지가 고민입니다.

[f1v3-dev]

JwtAuthenticationFilter를 통해서, 검증이 필요한 API (USER_LIST)인 경우에 AT를 검증하는데,
오류가 발생했을 때 401 Unauthorized 를 통해서 해당 오류라면, 프론트 측에서 재발급 요청 API를 호출하는 것으로 알고 있어요

프론트 측에서 미들웨어를 두고, 401일 때 리이슈를 한다 라고 들었던 것 같은데 확실한지는 지현님이나 세빈님에게 여쭤봐야 할 것 같아요

[f1v3-dev]

제가 생각할 때 탈취당했다는 트리거가 발생 시 재발급을 즉시 해버리는 게 가장 나은 방안이긴 한데 탈취를 감지하는 트리거를 어떻게 만들지가 고민입니다.

해커가 탈취를 했다는 것을 알기엔 너무 어렵지 않을까요?

[RTUnu12]

현재 IP를 검사하는 방법이 있기는 한데...이건 윤리적 문제가 존재하고 확연하게 감지할 수 없기도 합니다.

[RTUnu12]

https://mgyo.tistory.com/832

여기 저희가 고민하는 문제를 해결한 분의 글을 정리해보면

A : 정상 유저
B : 해커

RT 탈취 시

• 로테이션으로 해결

RT가 재발급 되기 전에 탈취되어 그 RT가 재발급 될 경우

• A의 RT가 무효화
• Redis로 {key : value = RT : User}로 저장
  • A가 새로 로그인하여 RT1:A 형태로 Redis에 저장]
  • 탈취된 RT도 재발급될 때 RT2:A 형태로 저장
  • 한 유저에 여러 RT가 발급되는 문제 발생

한 명의 사용자가 여러개의 RT를 가지게 되는 경우

• 저장 방식에서 Key와 Value를 바꿔서 저장 -> User에 대응되는 RT를 1개로 제한

1. A가 RT에서 User 정보를 꺼냄
2. User를 Key로 Redis 조회 시 이에 대응되는 Value에 저장된 RT 리턴
3. 조회된 RT는 B가 먼저 재발급한 RT이므로 A가 가지고 있던 RT와 다른 토큰
4. 즉 매칭되지 않으므로 악의적인 침투가 있음을 인지
5. 해당 유저와 대응되는 User:RT 삭제 후 재로그인 하도록 클라이언트 리턴

즉, 탈취 감지 트리거와 승조님이 제시해주신 문제 상황을 이를 통해 해결할 수 있을 것 같습니다.

[RTUnu12]

정확합니다. 괜찮은 방법이라고 생각하시나요?

[f1v3-dev]

괜찮은 것 같아요!

다만, 완벽히 stateless 한 방법은 아닌 것 같다는 점을 저희 둘 다 인지해야 할 것 같아요.
JWT는 stateless 할 수 있지만, 보안을 높이기 위해서 JWT(AT, RT, BT) 를 저장소에 저장을 하게 되는 형태다보니 어쩔 수 없는 트레이드 오프인것 같네요.

[RTUnu12]

그렇습니다. 이 부분은 희생해야 할 부분인거 같아요. Redis로 구현할까요 아님 다른 기반으로 구현할 수 있을까요?

[f1v3-dev]

그렇습니다. 이 부분은 희생해야 할 부분인거 같아요. Redis로 구현할까요 아님 다른 기반으로 구현할 수 있을까요?

어제 말했던 것 처럼 많은 시간을 요구하는 것 같지는 않으니까 DB(MySQL) 기반으로도 해보고 Redis로도 해본 후 둘의 성능을 비교해보는건 어때요? ㅋㅋㅋㅋㅋ

두 방식을 각 브랜치 파서 하나씩 개발을 해보고 비교하면 재밌을 것 같아요

[RTUnu12]

오 좋습니다. 어느 부분을 하실 건가요?

[f1v3-dev]

부하 테스트 결과 (JMeter)

평균 값을 기준으로 합니다.

부하 테스트 결과를 표로 나타내면 다음과 같습니다:

Thread Count	MySQL (ms)	Redis (ms)
1000	700	20
3000	3000	200

장점 정리

1. 빠른 읽기/쓰기 속도: Redis는 메모리 기반 저장소이기 때문에 MySQL보다 훨씬 빠른 읽기 및 쓰기 속도를 제공합니다.
2. TTL 지원: 스케줄링 없이 Redis의 TTL(Time to Live)을 사용하여 자동으로 만료된 토큰을 제거할 수 있습니다.

결론,

기존에 Refresh Token 관리를 MySQL에서 진행하였지만 Redis 로 마이그레이션을 진행합니다.