[Spring Security + JWT] Access, Refresh 토큰을 DB에 저장해야하는 이유

오늘 모의 면접 때 Token을 왜 DB에 저장했냐고 질문이 들어왔는데, 뭔가 말로 설명하기는 어려웠음 + 이후에 생각난 게 있어서 이유를 정리해 봤다. 

 

 

DB에 토큰을 저장해야하는 이유

 

( 여기서 DB는 MySQL 같은 RDB일수도 있고, Redis 같은 인메모리 DB일 수도 있다.)

 

결론부터 말하자면 자동 로그인 때문이다.

 

Spring Security에서 유저 토큰은 기본적으로 security context에 authentication 객체로 저장되는데, security context는 세션에 저장되므로 서버가 꺼지면 초기화 된다. (세션은 Tomcat 내장 메모리에 저장되므로 재시작 시 초기화된다.)  

 

따라서 토큰이 서버 외의 어딘가에 저장되어있어야 

1. 오류 등으로 인해 서버가 down 되었다가 다시 켜졌을 때, DB의 토큰 정보로 유저 로그인을 유지 가능 (자동 로그인!)

2. 서버가 여러 대일 때, 서버(서로 다른 프로세스 or HW) 끼리 토큰을 공유 가능 (얘도 자동로그인)

 

 

서버끼리 토큰을 공유?

서버 외의 다른 곳에 토큰을 저장해두지 않으면 로그인 한 서버가 아닌 다른 서버로 중계 되었을 때 인증 실패 됨 -> 유저 재로그인시켜야 한다.  (인증 실패 이유 :  서버 2는 서버 1의 세션에 저장된 토큰을 모르니까)

 

DB에 토큰을 저장하지 않은 경우

 

중계 서버가 서버 1,2,3 에 골고루 트래픽을 배정한다고 가정하면... 어쩌면 상품 1 장바구니에  담기 요청 / 상품 2 장바구니에  담기 요청 / 상품 구매 요청 이라는 3가지 요청이 발생했을 때, 요청 시마다 계속 인증 실패를 해서 로그인만 3번 해줘야 하는... 열받는 상황이 발생할 수 있다. 쇼핑몰 앱이 저러면 다시는 안 쓸듯

 

1. 로그인 요청 - 발급된 토큰을 서버에만 저장했다

2. 상품 구매 요청 - 다른 서버에 저장 된 토큰 정보를 모르므로 인증 실패, 다시 로그인 요청함

 

DB에 토큰을 저장한 경우

서버2로 바뀌어도 DB에서 클라이언트 A의 토큰을 조회 가능 (인증 성공) 하므로 유저가 다시 로그인할 필요 없다.

DB에서 찾아온 토큰은 서버2의 security context에 저장해두고 쓰게된다.

2.상품 구매 요청 (DB에 토큰이 저장된 경우) - DB 조회해서 토큰 정보를 확인 (인증 성공)