JWT 인증 방식 로그인
기존의 세션 기반 인증 방식은 사용자의 인증 정보가 서버의 세션 저장소에 저장되어 메모리의 과부하를 초래할 수 있다는 단점이 있다.
반면에 JWT방식은 사용자의 인증 정보를 토큰 형태로 클라이언트 측에서 저장 하므로 서버의 부하가 세션 방식에 비해 줄어든다는 장점이 있다.
성능적으로는 JWT방식이 더 우수 해 보일 수는 있으나, 클라이언트 측에서 사용자 정보를 저장한다는 것은 보안적인 측면에서 취약할 수도 있다.
아래는 어떤 방식으로 JWT방식의 취약한 보안을 해결 하였는지에 대한 설명이다.
위 그림은 JWT 인증 방식으로 구현한 서비스의 사용자 인증 과정이다.
- 로그인 과정에서 회원정보 확인 후 Access Token과 Refresh Token을 클라이언트 측에 저장한다.
Refresh Token
- 짧은 유효기간을 가진 Access Token의 특성상 유효기간이 만료 될 때마다 다시 로그인을 해야하는 불편함이 있기에, 유효기간이 긴 Refresh Token을 같이 발급하여 사용자의 세션 유지 기간을 늘렸다. 이후, 사용자는 Refresh Token이 유효하다면 Access Token이 만료되더라도 Refresh Token으로 대신 인증 한 후 Access Token을 다시 발급받을 수 있게 된다.
토큰 저장 방식
- 발급받은 토큰은 각자
Cookie와Redux에 저장된다.
Local Storage에 저장하는 방식은 스크립팅 공격에 취약 하므로Cookie의 HttpOnly 옵션을 이용해 보안성을 높혔다. 하지만Cookie도 CSRF 공격에 취약하다는 단점이 있어, 보안의 허점이 있다. - 이 문제를 해결하고자 Access Token은
Redux에 저장하였다.Redux는 데이터를 메모리에 저장하는 방식으로,Cookie와는 저장 방식이 달라 두 토큰 모두 탈취당하는 가능성을 줄였다.
Redux에 토큰을 저장할 시에 발생하는 문제점
- 메모리는 휘발성이라 사용자가 사이트를 새로고침 할 시에 토큰 정보가 초기화 된다는 문제점이 발생 했었다.
- 그래서 새로고침 시에
Cookie에 저장되어있는 Refresh Token을 서버에 인증 요청을 보내 Access Token을 다시 발급 하게끔 구현하였다. 새로고침 할 때마다 인증을 받고 다시 토큰을 재발급 받는 로직이 추가되어 부하가 늘어 날 수 있지만, 새로고침 할 일이 많지 않을 거라 판단된다면 이렇게 구현해도 무방 할 것이다.
그래도 여전히 존재하는 토큰 탈취의 가능성
- 두 토큰을 서로 다른 곳에 저장 한다고 해도, 해킹의 난이도는 올라 가겠지만 여전히 탈취 가능성은 남아있다.
Refresh Token Rotation기법을 적용하여 기존의 Refresh Token을 이용하여 Access Token만을 재발급 받았었던 방식에서 Refresh Token도 함께 재발급 받는 것이다.- 이렇게하면 Refresh Token의 생명주기가 짧아져 둘 다 모두 탈취당했다고 해도 기존의 탈취당한 Refresh Token은 유효하지 않기 때문에 해커의 활동 가능 기간이 줄어들게 된다.
(예: Access Token의 유효기간이 2시간이라면 2시간 뒤 Refresh Token도 재발급. 즉, Refresh Token의 실질적인 유효기간도 2시간이 되는 것이다.)
Second brain