[실시간 대용량 서비스] JWT 인증에서 블랙리스트로도 충분한데, 왜 화이트리스트를 선택했을까?

지난 JWT 인증/인가 방식에 대한 설계를 정리한 이후, 인증인가에 대한 대화를 주고받는 과정에서 다음과 같은 질문을 받았다.

 

“블랙리스트와 화이트리스트의 차이가 정확히 무엇인가요?”

“화이트리스트에서 하려는 제어를 블랙리스트로는 구현할 수 없나요?”

 

이미 구현은 끝났지만, 이 질문에 명확히 답하기 위해서는 왜 그런 선택을 했는지를 개념적으로 다시 정리할 필요가 있다고 느꼈다.

🤔 블랙리스트란?

• 블랙리스트란 다시 말하자면 이미 문제가 된 토큰 목록이다.
• JWT 인증 구조에서 블랙리스트는 보통 다음을 의미한다
  • 로그아웃된 AccessToken
  • 탈취가 의심되어 강제로 만료한 토큰
  • 특정 정책에 의해 더 이상 유효하지 않은 토큰
• 정리하면, 원래는 유효했지만 지금은 사용하면 안되는 토큰을 따로 기록해두는 방식이다.

💡 블랙리스트의 인증 흐름 

1. 클라이언트가 AccessToken을 들고 요청
2. 서버는 서명 + 만료 검증
3. 블랙리스트에 포함되어 있는지 추가 확인
4. 포함되어 있다면 거부

정리하면, 블랙리스트에 없으면 토큰은 유효하다고 가정한다.

 

🎯 블랙리스트의 설계적 의미

• JWT의 Stateless 기반 개념을 크게 벗어나지 않는다.
• 서버는 문제가 생긴 토큰만 기억한다.
• 정상적인 토큰 흐름에는 개입하지 않는다.
  → 쉽게 생각하면 사후대응 이다.
  → 이러한 점을 고려해야 하는 부분이다. 그래서 아직 발견되지 않은 탈취 토큰은 어떻게 처리할 것인가? 

🤔 화이트리스트란? 

• 화이트리스트란 다시 말하자면 서버가 현재 인정하고 있는 토큰 목록이다.
• JWT 인증 구조에서 화이트리스트는 서버의 명시적 승인이 있어야만 한다.

💡화이트리스트의 인증 흐름

1. 클라이언트가 토큰을 들고 요청
2. 서버는 서명 + 만료 검증
3. 화이트리스트에 존재하는지 확인
4. 존재할 때만 요청 허용

정리하면, 화이트리스트에 없다면 그 토큰은 신뢰되지 않는다.

 

🎯 화이트리스트의 설계적 의미

• 서버는 언제든 자격을 회수할 수 있어야 하고
• 어떤 토큰이 살아 있는지도 알고 있어야 한다.

이 관점은 보안적으로는 강력하지만, 명확한 비용을 동반한다.

• 서버 상태 관리 필요
• 저장소(Redis 등) 의존
• 완전한 Stateless는 포기

🔥 '기본 허용' 과 '기본 차단' 관점의 차이

위의 내용을 정리하면 블랙리스트와 화이트리스트의 차이는 단순히 목록을 어디에 두느냐의 문제가 아니라

토큰을 바라보는 기본 관점의 차이라는 점이었다.

 

블랙리스트는 기본 허용(Default Allow) 구조이고, 화이트리스트는 기본 차단(Default Deny) 구조에 가깝다.

보안 사고를 어떤 시점에서 막고 싶은가의 선택의 차이라고 볼 수 있다.

 

❓ 그래서 블랙리스트로 화이트리스트에서 하려는 제어를 구현할 수 있을까 없을까?

우선 기술적으로 구현은 가능하다는 점이다.

 

예를 들어, RefreshToken을 재발급할 때마다 이전 토큰을 전부 블랙리스트로 등록하고 현재 토큰만 살아있게 관리한다면 결과적으로

허용된 토큰만 사용 가능한 상태 를 만들 수 있다.

 

✓ 그럼에도 블랙리스트를 선택하지 않는 이유는 무엇인가?

설계 단계에서 고민했던 것은 가능한가가 아니라 이 처리 방식이 맞는가에 대해서 였다.

블랙리스트는 구조적으로 이 토큰이 과거에 문제가 있었는가? 를 묻는다면, 내가 고민했던 부분은 이 토큰을 지금도 신뢰할 수 있는가? 였다.

🔗 블랙리스트의 한계 (RefreshToken 관점)

RefreshToken은 다음과 같은 특성을 가진다.

• 수명이 길고
• 사용 빈도는 낮지만
• 탈취 시 피해가 크며
• 로그아웃, 강제 만료가 반드시 필요하다.

이런 토큰을 기본적으로 신뢰하고 문제가 발생하면 막는다. 라는 관점으로 관리하는 것은 보안 리스크에 비해 통제력이 부족하다고 판단했다.

아직 발견되지 않은 탈취 토큰은 블랙리스트 구조상 그대로 허용되기 때문이다.

 

이러한 특성은 이전 글에서도 언급했지만,이번 글에서는 ‘왜 블랙리스트 방식이 맞지 않았는가’라는 관점에서 다시 살펴본다.

 

👍 화이트리스트가 적합했던 이유

화이트리스트는 위에서 작성했던 것과 같이

• 토큰이 살아 있는지
• 서버가 지금도 인정하는 상태인지
• 언제든 자격을 회수할 수 있는지

이 모든 것을 현재 상태 기준으로 판단한다. 과거가 아니라 지금 이 순간의 유효성에 집중하기 때문에 보안 민감도가 높은 자산에는 이 방식이 더 적합하다고 판단했다.

 

🔍 도메인 성향을 고려한 최종 판단

이번 프로젝트는 온라인 교육 플랫폼이라는 도메인을 대상으로 한다.

강의 영상과 같은 유료 콘텐츠를 다루고, 하나의 계정이 여러 디바이스에서 동시에 사용될 가능성이 높은 환경이다.

 

이런 도메인에서는 단순히 “로그인에 성공했는가”보다 “지금 이 접근을 허용해도 되는가”를 판단할 수 있는 구조가 더 중요하다고 생각했다.

 

특히,

• 계정 공유를 통한 동시 접속
• 로그아웃 이후에도 유지되는 접근
• 탈취된 토큰을 통한 장시간 이용

과 같은 상황을 고려했을 때, 과거에 문제가 있었는지를 기준으로 판단하는 블랙리스트 방식보다는,

현재 서버가 인정하는 상태인지를 기준으로 판단하는 화이트리스트 방식이 도메인 특성에 더 적합하다고 판단했다.

 

이러한 이유로, RefreshToken은 화이트리스트 방식으로 통제하고, AccessToken은 Stateless하게 유지하는 혼합 인증 구조를 선택하게 되었다.

 

📝 정리하며 - 이 질문이 내 설계에서 의미했던 것 

이 글을 통해 정리하고 싶었던 부분은 블랙리스트와 화이트리스트 중 어느 방식이 우월한가에 대한 판단이 아니었다.

 

중요했던 점은, 토큰을 어떤 관점에서 신뢰할 것인가였다.

 

블랙리스트는

"이미 문제가 발생한 토큰을 어떻게 차단할 것인가" 에 대한 해결법이고,

 

화이트리스트는

"이 토큰을 지금 이 순간에도 신뢰할 수 있는가"를 묻는 방식이다.

 

RefreshToken은 

수명이 길고 탈취 시 피해가 크며 로그아웃과 강제 만료가 반드시 필요한 자산이기 때문에 과거의 이력보다 현재의 유효성을 기준으로 판단하는 방식이 더 적합하다고 판단했다.

 

그래서 이전 글에서 정리한 Redis 기반 화이트리스트 구조는 단순한 구현 선택이 아니라,

토큰을 신뢰하는 기준을 어디에 둘 것인가에 대한 의도적인 설계 판단의 결과였다.