[프로젝트] 🔐 RefreshToken, 필요했구나!

• 지금의 방식대로라면 액세스 토큰만 있어도 되는 것 아닌가?
• reissue API(토큰 갱신 API)가 정말 필요한가?

이전 글에서 이러한 의문들을 남겨두고 글을 마무리했다. 오늘은 그 의문을 해소했던 과정에서의 생각을 정리하고자 한다. 프로젝트마다 토큰 구현 방식이 다를 수 있고 고민의 해소 방식이 다를 수 있다는 점 참고 바란다 🙌

방끗 프로젝트에서는 액세스 토큰, 리프레시 토큰을 모두 쿠키로 전달하고 있으며 모든 요청마다 2개의 토큰을 전송한다. 이때 액세스 토큰으로 토큰 계속해서 갱신하면 되지, 굳이 리프레시 토큰이 필요한가?라는 생각이 들었다.

✅ 액세스 토큰만 있다면 무엇이 문제일까?

만약 액세스 토큰이 탈취당하면 그 토큰으로 계속 토큰을 발급할 수 있기 때문에 매우 위험하다. 그런데 이는 리프레시 토큰도 마찬가지 아닌가?

먼저 액세스 토큰만 가지고 있다고 생각해보자.

액세스 토큰의 유효시간은 30분이다. 악의적인 사용자가 유저의 토큰을 탈취해 토큰의 요효시간인 30분동안 맘껏 토큰을 사용할 수 있다. 그리고 유효시간이 만료되면 토큰 갱신 API를 요청해 새로운 토큰을 발급받을 수 있다. 악의적인 사용자는 무한히 액세스 토큰을 발급받을 수 있다.

반면 리프레시 토큰이 존재한다고 생각해보자. 그 전에, 내가 잘못 생각하고 있던 부분을 짚고 넘어가야 한다. 지금의 구현에서는 매 요청마다 액세스, 리프레시 토큰이 함께 전달된다. 일반 요청에서는 액세스 토큰만, 토큰 갱신 요청에서는 리프레시 토큰을 함께 담아 전달하고 싶지만 이를 프론트에서 구별해서 보낼 수 없다. 보안상의 이유로 프론트에서 제어할 수 없도록 httpOnly 속성을 사용하고 있기 때문이다. 그래서 액세스 토큰이 탈취될 때 리프레시 토큰도 당연히 탈취되는 것 아닌가라고 생각했었다. 하지만 일단은 액세스 토큰과 리프레시 토큰을 다르게 보낼 수 있다는 가정이 필요하다.

다시 예시로 돌아와서, 악의적인 사용자는 사용자의 액세스 토큰을 탈취해 30분동안 맘껏 사용할 수 있다. 그리고 새로운 토큰을 갱신하고자 한다. 하지만 리프레시 토큰은 가지고 있지 않기 때문에 새로운 토큰을 발급받을 수 없다. 따라서 악의적인 사용자는 액세스 토큰의 유효시간동안만 피해를 줄 수 있으며 이후로는 권한을 잃게 된다. 리프레시 토큰을 사용해 토큰 갱신을 더욱 안전하게 처리할 수 있다. 또한 액세스 토큰은 매 요청마다 포함되지만 리프레시 토큰은 토큰 갱신 API에서만 사용되므로 탈취 위험이 낮아진다.

✅ 더 고려해볼 사항들

먼저, 액세스 토큰이 탈취되면 그 시간동안은 계속 사용할 수 있기 때문에 액세스 토큰의 유효시간은 최대한 짧게 가져가는 것이 좋다. 5 ~ 10분정도가 적당할 것 같다.

다음으로 리프레시 토큰이 탈취당하면 토큰을 무한히 생성할 수 있기 때문에 매우 위험하다. 이를 해결하기 위해 토큰을 특정 저장소(ex) Redis)에 저장해두어야 한다. 사용자의 식별자와 리프레시 토큰을 함께 저장해두고 토큰 갱신 API 요청시 리프레시 토큰을 대조해 악의적인 사용자를 판별할 수 있을 것이다. 이전 글에서 언급했듯, JWT를 서버에 저장해둔다면 stateless 특성을 잃는다고 생각해 서버에 저장하지 않았다. 하지만 리프레시 토큰은 토큰 갱신 API 요청시에만 대조를 위해 조회한다. 이는 큰 부담이 아니라고 생각해 서버에 저장하는 것이 큰 부담이 되지 않으면서도 보안의 이점을 챙길 수 있는 좋은 방식이라고 생각했다.

마지막으로 프론트에서 액세스 토큰, 리프레시 토큰을 구별해 보낼 수 있는 방법을 찾아보았다. 쿠키에 path 속성을 활용하면 특정 URL에 대해서만 쿠키를 전송할 수 있다. 그리고 이렇게 구별해보내기 위해서는 토큰 갱신 API가 필요하므로 reissue API(토큰 갱신 API)가 정말 필요한가? 라는 의문점도 해소되었다.