Access Token

• 사용자의 권한이 확인(ex:로그인)되었을 경우 해당 사용자를 인증하는 용도로 발한다.
• 우리가 일반적으로 JWT를 발급받고 설정한 Expires 기간이 지날 때 인증이 만료되게 하는 이것을 Access Token이라고 부를 수 있다.
• Access Token은 그 자체로도 사용자를 인증하는 모든 정보를 가지고 있다. 그렇기 때문에 토큰을 가지고 있는 시간이 늘어날 수록 탈취되었을 때는 피해가 더욱 커진다.

Refresh Token

<aside> 💡 특정한 사용자가 Access Token을 발급받기 위한 용도로만 사용된다.

</aside>

• Refresh Token은 Access Token과 똑같은 형태의 JWT이다. 단지 Access Token을 재발급하는데 관여하는 토큰이므로 행하는 역할이 다르다.
• 서버에 Refresh Token이 저장되어 있기 때문에, 사용의 인증 여부를 언제든지 제어가 가능하다는 장점이 있다.

왜 Refresh Token을 사용하는가?

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

Access Token은 발급된 이후, 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 권한을 인증 → 탈취되면 토큰이 만료되기 전까지 토큰을 획득한 사람 누구나 권한 접근이 가능하다.

JWT는 발급한 후 삭제가 불가능하기 때문에, 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제애 대응을 한다.

이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.

이때 “그러면 유효기간을 짧게 하면서  좋은 방법이 있지는 않을까?”라는 질문의 답이 바로 Refresh Token이다.

예를 들면 처음에 로그인을 했을 때, 서버는 로그인을 성공시키면서 클라이언트에게 Access Token과 Refresh Token을 동시에 발급한다.  서버는 데이터베이스에 Refresh Token을 저장하고, 클라이언트는 Access Token과 Refresh Token을 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을때마다 이 둘을 헤더에 담아서 보낸다.