RTR, 화이트리스트 구현
몬가... 몬가 처음부터 다시 하는 느낌인데... 낡고 지치고 말아...😂
JWT + 블랙리스트 방식
어제 토큰기반 인증 방식을 세션 방식과 비교하면서 "이미 발급된 토큰에 대해 즉각적인 제어를 할 수 없다"는 토큰기반 인증방식의
허점을 보완하기 위해, 블랙리스트와 화이트리스트 도입을 생각해 문서를 작성해 팀에 공유했었다.
처음엔 막연히 JWT가 자체로 정보를 가지고 있으므로, 모든 세션에서 검증을 할 필요가 없다는 이유로 세션 방식보다 우위를 가진다고 알고 있었는데, 게이트웨이에서만 검증을 맡아 게이트웨이 이후로의 모든 요청에 대해서 헤더 정보만을 그대로 믿는 현재 구현 방식에서는 세션 방식도 동일하게 적용할 수 있는 부분이라 성능상 우위가 있나? 싶었다.
AccessToken으로 요청을 보낼 때 블랙리스트에 있는지 조회하는 과정을 거치게 되면, 검증 과정에서 저장소 네트워크 비용이 없다는 토큰인증 방식의 성능 상의 이점을 잃게 되며 JWT 블랙리스트 방식을 사용하는것이 무슨의미가 있는지 팀원의 피드백을 통해 다시 알아보게 되었다.
블랙리스트가 있으면 결국 같다
세션 + Redis:
요청 → Redis 조회 → 인증
AT + 블랙리스트:
요청 → 서명 검증 → Redis 조회 → 인증
JWT 서명 검증: ~0.1ms (CPU 연산)
Redis 조회: ~0.5~2ms (네트워크 왕복, 로컬 기준)
RDB 조회: ~5~20ms (디스크 I/O 포함)오히려 JWT 서명 검증 단계가 추가되니까 세션보다 살짝 더 느려진다.
AT 수명을 15분으로 짧게 유지하면 블랙리스트 없이도 피해를 최소화할 수 있어서,
많은 서비스가 블랙리스트 없이 짧은 수명 + RT만 Redis 관리하는 방식을 택한다.
그럼 블랙리스트 + JWT를 왜 쓰지?
1. Redis 장애 시 fallback 전략 짜기 쉬움
세션 방식 → 서버가 상태를 들고 있음
블랙리스트 JWT → 토큰 자체에 정보가 담겨 있음
→ 마이크로서비스에서 각 서버가
독립적으로 1차 검증 가능
→ Redis 장애 시 fallback 전략 짜기 쉬움
2. "선택적 검증"의 가능성 (Critical Path 분리)
세션 방식은 유저가 누구인지 알기 위해 무조건 Redis를 찍어야 문이 열립니다.
하지만 하이브리드 JWT는 서버가 이미 유저 정보를 알고 있기 때문에, 비즈니스 로직에 따라 조회를 생략하거나 뒤로 미룰 수 있다.
- 일반 요청 (90%): "이 토큰, 우리 서버 비공개키로 서명된 거 맞네? 유저 ID도 들어있고 만료 시간도 남았어. 일단 통과!" → Redis 조회 0회
- 민감 요청 (10%): "결제나 비밀번호 변경이네? 혹시 모르니 블랙리스트에 있는지 Redis 한 번만 확인하자." → Redis 조회 1회
즉, 모든 API에 동일한 비용을 지불해야 하는 세션과 달리, 서비스의 중요도에 따라 네트워크 비용을 지불할지 말지 개발자가 제어권을 갖게 된다.
3. 더 진보된 방식: Bloom Filter (네트워크 요청 생략으로 세션방식보다 성능 우위 유지)
가장 성능에 민감한 곳에서는 Redis를 찌르기 전 서버 메모리에 Bloom Filter라는 자료구조를 두기도 한다.
- 서버 메모리 체크: "이 토큰이 블랙리스트에 있을 가능성이 있는가?"
- 결과가 NO라면: 100% 확률로 블랙리스트에 없는 것이므로 Redis에 요청조차 안 보내고 즉시 통과.
- 결과가 YES라면: 블랙리스트에 있을 확률이 있으니 그때만 Redis를 조회해서 확정.
