물론 프로젝트에 적용하고 있진 않지만, 예전에 했던 고민인데 완벽한 해결 방법도 모르고 급한대로 마무리했던게 아쉬워서 가져와봄


다들 어떤 생각을 가지고 있는지 서로 이야기 해보면 어떨까 싶어서 똥글 싸봄




------------------------------------------------------------------------------------------------------------------


JWT를 사용하는 서버에서 Stateless하게 유지해야하다보니, 서버 자체 세션은 시큐리티를 사용하여 끈 상태임. 근데 알다시피 JWT는 보안 상 문제가 많다고 생각했음


그래서 가장 흔한 방법인 블랙리스트 토큰을 우리 쪽에서 관리하면 어떨까 생각해봤음.


1. 가장 먼저 생각했던 방식은 회원이 만약 요청하거나 로그아웃을 하게 되면, JWT 토큰을 우리 쪽 DB에서 관리해보자 였음.


24b0d121e09c28a8699fe8b115ef046f5c4591



문제 :

- 이런 방식은 JWT 특성 상 클라이언트가 가지고 있는 토큰을 DB에 접근해서 이상이 없는지 확인해야 하다보니 DB 요청 수가 너무 많이 증가함.

- Access 토큰과 Refresh 토큰을 둘 다 관리해야되며, 만료될 때마다 데이터를 주기적으로 지워줘야함. 근데 토큰마다 만료가 다르니 계속 확인하거나, 특정 시점으로 지난건 확인해서 지워야하지만 이것 또한 DB 자원을 불필요하게 사용하는 것 같았음.


2. 그래서 이후에 Redis를 추가를 해봄




24b0d121e09c28a8699fe8b115ef04699338ff




블랙리스트 토큰에서만의 관계를 따졌을 때의 그림임. 이렇게 데이터를 가지고 있으니 엄청 많은 데이터를 확인했던건 아니지만, 기존 DB에 접근하는 횟수가 현저히 낮아짐. 하지만 피드백에서 다음과 같은 문제에 대한 답변이 어려웠음


문제 :

- 별 생각없이 개별적으로 TTL 설정을 했는데 앞서 이야기한 것처럼 각각의 토큰은 유효시간이 다 다름. 이걸 그때 그때마다 지우는 건 좋은 방향이 아님.

- 레디스는 알다시피 메모리기반 데이터로 데이터가 휘발성임. 레디스가 재시작 됐을 경우 블랙리스트로 등록되어있던 데이터가 사라져 로그인이 가능해질 수 있음.

- 레디스도 결국 서버와 통신하고 있는 하나의 인프라이므로 예상치 못한 장애가 발생했을 때의 대처 방법이 필요함.


-------------------------------------------------------------------------------------

아쉽게도 해당 문제는 실질적으로 해결하진 못했지만 TTL 관련은 배치를 사용하고, 두 번째는 백업, 세 번째는 레디스 클러스터링? 을 이용하면 된다는 정도만 이해했었음.


다들 동일한 이유는 아니더라도 비슷한 이유로 레디스를 많이 사용했을텐데 솔직히 내가 적절히 쓴지도 모르겠음. 그냥 이런게 있으면 좋을거 같다는 생각으로 만든거라서.. 어떤 문제가 있었고 어떻게 해결했는지 궁금하고 듣고 싶음.