20221106 TIL JWT를 쓸 때 주의할 점

 

서버에서 사용자 정보를 세션으로 관리해야 하는 세션 기반 인증 시스템과 달리

토큰 기반 인증 시스템에서는 인증이 된 사용자들에게 토큰을 발급하고,

인가가 필요한 경우 클라이언트에서 요청을 할 때 토큰과 함께 요청함으로써

서버에서 상태를 유지하지 않아도 된다.

이처럼 토큰 방식은 stateless라는 큰 장점이 있기 때문에 매우 유용할 것이라고 생각했는데, 

토큰 방식을 이용할 때는 꽤 많은 것들을 고려하지 않으면, 서비스의 안전성에 문제가 생길 수 있다.

 

https://icons.veryicon.com/png/o/miscellaneous/skent-icon/key-69.png

토큰 방식에서 자주 사용되는 JWT를 사용할 때 주의할 점에 대해 알아보자.

JWT는 토큰에 Base64Url로 인코딩 된 사용자 정보가 포함되어있다.

Base64Url은 동일한 문자열에 대해 동일한 인코딩 값을 반환하고, 디코딩이 가능하다.

따라서 토큰을 보면 누구나 전달되는 값을 알 수 있기 때문에 암호화되지 않은 민감한 개인정보를 토큰에 넣는 것은 주의해야 한다.

 

또한, JWT의 세가지 구성요소인 Header, Payload, Signature에서 유효성 검사에 제일 핵심이라고 할 수 있는 Signature는

헤더에서 정의한 알고리즘으로 secret key를 이용해서 Base64Url로 인코딩 된 Header와 Payload를 .으로 이은 값을 해싱한 값이다.

예를 들어 만약 HMAC SHA256알고리즘을 이용한다면

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

위 식을 이용해 signature를 생성하게 된다.

따라서 동일한 알고리즘으로 동일한 payload(사용자 정보를 JSON으로 표현한 값)를 동일한 key를 이용해 JWT를 만들면 동일한 토큰이 계속 생성된다.

따라서 key 관리가 매우 중요하고, key에 추측하기 쉬운 MYSECRET 등 보안에 취약한 key를 넣으면 안 된다.

 

또한, 인가가 필요한 요청 header에 매번 토큰이 포함되기 때문에 payload에 너무 많은 정보가 들어가지 않도록 주의해야 한다.

payload에 많은 정보가 들어갈수록 토큰이 길어지기 때문에 네트워크에 부하가 걸릴 수 있고,

8kb 이상의 헤더를 받지 않는 서버들도 있기 때문이다.

 

게다가 토큰 방식에서는 토큰으로 인가를 하게 되기 때문에 토큰만 탈취하면 토큰 주인이 할 수 있는 모든 것을 할 수 있게 된다.

또한 서버에서 직접 관리하는 세션과 달리 토큰은 stateless라는 특성상

서버에서 토큰 상태를 관리하지 않기 때문에 발행된 이후로 서버에서 통제를 하기가 쉽지 않다.

따라서 탈취당한 상태여도 무효화할 방법이 없다.

따라서 토큰에는 적절한 유효기간을 항상 주어야 한다.

그리고 유효기간이 매우 짧은 토큰을 이용하면 토큰 탈취로 인한 문제를 최소화할 수 있지만,

완전한 해결책은 아니기 때문에 JWT를 사용할 때의 주의점을 항상 인지하고 사용해야 한다!

 

JWT를 처음 써봤을 때 편리했고 많이들 쓴다고 해서 JWT가 좋은 줄만 알고 있었는데,

서버를 재실행해도 매번 동일한 토큰이 생성되는 것을 보고 깜짝 놀라서 JWT토큰을 사용할 때 주의할 점을 찾아보았다.

JWT는 사용하기 매우 편리한 기술이지만, JWT의 한계점을 반드시 인지하고 사용해야겠다는 생각을 했다.

그리고 앞으로 어떤 새로운 기술을 적용할 때 한계점을 먼저 찾아보고,

서비스에 적용했을 때 그 기술의 한계점이 큰 문제를 발생시키진 않을지를 먼저 따져봐야겠다.