Refresh Token?
로그인 요청을 하고 나서, 서버에서 토큰을 프론트에게 넘겨줄 때, 토큰을 하나 더 만들어서 넘겨준다. 하나 더 만든 토큰을 refresh token이라고 하고 기존에 발행하던 토큰을 access token이라고 한다.
refresh token은 access token이 만료되었을 때, access token을 다시 발행하기 위한 용도로 쓸것이기 때문에 access token보다 유효기간이 길어야 한다.
Access Token(JWT)를 통한 인증 방식의 문제는 해킹을 당했을 경우 보안에 취약하다는 점이 있다.
유효기간이 짧은 토큰의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 토큰을 발급 받아야 하므로 불편하다. 그렇다고 유효기간을 늘리면 토큰을 해킹당했을 때 보안에 더 취약해지게 된다.
이러한 점들을 보완하는게 Refresh Token이다.
-
refresh token은 access token과 같은 형태의 JWT이다. refresh token은 처음에 로그인을 완료 했을 때 access token과 동시에 발급된다. access token보다 긴 유효기간을 가지면서 access token이 만료되었을 때 새로 발급해 주는 열쇠가 된다.
-
access token이 해킹 당하면 정보가 유출된다. 하지만 유효기간을 짧게 해두면 그 기간 안에서만 사용이 가능하기 때문에 더 안전하다는 의미가 된다.
-
refresh token의 유효기간이 만료되면, 사용자는 새로 로그인 해야 한다. refresh token도 해킹될 가능성이 있기 때문에 적절한 유효기간 설정이 필요하다.
Access Token & Refresh Token 인증 과정
1) 사용자가 로그인을 한다.
2) 서버에서 사용자가 입력한 id, pw를 회원 DB에서 값을 비교한다.
3-4) 로그인이 완료되면 Access token, Refresh token을 발급한다. 이때 일반적으로 회원 DB에 refresh token을 저장해 둔다.
5) 사용자는 Refresh token은 안전한 저장소에 저장 후, Access token을 헤더에 실어 요청을 보낸다.
6-7) Access token을 검증하여 이에 맞는 데이터를 보낸다.
8) 유효기간이 지나면 Access token이 만료됐다고 보낸다.
9) 사용자는 이전과 동일하게 Access token을 헤더에 실어 요청을 보낸다.
10-11) 서버는 Access token이 만료됨을 확인하고 권한 없음을 신호로 보낸다.
Access token 말료가 될 때마다 계속 과정 9~11을 거칠 필요가 없다. 프론트에서 Access token의 payload를 통해 유효기간을 알 수 있다. 따라서 프론트단에서 API요청 전에 토큰이 만료 됐다면 바로 재발급 요청을 할 수 도있다.
12) 사용자(프론트)는 Refresh token과 Access token을 함께 서버로 보낸다.
13) 서버는 Access token이 조작되지 않았는지 확인을 한 후, Refresh token과 사용자의 DB에 저장되어있던 Refresh token을 비교한다. 토큰이 동일하고 유효기간도 지나지 않았다면 새로운 Access token을 발급해 준다.
14) 서버는 새로운 Access token을 헤더에 실어 다시 API요청을 진행한다.
장점
- 기존 access token보다 안전하다.
단점
- 구현이 복잡하다. 검증 프로세스가 길기 때문에 자연스럽게 구현하기 힘들다.
- Access token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP요청 횟수가 많아진다. 이는 서버의 자원 낭비로 이어진다.
참고
