처음 로그인 기능을 배울 때는 쿠키와 세션을 통해 아이디 기억하기나 자동로그인 작업을 했었다.
하지만, 실무에서는 JWT를 쓴다는 점...ㅎㅎ
각각의 차이가 뭔지, 언제 어떤 거를 쓰는 게 적절할지 정리를 해보려고 한다🤔
1. 세션(Session)과 쿠키(Cookie)
세션은 브라우저와 웹 서버가 연결된 후부터 브라우저가 종료될 떄까지의 시점을 말한다.
👉 세션 인증은 어떻게 진행되는 것일까??
1. 사용자가 로그인 정보를 서버에 전송한다.
2. 서버는 메모리에 사용자를 저장한 뒤, 세션 ID를 쿠키에 담아 사용자에게 돌려준다.
3. 사용자는 세션 ID를 담은 쿠키를 이용해, 이후 요청에서 식별을 하게 된다.
만약, 클라이언트가 요청을 보낼 때 쿠키에 세션ID가 없다면 서버는 세션ID를 생성해서 쿠키에 담아 돌려주게 된다.
위의 방식으로 주로 세션과 쿠키를 같이 사용하게 되고, 둘은 Stateless를 보완한다는 점에서 같이 언급이 된다.
쿠키는 만료시간을 정할 수 있어서 영구 쿠키와 세션 쿠키가 있지만, 세션은 브라우저 종료 시 만료된다.
또한, 쿠키는 클라이언트에 저장되지만 세션은 서버에 저장된다.
어쩌면 한 쪽의 문제점을 한 쪽이 보완하는 방식으로 같이 쓰인다고 볼 수 있다.
👉 세션에 단점이 있다!
- 유저가 늘어나면 서버 램이나 DB에 과부하가 될 수 있다.
메모리에 저장하기도 하지만, 램 부하가 걸리기 쉬워 DB에 저장을 많이 한다.
하지만 많은 사용자는 DB또한 무리가 될 수 있다는 점... - 사용자가 많은 만큼 트래픽이 늘게 되면 여러 프로세스를 돌리거나 컴퓨터를 추가해야 하지만,
세션을 사용하면 분산시키는 시스템 설계가 매우 복잡하고 어렵다. - 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있어 여러 도메인에서 관리하기가 번거롭다.
이는 CORS (Cross-Origin Resource Sharing) 문제라고 한다.
2. Session과 JWT 차이
JWT에 대한 설명은 해당 글을 참고하면 된다.
JWT와 달리 Session은 인증 정보를 서버에 저장하는 것이고,
클라이언트의 요청마다 인증을 위해 DB를 탐색하긴 해야 한다. 또 그를 위한 저장 공간도 필요하다.
| 항목 | Session | JWT |
|---|---|---|
| 상태 관리 | 서버가 상태 관리(Stateful) | 서버가 상태 관리하지 않음(Stateless) |
| 데이터 저장 | 서버 (Session Storage 또는 DB) | 클라이언트 (JWT가 정보를 갖고 있음) |
| 스케일링 | 세션 동기화 필요 (Redis등) | 스케일링에 유리 (토큰만 검증하면 됨) |
| 보안 | 상대적으로 안전 (정보는 서버에만!) | 토큰 탈취 시 위험 (XSS/CSRF 방어 필요!) |
| 추가 요청 크기 | 세션 ID만 전송하므로 작음 | JWT가 비교적 큼 (payload가 많을 수록 더!) |
| 강제 만료 관리 | 서버에서 세션 삭제로 가능 | 복잡함 (만료 시간이나 블랙리스트 관리 필요) |
| 만료 후 재인증 | 세션 만료 시 자동 로그아웃 | JWT 토큰 만료 시 재로그인 요구 |
결국 JWT가 무조건 좋은거다! 라기보단
장단점이 모두 존재하기에 필요한 환경에 맞춰 사용하거나 혼합해서 사용하는 게 좋다고는 한다!
위에 언급했던 XSS나 CSRF등은 JWT 프로젝트를 해보면서 작성해보고자 한다.😂 (어렵다...)
