JWT 로그인 테스트-2

리프레시 토큰?

 

토큰을 안전하게 사용하기 위해선 토큰 유효기간이 필요한데,

유효기간이 만료되면 새로운 토큰을 발급하기 위해 사용한다.

위와 같이 토큰 발급을 처리하게 되는데 특이하게 데이터베이스가 등장했다.

여기서 드는 궁금증은 리프레시 토큰을 위한 데이터베이스를 따로 만들어야 하는가 이다.

 

데이터베이스에 리프레시 토큰 저장

구현 방식

• 사용자의 로그인 시, 서버는 리프레시 토큰을 생성하여 데이터베이스에 저장
• 클라이언트는 이 토큰을 저장하고, 액세스 토큰이 만료되면 리프레시 토큰을 사용해 새 액세스 토큰을 요청
• 서버는 리프레시 토큰의 유효성을 확인하기 위해 데이터베이스를 조회합니다.

장점

• 서버가 리프레시 토큰의 유효성을 명확히 검증할 수 있습니다.
• 리프레시 토큰 탈취 사고가 발생했을 때, 해당 토큰을 데이터베이스에서 삭제하여 즉시 무효화할 수 있습니다.
• 사용자 로그아웃 또는 재로그인 시, 기존 토큰을 폐기하는 처리가 쉽습니다.

단점

• 데이터베이스 조회가 필요하므로 서버의 부하가 약간 증가할 수 있습니다.
• 상태(Stateful) 기반 구현이 되며, 리프레시 토큰의 무상태(Stateless) 성격이 감소합니다.

 

데이터베이스 없이 리프레시 토큰 관리

구현 방식

• 리프레시 토큰도 JWT 형태로 생성하며, 액세스 토큰과 마찬가지로 서버가 비밀 키로 서명
• 클라이언트가 리프레시 토큰을 사용해 새 액세스 토큰을 요청하면, 서버는 리프레시 토큰의 서명을 검증하고 만료 여부를 확인
• 데이터베이스 조회 없이 토큰의 유효성을 판별합니다.

장점

• 서버는 토큰을 별도로 저장하지 않으므로 무상태(Stateless) 특성을 유지
• 데이터베이스 조회가 필요 없어 성능이 개선
• 마이크로서비스 환경에 적합

단점

• 리프레시 토큰이 탈취되면 유효 기간이 끝날 때까지 무효화할 수 없음
• 로그아웃이나 강제 토큰 만료 기능을 구현하기 어려움

결국 두 방식다 장단점이 있으나 데이터베이스에 저장하는 것이 

토큰 방식의 무상태 성격을 감소시키더라도 보안과 유지보수를 위해 좋아보인다.