세션과 토큰에 대한 기본적인 내용은 이전 블로그를 참고하면 된다.
1. JWT란?
JWT(Json Web Token)는 클라이언트와 서버 간에 정보를 JSON 형식으로 안전하게 전송하기 위해 사용되는 토큰이다. 인증 및 정보 전송에 주로 사용되며, 헤더(Header), 페이로드(Payload), 서명(Signature)의 세 부분으로 구성됩니다. 이 구조는 정보의 안전한 전달을 보장하며, 페이로드 부분은 필요한 인증 정보를 담기 위해 수정될 수 있다.
- 헤더(Header): 토큰의 타입(JWT)과 해싱 알고리즘 정보를 담고 있다.
- 페이로드(Payload): 사용자의 인증 정보 및 필요한 데이터를 담고 있으며, Base64Url로 인코딩되어 표현된다.
- 서명(Signature): 헤더와 페이로드를 합친 후, 비밀키로 해시하여 생성합니다. 이는 토큰의 무결성을 보장한다.
2. JWT 와 세션 비교
2.1. JWT의 장단점
장점
- 분산 시스템에 유리: JWT는 토큰 기반 인증 시스템으로, 서버와 클라이언트 간의 통신이 자유롭고, 서버의 부하를 줄일 수 있다.
- 확장성: 다양한 서비스와의 연동이 용이하며, 마이크로서비스 아키텍처에 적합하다.
- 자가 포함적: JWT는 필요한 모든 정보를 자체적으로 포함하고 있어 별도의 인증 저장소가 필요 없다.
단점
- 토큰 탈취 위험: 한 번 발급된 토큰은 만료될 때까지 유효하므로, 탈취당하면 보안 문제가 발생할 수 있다.
- 토큰 크기: JWT는 세션 ID에 비해 크기가 크므로, 매 요청마다 헤더에 포함시켜 전송해야 하기 때문에 네트워크 부하가 증가할 수 있다.
2.2. 세션의 장단점
장점
- 보안성: 서버 측에서 사용자의 인증 정보를 관리하기 때문에, 보안성이 높다.
- 상태 유지: HTTP의 비연결성, 비상태성 문제를 해결하며, 사용자의 상태 정보를 서버에서 관리할 수 있다.
단점
- 서버 부하: 모든 사용자의 세션 정보를 서버에서 관리해야 하므로, 사용자가 많을 경우 서버의 부하가 증가할 수 있다.
- 확장성 제한: 세션 정보가 특정 서버에 저장되므로, 로드 밸런싱이나 서비스 확장 시 세션 공유 문제가 발생할 수 있다.
3. 왜 JWT 를 써야 할까?
지금까지 했던 Server Side Rendering 방식에선 세션을 사용해왔다. 세션은 서버의 확장성이 제한되는 단점이 있지만, Redis나 Sticky 세션등의 방식으로 해결할 수 있다. 그렇다면 확장성 이외에 어떤 이유로 JWT 를 사용할까?
브라우저는 쿠키를 통해 세션ID를 클라이언트와 서버에게 안전하게 전달할 수 있다.
하지만 브라우저를 제외한 다른 기종은 클라이언트 측에서 화면을 그리는 CSR 방식을 사용하기 때문에 세션보단 JWT 를 사용하는 것이 부하를 줄일 수 있고, 사용자의 경험을 높일 수 있다.
만약 여러 기종을 호환해야 하는 서비스라면 어떻게 될까? 브라우저만을 위해 세션을 쓰게 되면 세션 서버와 JWT 를 사용하는 서버가 각각 있어야 할 것이다.
정리하면 세션보다 JWT를 쓰는 이유는 단순히 확장성 만은 아니다. 브라우저만 사용하는 서비스에서는 세션을 사용하는 것도 좋은 선택이다. 하지만 브라우저가 아닌 다른 기종도 함께 서비스를 해야 한다면 JWT로 통일해 하나의 서버를 운영하는 것이 효율적일 것이다.
Share article
