JWT Token 인증 정리
더 이상 쿠키를 전달하지 않아도 된다 👉🏻 토큰 기반 인증 시스템을 사용하여 어플리케이션의 보안을 비교적 높일 수 있다.
보안이 뛰어나다❗️ 는 아니지만, 기존 방식에 비해 보안이 좋은 기술이라고 표현할 수 있을 것 같다.
하지만, 누군가 중간에 토큰을 탈취한다면 보안에 큰 취약점이 생긴다.❓
그래서 토큰에 유효기간을 설정한다.
유효기간이 끝나면 새로운 Access Token을 발급받는 방식을 사용한다.
만약 세션을 서버 측에 저장하고 있고 서버를 여러 대를 사용하여 요청을 분산하였다고 생각해보자.
어떤 유저가 로그인 했을 때, 그 유저는 처음 로그인했던 그 서버에만 요청을 보내도록 설정해야한다.
서버를 옮기거나 확장하기에 부담이 된다.
Access Token(JWT)를 통한 인증 방식의 문제점은 제 3자에게 탈취당할 경우 보안에 취약하다는 점이다.
보안을 높이기 위해 Access Token의 유효기간을 짧게 설정하면 사용자는 그만큼 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다.
그렇다고 유효기간을 늘리자니 보안이 취약해지고...
그래서 나온 것이 Refresh Token 이다.
Refresh Token은 Access Token과 똑같은 형태의 JWT이다. 처음에 로그인을 완료 했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료 됐을 때 새로 발급해주는 열쇠가 된다!
예를 들어 Access Token은 유효기간이 30분, Refresh Token은 유효기간이 2주라고 가정하고, 사용자는 로그인을 하고 Access Token과 Refresh Token을 받는다. 클라이언트는 Refresh Token을 안전한 곳(Local Storage?) 에 저장하고, API 요청은 Access Token을 가지고 할 수 있다. 30분이 지나 토큰이 만료되면 Refresh Token을 서버에 보냄으로써 새로운 Access Token을 발급받을 수 있게 되고, 발급받은 Access Token으로 다시 API요청을 할 수 있게 된다.
refresh token도 탈취 당하면 똑같이 보안상 취약점이 생긴다.
access token이 api 요청 시마다 http통신을 통해 노출이 되는 반면, refresh token은 access token이 만료 됐을 경우만 네트워크 통신을 통해 서버로 보내기 때문에 탈취될 위험이 현저히 적다.
그래서 보안상 이점이 있다!
- 사용자 로그인 시 access token과 refresh token 2개 발급
- access token은 30분, refresh token은 2주일
- access token은 username을 payload에 가지고 있음
- refresh token은 DB에 key: username, value: token 형태로 가지고 있음
- Client가 refresh token과 만료된 access token을 가지고 재발급 요청을 보내면
- 만료된 토큰에서 username을 얻고(refresh token에 user정보를 담지 않기 위해서)
- username을 key로 DB에 있는지 확인
- 유효기간도 확인
- 위에서 통과를 못하면 다시 로그인을 통해 refresh token + access token을 처음부터 발급받게 함
- Refresh token은 payload에 아무 정보도 저장하지 않고 그저 유저가 가지고 있던 것과 DB에 저장된 것이 같은지만 확인한다. 물론 변조되지 않았는 지와 만료되지 않았는지는 확인한다.
참고자료