JWT, 함부로 사용하면 다친다?

요즘 많은 곳에서 JWT를 인증에 사용하시는 것 같습니다. 크게는 MSA를 사용하는 곳부터 세션 스토리지를 둘 여력이 없는 스타트업까지 다양하게 사용하고 계시는 것 같습니다. 

 

물론 이런 흐름에 맞춰 저를 비롯한 많은 취준생분들도 포트폴리오에 인증 레이어를 JWT로 사용했다는 포트폴리오를 많이 봤습니다. 

 

하지만 이런 상황은 면접관들에게 좋은 먹잇감이 되기 쉽다는 것을 취준할 때 면접보면서 깨달았죠. 

 

지금은 현재 회사에서도 JWT를 이용해서 인증을 처리하고 있지만 고려해야 할 사항들이 세션보다 많아 제가 현업에서 겪었던 경험 + 다른 사람이 겪었던 경험 이렇게 혼합해서 정리를 해보려고합니다. 

 

 

JWT 사용시 주의사항

세션을 이용해서 인증을 구현하면 서버가 여러대일 경우 문제가 발생할 수 있습니다. 그 이유는 세션의 stateful하다는 특징 때문인데, 세션 데이터는 서버에 저장되고 사용자의 요청이 다른 서버로 들어가는 경우 (이 경우는 MSA뿐만 아니라 로드밸런싱을 이용한 모놀리식 구조에 해당합니다.) 이 사용자가 어떤 사용자인지 모르는 서버도 존재하기 때문에 문제가 됩니다. 

 

물론, 세션 계층을 Redis로 따로 빼어내면 이런 문제가 해결되지만 인증을 위해 Redis서버와 통신해야 하기 때문에 네트워크 레이턴시와 서버의 자원 (CPU, Memory) 을 사용하기 때문에 이 또한 다른 문제로 이어질 수 있습니다. 

 

이런 Redis라는 세션 스토리지를 두어야하는 입장에서 스타트업의 경우 서버의 비용을 최대한 아껴 고정비를 줄이는 것이 큰 도움이 되기 때문에 JWT가 큰 도움이 될 수 있습니다. 

 

또한, 도메인별 서버가 따로 존재하고 수많은 서버가 있는 MSA의 경우도 마찬가지가 될 수 있겠죠. 

 

토큰의 사이즈

JWT는 유저의 데이터를 얼마나 많이 가지고 있느냐에 따라서 토큰의 크기가 커질 수 있습니다. 

 

이렇게 토큰의 크기가 커지면 네트워크 트래픽을 많이 잡아먹기 때문에 비용적인 측면에서도, 레이턴시의 측면에서도 지양해야하는 상황입니다. 

 

때문에, 유저를 식별할 수 있는 간단한 정보를 JWT에 담음으로써 JWT의 크기에 대한 고민을 해야합니다. 

 

JWT토큰은 불변이다. 

JWT토큰은 한번 발급되면 만료될 때까지 남아있고 제어하기 굉장히 까다롭다는 것이 특징입니다. 이렇게 JWT토큰이 불변이기 때문에 겪을 수 있는 문제들이 몇 가지 있는데 그 중에서 대표적인 것을 정리해봤습니다. 

 

 * 사용자가 로그아웃 하는 경우  *

만약 사용자가 로그아웃을 하는 경우 이미 발급된 토큰은 방치되고 이는 로그아웃을 했음에도 로그인이 된 상태로 돌아다닐 수 있다는 문제가 발생합니다. 

 

이를 위해 로그아웃을 위한 엔드포인트에서 Access Token을 서버로 보낸 뒤 이 토큰을 Redis같은 데이터베이스에 적고 이를 만료될 때까지 가지고 있음으로써 해당 토큰을 재사용할 수 없도록 해야합니다. 

 

이러한 방식을 "토큰을 블랙리스트에 등록한다" 라고 하며 이 방법은 한번 발급된 토큰을 재사용할 수 없도록 매번 Request 필터에서 확인해야한다는 단점이 존재합니다. 

 

* 탈취된 토큰에 대한 대처 * 

만약 사용자의 토큰이 탈취되는 경우 해커는 Access Token이 살아있는 동안 정상적인 유저인척 애플리케이션을 돌아다닐 수 있습니다. 

 

이는 Access Token의 만료시간을 짧게 설정함으로써 해결할 수 있지만 그렇다고 굉장히 짧게 설정할 수는 없는 노릇이기 때문에 보통 15분에서 30분 사이로 Access Token을 설정하는데, 이 시간은 해커가 Access Token을 탈취하면 꽤 널널하게 사용자의 개인정보를 빼낼 수 있는 시간입니다. 

 

이에 대한 대처 방법으로 Access Token에 사용자의 IP를 적는 방법이 있습니다. 토큰에 IP주소가 적혀있고 이를 지속적으로 바꼈는지 확인한다면 토큰이 탈취되더라도 문제를 해결할 수 있습니다. 

 

기존에 발급된 IP주소와 다른 IP주소가 탐지되었다면 해당 토큰을 블랙리스트에 등록하고 사용자에게 다시 로그인을 유도하는 방법으로 이를 해결할 수 있습니다. 

 

* 사용자의 정보가 업데이트 되는 경우 * 

만약 Access Token에 사용자의 권한이나 역할이 적혀있는 상황에서 이 사용자의 역할 혹은 권한이 변경되면, JWT의 불변속성 때문에 재로그인하기 전까지는 서버 입장에서 이 사용자가 업데이트된 것을 확인할 수 없습니다. 

 

이는 JWT토큰에 버저닝을 하는 방법이 해결방안이 될 수 있습니다. 사용자의 정보가 업데이트 되면서 버전을 높여 이 사용자의 토큰이 업데이트 됐음을 서버에 알려주는 것입니다. 

 

하지만 이런 경우 사용자의 토큰의 버전이 이전 버전과 달라졌는지 달라지지 않았는지 지속적으로 확인해야하기 때문에 구현의 복잡성이 올라간다는 단점이 있을 수 있습니다. 

 

손상된 Secret Key로 발급된 JWT토큰

만약 해커가 손상된 Secret Key로 토큰을 만들어서 행동한다면 문제가 발생할 수 있습니다. 만약 Secret Key가 손상되었다면 해커가 위조된 토큰을 발급할 수 있기 때문입니다. 

 

이 때, 위조된 토큰으로 애플리케이션을 돌아다니면 치명적인 보안 문제로 이어질 수 있습니다. 

 

이를 해결하기 위해서는 Secret Key에 대한 전략을 세워야하는데 먼저 MSA의 경우와 Monolithic의 경우를 살펴보죠. 

 

* MSA인 경우 *

만약 MSA에서 JWT토큰을 발급하여 인증을 구현했다면 각 서버별 다른 Secret Key를 이용해서 JWT토큰을 만들면 해결할 수 있습니다. 이 해결 방법은 완전한 해결 방법은 아니고 문제를 전체 애플리케이션으로 확장하지 않게 하기위한 방지책정도인데요. 다른 도메인에 해당 문제로 인해 장애가 전파되지 않게 하기 위함입니다. 

 

때문에, 모든 서버가 같은 Secret Key를 이용하는 것은 꽤나 문제가 되고 이런 경우 애플리케이션 전체 장애로 이어질 수 있습니다. 

 

* Monolithic인 경우 *

아마 대부분의 경우가 이 경우일 것 같은데, 만약 Monolithic에서 JWT토큰을 이용해서 인증을 구현했다면 Secret Key를 지속적으로 바꿔주는 로직이 필요합니다. 

 

항상 같은 Secret Key를 사용하면 Secret Key가 손상되는 경우에 대처하기 힘들기 때문입니다. 

 

 

마치며

저희 회사에서도 JWT를 이용해서 인증을 구현하고 있고, 아마 대부분의 회사들이 JWT를 이용해서 인증을 구현하고 있을 것으로 예측됩니다. 

 

JWT는 세션에 비해 생각해야 하는 것이 많고 애플리케이션의 복잡도가 많이 올라가기 때문에 신중하게 사용해야할 것 같습니다. 

 

만약 자신의 회사에서도 JWT를 사용한다면 위의 문제에 어떻게 대응하고 있는지 알려주세요!

 

혹은 취준생이라면 자칫 단순히 JWT가 Stateless하고 세션에 비해 서버의 부하가 줄어들고 속도가 빠르고 이런 점만 면접관에게 어필한다면 좋은 먹잇감이 될 수 있으니 대비하는 것이 좋을 것 같습니다. 

 

이번 포스팅은 여기서 마치도록 하겠습니다! 긴 글 읽어주셔서 감사합니다. 오늘도 즐거운 하루 되세요!

 

 

출처

https://pragmaticwebsecurity.com/articles/apisecurity/hard-parts-of-jwt.html

The hard parts of JWT security nobody talks about

https://medium.com/@codealfi/understanding-jwt-authentication-benefits-and-limitations-3c388dba172e

Understanding JWT Authentication: Benefits and Limitations