JWT 토큰에 대해 알아보자

지금까지 여러번 프로젝트에서 사용해본 JWT 토큰에 대해 이번 자체 프로젝트를 개발해보면서 다시금 사용하게 되었다.

어떤 방식으로 어떤 작용을 통해 토큰이 생성되고 유지되고 사용 되는지에 대한 궁금증은 있었지만 적용할 당시에만 겉핥기 식으로 확인하고 적용하기 급급했다가 사용법을 알고나서는 자세히 알아보고자 하는 생각도 하지 않고 기계적으로 사용하기 일쑤였다.

하지만 일정에 여유가 되는 이번 개인 프로젝트에서는 자세히 알아보고 넘어가려 한다.

JWT 토큰이란,

각각의 부분을 알아보자면,

1. Header는 "어떤 알고리즘으로 암호화되었는지"에 대한 정보를 담는다.(ex: HS256)
2. Payload는 JWT 토큰의 핵심으로 "실제로 사용될 데이터" 즉 회원의 운용 부분에서 사용된다면 유저 ID, 만료 시간, 권한 등을 담고 있다.
   이를 Claim이라고 부른다.
3. Signature는 헤더와 페이로드가 "변조되지 않았음을 증명"하는 부분이다.
   서버만 아는 Secret Key로 암호화되어 있어 누군가가 페이로드의 내용을 조작하게 되면 서명이 깨지게 되어 더는 그 토큰을 사용할 수 없다.

그렇다면 기존의 세션(Session)방식과는 무엇이 다른가?

가장 큰 이유는 확장성과 무상태성으로

기존의 세션 방식에서는

• 유저가 로그인하면 서버 메모리(혹은 DB)에 세션을 저장
• 유저가 100만명이면 서버 메모리도 100만 개가 필요. 서버를 여러 대 늘리면 세션 공유 문제도 해결해야함

하지만 JWT 방식에서는

• 서버는 아무것도 저장하지 않음(무상태성)
• 그저 들어온 토큰의 서명만 확인하면 됨.
• 따라서 서버가 몇대이든 상관없고, 모바일 앱 같은 다양한 환경에서도 쉽게 사용이 가능하다.

이런 JWT 방식에서도 단점은 존재하는데

1. JWT 토큰은 한 번 발급된 후 통제가 불가능하다.
   ❗️ 토큰의 유효기간이 끝날때까지 서버가 강제로 토큰을 회수할 방법이 없다
2. 토큰의 크기때문에 네트워크의 부하가 발생할 수 있다.
   ❗️ 세션 ID는 그냥 짧은 문자열에 불과하지만, JWT는 사용자 정보가 많아질수록 길이가 길어진다.
3. 보안 취약점
   ❗️ 토큰의 저장소가 LocalStorage일 경우 XSS공격에 취약해지고, Cookie일 경우 위조 요청 공격(CSRF)에 취약하다.
4. 정보 노출
   ❗️ JWT의 Payload는 암호화된 게 아니라 Base64인코딩된 것이므로 누구나 공식 사이트에서 토큰 디코딩을 통해 내용을 확인할 수 있다.