[TIL] 07/12 항해99 65일차 - 트러블 슈팅 : Access Token 재발급은 언제 해주어야 할까?

 

들어가며

JWT를 구현하면서 Access Token이 탈취되었을 때를 대비하여 Refresh Token도 함께 발급해주는 방식을 사용하고 있다.

 

Access Token의 만료일을 짧게 설정하여 프론트로 보내주고 Refresh Token의 만료일은 길게 설정한 다음 안전한 곳에 보관한 다음, Access Token이 만료되어서 프론트가 서버에 요청을 보내면 Refresh Token을 이용하여 새로운 Access Token을 발급해주는 방식이다.

 

그런데, 여기서 고민 하나가 생긴다.

 

Access Token은 언제 발급해주는게 가장 좋을까?

 

 

오늘의 TIL은 이 고민에 대한 트러블 슈팅을 하고자 한다.

 

---

만료된 Access Token의 재발급은 언제가 좋을까?

세가지 경우를 추려보았다. 각각의 장단점을 비교해보자.

 

 

첫번째 - 프론트가 만료된 Access Token을 가지고 API를 호출했을 때 에러를 보내고, 재발급 요청을 보내도록 하기

프론트가 Access Token을 가지고 API를 호출했는데, 그 token이 만료가 된 경우 '토큰이 만료되었다' 라는 에러를 보내주면 프론트가 이를 인지하고 서버로 토큰 재발급 요청을 보내는 방식이다.

 

JWT 구현을 위해 참고한 코드에서는 이와 같은 방식을 사용하고 있었다.

 

 

장점 - 사용자가 인가가 필요한 작업을 요청할 때만 Token이 재발급 되기 때문에 경제적이다.

단점 - 프론트에서 인가가 필요한 요청을 보낼 때, Token이 만료되었는 지 확인하는 로직과 재요청 로직이 추가된다. 토큰이 만료된 경우 결국 요청은 2번 보내지게 된다.

 

 

기존에는 이 방식을 사용하고 있었는데, 요청이 실패한 경우 한번 더 추가 요청이 들어가는 과정이 다소 귀찮을 것 같다는 의견을 수렴해서 다음 방식을 고려해 보았다.

 

 

 

두번째 - 일정 시간 마다 새로운 Access Token 발급해주기

첫번째 방식은 토큰 재발급 요청이 들어왔을 때, Token이 완전히 만료가 되지 않았다면 '아직 토큰이 만료되지 않았다'라는 에러와 함께 재발급을 해주지 않았다.

 

두번째 방식은 Access Token이 만료되기 5분 전에는 토큰을 재발급 받을 수 있도록 허용해주고, 프론트에서는 토큰이 만료되기 5분 전만큼의 시간마다 토큰 재발급 요청을 보내도록 하는 방식이다.

 

 

장점 - 일정 시간 마다 토큰을 재발급 받는 로직을 짜면 되기 때문에 편리하다.

단점 - 백그라운드에서 일정 시간마다 계속 토큰을 재발급받는 요청을 보내기 때문에 비효율적일 수 있다.

 

 

첫번째 방식과 두번째 방식이 보안적으로 큰 차이가 없다면 두번째 방식이 조금 더 편리한 방식이라고 생각하여 두번째 방식을 사용하고 있었는데, 프론트 팀원분께서 아이디어를 하나 제안해주셨다. 

 

 

 

세번째 - Access Token이 만료되지 않아도 프론트에서 요청하면 재발급 해주기

이 방식은 위의 두 방식보다 어떻게 보면 비효율적일 수도 있고, 어떻게 보면 보안적으로 더 나을 수도 있다.

 

세번째 방식은 프론트에서 Access Token이 만료되지 않았더라도 특정 트리거가 발생할 때마다 (ex. 페이지 이동) Access Token을 재발급 받는 방식이다. 처음에는 이 방식을 사용했을 때, 특정 트리거가 자주 발생하는 상황이 온다면 Access Token을 계속해서 재발급 해주기 때문에 비효율적이라고 생각했다.

 

 

여러가지 고민을 해본 결과, 이 방식을 사용하되 약간의 수정을 거치면 오히려 보안상의 이점을 가져갈 수 있지 않을까 라는 결론에 도달했다.

 

기존에는 Access Token을 재발급 해줄 때, Refresh Token의 만료일이 3일 이하로 남았을 때만 Refresh Token을 재발급해주고 있었다. 이것 대신 Access Token을 재발급 해줄 때마다 Refresh Token도 함께 재발급해주는 방식으로 변경해주면 어떨까?

 

 

만약 Access Token이 재발급 될 때마다 Refresh Token도 함께 재발급 된다면 기존의 Access Token이 탈취되더라도 페이지가 이동되는 순간 새로운 Access Token과 Refresh Token이 발급되기 때문에 탈취된 Access Token을 가지고 토큰을 재발급 받을 수 없다. 

 

또, 자주 Access Token을 재발급 받으므로 Access Token의 만료일을 기존보다 더 짧게 설정할 수 있어 Access Token이 탈취 되더라도 그 수명이 짧다.

 

 

결론적으로 Access Token을 자주 재발급 받는 데에서 오는 비효율보다 보안상의 이점이 더 크다고 판단하여 세번째 방식을 사용하기로 했다.

 

 

---

마치며

로그인 / 회원가입을 구현하면서 보안을 철저하게 하는건 굉장히 어렵다는걸 깨닫고 있다. 웹서비스를 이용하면서 보안적인 부분은 비밀번호 어렵게 만들기 정도로만 쉽게 생각하고 있었는데, 좀 더 개발자스럽게 생각이 바뀌고 있는 것 같다.

 

 

---

참고

refresh token 도입기