23년 12월 27일(수요일) - 60번째 TIL

Refresh token이 필요한 이유 

Access token 만을 통한 인증 방식의 문제는, 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다. 

 

발급된 이후에는 서버에 저장되지 않아 토큰 자체로 검증을 하며 사용자 권한을 인증하기 때문에 Access token이 탈취되면 토큰이 만료되기 전까지 토큰을 가지고 있는 사람은 누구나 접근 권한을 가진다. 

 

JWT는 발급 후 삭제가 불가능해서 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대응을 하고 있다. 

 

보통은 유효기간을 짧게 하여 탈취당했을 때의 악용 시간 자체를 줄이는 해결책이 있긴 하지만, 그만큼 사용자는 자주 로그인을 하여 토큰을 발급받아야 하는 불편함이 있었다. 이러한 이유로 Refresh token이 나오게 되었다. 

 

이름이 Refresh token 이라고 붙긴 했지만, Access token과 마찬가지로 JWT이며, 차이점으로는 유효시간이과 역할이다. 

 

Access token은 유효기간을 짧게하고 접근에 관여하는 토큰이라면, Refresh token은 유효기간을 길게하고 재발급에 관여하는 토큰이다. 

 

이를 이용하는 방식은 다음과 같다. 

 

처음에 로그인에 성공하면 응답으로 Access token과 Refresh token을 동시에 발급한다. 서버는 DB에 Refresh token을 저장하고, 클라이언트는 Access token과 Refresh token을 쿠키, 세션, 혹은 웹스토리지에 저장한 뒤 요청마다 헤더에 담아 보낸다. 

 

Refresh token은 긴 유효기간을 가지면서 AccessToken이 만료되었을 때 새로 재발급해주는 역할을 한다. 따라서 만료된 Access token을 서버에 보내면, 서버는 같이 보내진 Refresh token을 DB에 있는 것과 비교하여 일치하면 다시 Access token을 재발급해준다. 

 

그리고 로그아웃을 하면 저장소에서 Refresh token을 삭제하여 사용이 불가능하도록 한다. 

 

Access token의 유효기간은 1시간, Refresh token은 2주 정도로 많이 잡는 편이라고 한다. 

 

 

Access token / Refresh token 재발급 원리 

 

1. 기본적으로 로그인 성공 시 Access token과 Refresh token을 모두 발급한다. 

- 이때 Refresh token만 서버측의 DB에 저장하며, Refresh token과 Access token을 쿠키 혹은 웹스토리지에 저장한다. 

 

2. 사용자가 인증이 필요한 API에 접근하고자 한다면, 가장 먼저 토큰을 검사한다. 

- 이때 토큰을 검사함과 동시에 각 경우에 대해서 토큰의 유효기간을 확인하여 재발급 여부를 결정한다. 

 

• case 1 : Access token과 Refresh token 모두가 만료된 경우 
  • 에러 발생으로 다시 로그인 하도록 함 
• case 2 : Access token은 만료됐지만 Refresh token은 유효한 경우
  • Refresh token을 검증하여 Access token 재발급
• case 3 : Access token은 유효하지만 Refresh token은 만료된 경우
  • Access token을 검증하여 Refresh token 재발급 
• case 4 : Access token과 Refresh token 모두가 유효한 경우
  • 정상 처리 

 

3. 로그아웃을 하면 Access token과 Refresh token을 모두 만료시킴

 

 

Refresh token 인증 과정 

인파 블로그 (클릭 시 블로그로 이동)

 

자세한 과정에 대한 설명은 인파 블로그에 잘 설명이 되어 있지만, 9~11번째 과정은 프론트에서는 Access token의 유효기간을 알 수 있으므로 곧바로 재발급 요청을 할 수도 있다. 

 

참고 링크 

• 인파 블로그 - JWT 인증
• 인파 블로그 - Access token & Refresh token