토큰이 탈취되었을 때를 어떻게 대비할 것인지
우선 유저인증 수단으로 JWT를 사용하였다. 별도의 서버비용이 들지 않고, 확장성까지 좋은 인증수단이기 때문이다.
처음에 고민했던 부분은 토큰이 탈취되었을 때의 문제점이었다. 토큰이 탈취가 된다면 남아있는 유효기간동안 해커를 막을 방법이 없기 때문이다.
즉, 유효기간을 늘리면 보안에 취약해지고, 유효기간을 줄이면 사용자가 그만큼 자주 로그인을 해야 하는 불편함이 생기는 문제가 있다.
이것을 해결하기 위해서 RefreshToken을 적용하게 되었다. AccessToken과 RefreshToken 두 개의 토큰을 사용하여 위의 문제점을 어느정도 해결했다고 생각하였는데 문득 RefreshToken이 탈취당하면 어떻게 하지...? 라는 의문이 들었다.
이것을 해결하려고 노력한 방법은 아래에 주소에 정리해 놓았다.
토큰에 어떠한 정보를 담아줄 것인지
이 생각은 금방 답을 내릴 수 있었다.
토큰에 아주 최소한의 정보만 담은 후 인증 미들웨어를 거칠 때마다 DB에 접근하여 유저의 정보를 찾아 오는 방법을 선택했다. 토큰의 Payload는 암호화가 되지 않는다는 사실을 인지하고 있었기 때문에 서버에서 조금의 손실을 보더라도 최소한의 정보만을 토큰에 담는것이 옳다고 생각한 까닭이다.
토큰을 발급하는 코드의 구성을 어떻게 할 것인지
우선 Sign과 Verify 함수를 jwt-util 파일에서 관리하였다. 함수를 따로 util에서 정리해 놓은 후 로그인 시 가져다 쓰는 방법을 택한 것이다. 이러한 방법을 택한 이유는 향후 코드의 수정이 필요할 때 손쉽게 수정을 할 수 있다고 생각하였고, 무엇보다 로그인 시 토큰을 발급하는 서비스 부분의 코드를 깔끔하게 유지하고 싶었던 이유가 컸다
jwt-util 코드
로그인 서비스 로직 코드
getting ready to run