본 문서는 3 Scenarios Where You Can Store JWT Token in Your DB 를 요약 및 번역한 글입니다.
요약되어 생략된 내용이 있습니다.
오역이 있을 수 있습니다.
토큰 기반의 인증 방식(보통 JWT)은 stateless 라고 한다. 토큰이 그 자체로 인증에 필요한 정보를 모두 갖고 있어서 서버가 상태를 저장할 필요가 없기 때문이다.
그러나 저장해야 할 필요가 있는 상황이 있는데, 한 번 알아보자.
1. Refresh Tokens
사용자는 access token 요청 헤더에 담아 서버의 검증을 통과한 후 보호된 리소스에 접근할 수 있다. 보안을 위해 access token의 수명은 짧다. Refresh token은 access token을 갱신할 때만 사용한다. 그러므로 수명을 길게 설정한다. 여기서 의문이 든다. Refresh Token이 있으면 access token을 무한정 획득할 수 있는데, 그렇다면 악의적인 사용자로부터 어떻게 리소스를 보호해야 할까?
먼저, 악의적인 행동이 보고되면 모든 사용자의 refresh token을 삭제하는 방법이 있다. 하지만 사용자 경험 측면에서 좋지 않으며, 악의적인 행동이 발견되지 않는다면 어떨까?
답은 refresh token rotation 이다. Refresh token을 한 번 사용하면, 새로운 refresh token을 발급하는 것이다. 이렇게 하면 refresh token이 재사용될 수 없기 때문에 악의적인 공격을 예방할 수 있다.
참고로 refresh token은 꼭 JWT일 필요는 없다. 인코딩 된 간단한 문자열이나 UUID여도 된다.
2. 이메일 확인 토큰
서버는 사용자가 회원가입 할 때 이메일 주소 확인용 메일을 보낸다. 메일에는 사용자 식별을 위한 토큰이 포함된 링크가 있고, 사용자가 링크를 클릭하면 API 요청을 보낸다. 이 토큰은 항상 수명이 짧다.
사용자가 확인 메일 요청을 다시 한다면 어떨까? 이런 상황에서는 토큰이 DB에 저장되어 있어야 한다. 새로운 토큰이 생성되면 이전의 토큰이 삭제되야 하기 때문이다.
또한, 메일 인증이 완료되면 DB에 저장된 토큰은 삭제되어야 한다.
3. 비밀번호 재설정 토큰
서버는 사용자가 비밀번호 분실 버튼을 클릭하고 이메일을 입력하면 비밀번호 재설정 이메일을 보낸다. 메일에는 비밀번호 재설정을 위한 토큰이 포함된 링크가 있고, 사용자가 링크를 클릭하면 API 요청을 보낸다. 마찬가지로 이 토큰은 수명이 짧다.
메일 인증 토큰과 마찬가지로 하나의 토큰만 유효하도록 구현한다.
결론
JWT는 stateless 인증을 가능하게 한다. 하지만 이메일 확인처럼 단일 목적에 하나 이상의 JWT가 생성될 수 있는 경우에는 반드시 DB에 최신의 토큰을 저장하여 사용해야 하고, Refresh token의 경우에도 악의적인 접근을 예방하기 위해 DB에 저장해야 한다.
