토큰 기반 인증에서 리프레쉬 토큰 관리

JWT로 토큰 기반 인증을 구현할 때 궁금한게 좀 생겼습니다! 리프레쉬 토큰은 DB에 저장해볼까 했는데 그러면 토큰 기반 인증이 아니라 세션 기반 인증인 것 같아서 고민입니다. DB에 저장하는 순간 Stateless 장점도 없어지는 것 같구… Stateless로 구현한다해도 로그아웃 때문에 블랙리스트 관리해야한다는데, 이러면 결국 Stateful인거 같구… 다른 분들은 어떻게 구현하시는지 궁금합니다! 일단 이렇게 고민해봤습니다. --- <1번 시나리오 - 리프레쉬 토큰을 DB에 저장하지 않는 시나리오>

 1. 액세스 토큰이랑 리프레쉬 토큰은 클라이언트가 저장하고 서버는 저장하지 않는다.
 2. 클라이언트 요청이 왔을 때 리프레쉬 토큰이 만료되지 않았으면 액세스 토큰을 발급해주고, 만료됐으면 액세스 토큰을 발급해주지 않는다. (401 또는 403)
 장점 - DB에 접근할 이유가 없으므로 Stateless 하다. 단점 - 로그아웃을 했을 때 토큰 자체는 무효화시킬 수 있는 방법이 없다.

 <2번 시나리오 - 리프레쉬 토큰을 DB에 저장하는 시나리오> 1. 액세스 토큰이랑 리프레쉬 토큰은 클라이언트와 서버가 각각 저장한다.
 2. 클라이언트 요청이 왔을 때 리프레쉬 토큰이 만료되지 않았으면 액세스 토큰을 발급해주고, 만료됐으면 액세스 토큰을 발급해주지 않는다. (401 또는 403) 장점 - 로그아웃을 했을 때 토큰 자체는 무효화시킬 수 있다. 단점 - DB를 접근해야하므로 Stateful 하다. => 클러스터링이나 샤딩이 도입되면 복잡도가 올라간다.
 --- 1번 시나리오 단점을 극복하려고 블랙 리스트를 Redis에 관리한다는 글들을 종종 봤습니다. 블랙 리스트를 도입 안했을 때 문제는 실제로 겪어본 적이 있어서 공감은 가는데, 이러면 사실상 세션 쓰는거랑 똑같지 않나라는 생각이 듭니다. 인증시 결국 Redis 같은 DB에 접근해서 직접 확인하는 거니까요. 한편으로는 서비스가 매우 많이 커지면 세션이 부담돼서 토큰 기반 인증으로 전환한다는데, 파면 팔수록 점점 세션 기반 인증으로 바뀌는 것 같아서 고민입니다.

이 질문이 도움이 되었나요?

'추천해요' 버튼을 누르면 좋은 질문이 더 많은 사람에게 노출될 수 있어요. '보충이 필요해요' 버튼을 누르면 질문자에게 질문 내용 보충을 요청하는 알림이 가요.

추천해요 0

보충이 필요해요 0

장성호 Toss Server Developer 님의 질문