JWT 리프레시 토큰의 필요성에 대해

RefreshToken의 필요성

기존 AccessToken을 사용할 때는 Stateless이기 때문에, 발급 이후로는 조작할 수 없다.

그렇다고 만료기간을 짧게 주면, 사용자는 재로그인을 빈번하게 해서 경험이 부정적이게 된다.

 

따라서 이 AT의 만료기간을 짧게 하고 재발급을 받을 수 있는 RefreshToken을 같이 발급한다.

이렇게 하면, 재로그인 없이 RT의 만료기간안에 재발급을 받을 수 있어 사용자 경험을 해칠 일이 없고,

AT의 만료기간이 짧기 때문에 탈취당해도 피해가 최소화될 수 있다.

 

 

RefreshToken이 탈취당한다면?

처음 로그인할 때 AT와 RT 모두 발급해서 전달할텐데, AT가 탈취당한다면 RT도 같이 탈취당하는 것이 아닌가?

 

우선 웹과 모바일 환경은 서로 다르다. 우선 웹은 사용자가 자바스크립트 코드를 볼 수 있고,  localStorage는 자바스크립트로 접근이 가능해 XSS에 취약하다.

따라서 AT가 탈취당한다면 RT도 탈취당하는거나 다름이 없다.

 

그래서 웹에서  RT는 주로 쿠키로 보낸다.

쿠키로 보내게 되면 HTTP ONLY를 통해 XSS를 방지할 수 있고 CSRF는 보안에 조금만 신경을 써도 쉽게 차단할 수 있기 때문이다.

 

하지만 모바일 환경에선 앱의 경우, kotlin이나 swift같은 프로그래밍 언어를 사용하고, 하이브리드 앱같은 경우에도 내부 코드를 사용자가 볼 순 없다. 또한 앱의 경우 secureStorage를 사용하기 때문에 데이터 암호화 및 접근 제어를 제공해 더욱 안전하다. 그리고 쿠키는 웹에 최적화돼있어 쿠키를 자동을 관리해주지만, 모바일은 수동으로 관리를 해야한다고 한다.

따라서 모바일은 http body나 헤더로 보내면 된다.

 

그렇다면 웹에서 AT는 왜 쿠키로 보내지 않는가?

쿠키는 웹에 최적화돼있기 때문에, 웹 모바일 모두 통신하기 쉽게 하려면 헤더로 보내는게 좋다.

또한 표준방식이 헤더로 보내는 것이기 때문이다. 굳이 표준을 무시할만큼의 장점이 생각나지 않는다.

CSRF의 방어를 한다는 가정하에 XSS를 방지할 수 있다는 것 뿐인 듯 하다.