1. JWT?

• 기존 http의 경우엔 보안을 위해서 stateless 한 방식을 사용함에 통신이 끊기면 계속해서 추가로 입력했던 정보를 다시 요구하기 때문에 이에 불편함을 느끼게 됐다.

2. 장단점?

• 가볍다.
  • 따로 서버에 메모리에 저장하는 방식인 세션과 다르게 JWT의 경우엔 서버 메모리 확보가 필요하지 않다. 클라이언트가 서버에서 보내준 토큰을 가지고 있다가 요청이 올 때 헤더에 해당 토큰을 보내주면 토큰 검사를 통해서 이를 확인하고 작업한다.
• 모바일 환경에서 최적화 되어있다.

2.1 단점

• 페이로드 크기가 커지면 전송 비용이 커진다.
• 자동 소멸이 되지 않기 때문에 계속 냅두게 되면 해킹의 위험성이 높아진다.
  • 페이로드는 로그인 유저임을 증명할 수 있는 기본적인 정보들을 말한다.
• localstorage에 jwt 을 보관하면 xss공격에 취약하게 된다.

3. jwt의 치명적 문제 해결을 위한 Redis 도입

그래서 이런 저런 이유로 JWT를 이용해서 해당 authentication(인증) 작업을 진행할 때 JWT 도입을 하고 사용하려고 했다. 그러나 사실상 JWT는 토큰 자체가 만료가 되어도 삭제가 되지 않는 문제가 있기 때문에 이 문제를 어떻게 해결할까? 오케이 일단 지금 프로젝트에 Redis를 도입해보자

jwt의 accessToken & refreshToken

• accessToken의 경우엔 토큰 자체의 탈취 문제로 만료시간을 짧게 둔다. 그런데 상태 유지를 위해서 jwt를 사용하는데 이 방법이 만료시간이 짧아서 회원들이 자주 다시 로그인을 해야하는 등의 불편함이 생긴다면 이 방법을 적용하는 이유가 없을 것이다.
• 이를 해결하고자 토큰 만료 시간이 짧아도, 토큰이 탈취 되어도 문제가 없도록 refreshToken을 사용해서 이 문제점을 보완해보고자 한다.
• 이때 refreshToken을 탈취 당하면?
  • 해당 토큰을 가지고 새로운 accessToken을 발급해주는 문제가 있을 수 있는데 이때 accessToken의 클라이언트가 누구인지 알수 없다는 문제가 생길 수 있다.
  • 발급해준 refreshToken 역시 저장(=db에)해두고 비교해가며 해당 토큰이 제대로 된 토큰인지를 확인하여 refreshToken이 accessToken을 발급해줘도 소용이 없게 한다.
  • 이때 저장은 redis에서 진행될 예정