23년 1월 6일

팀 프로젝트가 끝났다. 

발표중에 리프레쉬 토큰에 대해 질문을 받았는데, 내가 리프레쉬토큰에 대해서 제대로 이해하지 못하고 있다는걸 깨닫게 되었다.

일단 액세스 토큰이 만료되면 리프레쉬 토큰을 확인하고, 액세스 토큰을 발급하는 로직을 만들었는데, 문제는 이때 리프레쉬 토큰도 재발급 되게 만들어야 했는데 액세스 토큰만 재발급 되게 만들었다.

이렇게 로직을 만들면 리프레쉬 토큰이 한번 탈취당하면, 리프레쉬토큰의 기간이 만료될때까지 탈취한 사람이 무제한으로  액세스 토큰을 발급받을 수 있다.

그리고 유저db에 리프레쉬 토큰을 저장하기 때문에, db에는 유저정보가 담긴 jwt가 리프레쉬토큰으로 담길 이유가 없다.

이럴 경우에는, jwt가 아닌  다른 값을 이용해 리프레쉬 토큰을 만드는게 맞다고 한다.

찾아보니 이를 RTR(Refresh Token Rotation)이라고 한다고 한다.그리고 jwt가 아닌 random string 또는 UUID를 리프레쉬 토큰으로 이용한다고 한다.

아니면 액세스 토큰과 리프레쉬 토큰을 body에 따로 발급하고, 리프레쉬 토큰을 db에 저장하는게 아닌 사용자가 따로 가지고 있게 만드는 형태로 구현했어야 했다.

이럴경우에는 리프레쉬 토큰을 jwt로 해서 발급을 하는데 jwt에는 유저정보가 있기때문에 따로 db에 연결할 필요가 없다.

때문에 액세스 토큰이 만료되었을때 리프레쉬 토큰만 검사하면 된다.

그렇기 때문에 jwt로 리프레쉬 토큰을 만들거면 db에 저장할 필요가 없다.

jwt의 무상태성을 이용할 수 없기때문에 jwt토큰을 발급한 의미가 없기 때문이다.

차라리 그렇게 할거면 jwt가 아닌 다른 형태로 리프레쉬 토큰을 발급받는것이 맞다는 것을 알게 되었다.

 

리프레쉬 토큰의 구조에 대한 대략적인 이해를 다시 했으니 주말에 프로젝트를 다시 만들어보면서 구상을 해 봐야 할 것 같다.