[TIL] Refresh Token 을 사용하는 이유와 구현 방식

 

 

Refresh Token이 필요한 이유:

JWT로 발급하는 토큰은 서버에 저장되지않고 발급된 토큰만으로 인증하는 방식이다.

하지만 이러한 방식은 보안적인 부분에서 한계가 있다.

 

JWT인증 방식의 한계

1. 토큰 탈취 위험

• JWT는 서버에 저장되지 않기 때문에 만약 토큰이 탈취당한다면 대응할 방법이 없.

 

2. Access Token의 만료 시간 문제

• 만료 시간을 길게 설정하면 탈취 당했을 때 악용될 가능성이 커진다.
• 만료 시간을 짧게 설정하면 사용자가 로그인 요청을 자주 받아야하기 때문에 불편해진다.

 

이러한 문제들을 해결하고자 Refresh Token을 함께 이용하는 방식이 생겨났다.

 

 

 

Refresh Token의 역할

1. Access Token 재발급:

Refresh Token을 통해 짧은 만료 시간의 Access Token을 반복적으로 발급받아, 로그인 세션을 유지한다.

 

2.보안 강화:

• Access Token 탈취당한 경우: Access Token의 유효 시간이 짧고 Refresh Token이 없으면 Access Token을 재발급 받을 수 없음.
• Refresh Token 탈취당한 경우: Refresh Token은 서버 DB에 저장되기 때문에 이를 삭제하면 된다.

 

 

(액세스토큰은 약 30분정도로 잡고, 리프레쉬토큰은 2주정도로 잡는다. 이는 상황에따라 다르게 할 수 있음.)

 

 

 

 

기존 방식 구현한 Refresh-token 

refresh-token, access-token 시퀀스 다이어그램

 

 

기존 방식에서는 매 요청마다 Access Token과 Refresh Token을 헤더에 함께 포함시켰다.

 

기존 구현 방식의 문제점:

 

Refresh Token은 Access Token이 탈취되었을 때를 대비하기 위한 추가 인증 수단이다. 하지만 둘 다 헤더에 포함되면 Access Token만 사용하는 것과 다를 바가 없다.

 

 

 

 

 

 

새롭게 구현한 Refresh-token 1)

 

 

Access-Token이 만료되었을때 상태코드 401, message: "Authentication TimeOut" 를 반환함으로써 프론트엔드는 Access-Token이 만료되었다는 사실을 알게되고 Access-Token을 재발급받고나서 다시 요청을 보낸다. 이때 토큰이 없는 경우, 토큰이 유효하지 않는 경우도 상태코드 401로 반환되는데 에러메시지를 통해 이 예외처리들과 구분할 수 있도록 한다.

 

 

 

 

 

 

새롭게 구현한 Refresh-token 2)

 

 

이 방식은 위와 다르게 Access-Token이 만료되었을때 상태코드 401, message: "Authentication TimeOut"를 반환하고 이를 인터셉터로 캐치(상태코드 == 401 && message == "Authentication Time Out" 예외처리)하여 자동으로 다시 Access-Token을 발급 후 이를 헤더에 넣고 다시 API를 재요청한다. 이 모든 과정이 서버에서 이루어지기 때문에 1방식과 차이가 있다.  이때도 마찬가지로 토큰이 없거나 유효하지 않은경우와 구분하기위해 에러 메시지를 통해 구분하여 예외처리를 할 수 있도록 한다.

 

 

 

 

 

 

 

 

참고자료)

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-Access-Token-Refresh-Token-%EC%9B%90%EB%A6%AC-feat-JWT