Refresh Token 도입 이야기

API 서버를 만들어보면서 회원 인증 방법에 대해 JWT를 택했다.

 

JWT는 AccessToken과 RefreshToken으로 회원을 구분한다.

 

처음에는 Refresh Token의 필요성에대해 전혀 이해가 가지 않았다.

그냥 Access Token을 Refresh Token 처럼 만료 기한을 길게 잡고 쓰면 되는것이 아닌가?

DB에서 Access Token을 저장하며 사용하면 탈취시 대응할 수 있지 않는가?

 

전혀 JWT의 장점을 이해하지 못한 상태에서 생각할 수 있는 수준 정도였던 것 같다.

 

클라이언트가 서버에 인증 과정을 거쳐 JWT인 Access Token과 Refresh Token을 발급 받는다.

 

먼저 Access Token에 대해 알아보자.

Access Token

Access Token은 만료 시간을 짧게 가져간다.

왜일까? 내가 누구인지를 증명하기 위해 서버와 함께 자주 통신하기 때문에 탈취 위험이 커서 만료 시간을 짧게 가져가는 것이다.

 

여기서 Refresh Token을 사용하지 않고

Access Token을 Refresh Token만큼 길게 만료 시간을 가지면 안되는 이유를 찾을 수 있다.

 

Refresh Token

RefreshToken은 만료 시간을 길게 가져간다.

왜일까?

클라이언트는 Access Token으로 서버에 내가 누구인지 알리는데

Acess Token은 보안상 만료 시간을 짧게 가져가기에 만료시 다시 로그인과 같은 인증 과정을 거쳐야한다는 문제가 발생한다.

이 문제를 해결하기위해 Refresh Token을 통해 로그인 과정을 거치지 않고 Access Token을 재발급 받는 것이다.

 

그럼 Refresh Token도 탈취 위험이 있는데

그냥 Access Token의 만료 기간을 길게하면서

서버측 DB에 저장하며 탈취에 대응하면 되는거 아닌가?

 

이런 생각이 들었는데 이제 명확하게 이해가 갔다.

 

JWT는 사용자 인증에 필요한 모든 정보가 이 토큰안에 있기에 별도의 인증 저장소가 없다는 장점이 있다.

즉, 저장소가 없어 stateless하여 인증 서버나 DB에 의존하지 않고 인증이 가능하다는 장점이다.

 

Access Token을 관리하기 위해 DB를 사용하는 순간

JWT의 장점을 전혀 누릴 수 없는 상황이 되는 것이다.

그래서 Access Token을 저장소에 저장하지 않는다.

 

그러나 서버측에서 보안 주도권을 가지기 위해

Refresh Token을 서버에서 관리하는것은 꽤나 타당한 것 같다.

 

Access Token은 유효 기간이 짧아 빈번하게 인증 과정을 서버에 요청하지만

 

Refresh Token 같은 경우 Access Token의 재발급시에만 요청하기에 비교적 적은 요청이 들어오며

DB에 저장하여 관리함으로써 JWT가 stateless함으로 가지는 탈취 위험에 대해 서버가 대응이 가능하다.

 

결론

Access Token을 사용하되 Refresh Token은 서버측에서 관리함으로써

JWT의 단점을 보완할 수 있다.