어제 확인해본 내용과 상이한 글을 확인해 Refresh토큰에 대해 다시 알아보려 한다.
어제 확인한 글에서는 random string이나 uuid로 만들어야 서버측에서 탈취단한 토큰을 삭제할 수 있다고 했는데, 서버에 저장하는(stateful) 방식만 취한다면 JWT토큰이여도 삭제할 수 있다고 한다.
또한 refresh 토큰을 저장하는 위치도 cookie, session, local storage 등 다양하던데, 튜터님은 셋 모두 각자의 장단점이 있을 뿐 어디에 저장하든 탈취당하지 않도록 관리하는 방법 자체가 중요하니 당장은 구현하기 쉬운 곳에 구현하는 것이 좋다고 말씀하셨다.
저장 위치에 따른 장단점은 아래 블로그를 참고하자.
하지만 여전히 refresh 토큰을 jwt 형태로 만드느냐 그 외 형태로 만드느냐에 대한 의문은 풀리지 않는다. jwt 토큰으로 만들어도 어차피 암호화 되어있고, refresh 토큰으로는 인증/인가를 받을 수 없기 때문에 RTR을 사용하면 위험성이 현저히 줄어들어 괜찮다는 사람도 있고, jwt 토큰으로 만들면 서버에서 제어할 수 없어 탈취당했을 때 서버에서 삭제가 안되니 위험하다는 사람도 있다.
튜터님과의 상담 결과 jwt가 아닌 형태로 refresh토큰을 만들면 탈취당했을 때 서버에서 대응하기 좋아지는 것은 사실이나, 그렇다고 jwt 의 장점을 포기하면서 만들기에는 서로의 장단점이 확실하기에, jwt 토큰 형태로 만들되 탈취당했을 경우를 대비해 RTR 방식을 채택한다. 또한, 탈취 당하지 않도록 관리하는 것도 물론 중요하다. 실제로 현업에서는 jwt 토큰 자체를 쓰는 것도 갈리고, 각자의 장단점이 있다보니 토큰을 관리하는 방법도 각양각색이라고 한다. 실제로 튜터님이 지금 하시는 환경에서는 jwt 토큰을 사용하는 이유였던 session 방식을 사용하고 계신다고 한다.
결론 : refresh 토큰도 jwt 형태로 만들되 RTR 방식을 채택하고, 그 외에도 토큰이 탈취당하지 않도록 보안을 강화하는 방법을 더 강구해본다.
