refresh-token rotation
사이드 프로젝트를 진행하는 동안 인증기반을 JWT로 하기로 했고
refresh-token을 순환시키는 방법에 대해 알게 됐다.
그게 바로 refresh token rotation인데
무엇 때문에 생긴 기법이냐?를 알기 전에
refresh token에 대해서 알아보자
JWT를 사용하면 로그인 후 서버에서 access-token을 내려주고
클라이언트는 이 access-token을 웹 스토리지에 저장한 후 API요청할 때마다 http헤더에 같이 담아서 보내준다.
이 access-token의 만료기간을 길게 잡게 되면 해커의 공격으로 탈취될 경우
해커가 이 토큰으로 api요청을 보낼 수 있다.
그렇다고 만료기간을 짧게 잡으면 사용자가 그 만료기간이 지날 때마다
로그인을 자주 해줘야 하는 불편한 경험을 초래하게 될 것이다.
access-token 만료기간을 짧게 잡으면서 원활한 유저 경험을 가져가게 하려면 refresh token이 필요한데
이 refresh token은 만료기간을 길게 줘서
HTTP요청을 보냈는데 access-token이 만료되었을 때
자동적으로 refresh token을 같이 담아 보내서 액세스 토큰을 갱신한다.
여기서 핵심은
1. 액세스 토큰은 API를 통해 서버와 데이터를 주고받기 위함이다.
2. 리프레시 토큰은 엑세스 토큰을 자동적으로 갱신하기 위함이다.
access-token, refresh-token 작동원리
refresh-token은 만료기간을 길게 주는데
그렇다면 refresh-token이 탈취당할 위험은 없나?
당연히 있다.
대부분의 경우 네트워크를 통해 탈취당한다고 한다. (HTTP요청 자체를 탈취)
그게 바로 refresh token rotation기법이 등장하게 된 배경이다.
refresh-token을 순환시키면
access-token이 만료되어 새로 받아올 때
refresh-token도 함께 받아온다는 것이다.
그래서 하나의 refresh-token으로 access-token을 갱신하는 건
단 한번뿐인 것이다.
즉, 일회성이다.
이렇게 됐을 경우
동일 refresh-token이 두 번 이상 사용될 경우
해당 refresh-token은 탈취되었다고 가정하여
이 토큰이 연관되어 있는 모든 refresh-token을 폐기한다.
다만 해커가 지속적으로 새로운 access-token만을 탈취한다면 무용지물이라고 한다. (이건 사실 다른 방법으로 보안을 강화해야 될 듯..)
이렇게 refresh-token과 rotation 기법에 대해 알아봤는데
실제 코드는 어떻게 작성될지 해봐야 알 것 같다.
코드 짜기 전에 전체적인 흐름을 한번 파악하기 위해 블로그 포스팅을 하는 것이다.
다음은 실전으로 돌아오겠다!