이번 delivery 프로젝트에서 유저 기능 구현을 담당하게 되어 JWT 토큰 방식의 로그인을 구현 하던 중 토큰을 쿠키에 저장할지 헤더에 저장할지 고민이 생겼다. 두 가지 방식은 각각의 장단점이 존재한다.

Cookie

쿠키(Cookie)에 저장하는 방식은 서버가 JWT를 발급하여 쿠키에 저장한 뒤, 클라이언트로 전송하는 방식으로, 클라이언트는 자동으로 이후 요청에 쿠키를 포함한다.

장점

• 자동 전달 : 클라이언트가 자동으로 쿠키를 요청에 포함시키므로, 별도의 토큰 관리 로직이 필요하지 않다.
• XSS 공격 방지 : HttpOnly 쿠키를 사용하면 JavaScript로 쿠키에 접근할 수 없다.

단점

• CSRF 공격에 취약 : 쿠키가 자동으로 요청에 포함되므로 CSRF 공격에 노출될 수 있다.
• 도메인 제약 : 쿠키는 도메인 단위로 관리되므로 여러 도메인 간에 토큰 공유가 어렵다.
• 사이즈 제한 : 쿠키에 크기 제한 (약 4KB)이 있어 토큰의 크기가 커질 경우 문제가 될 수 있다.

Header

헤더(Header)에 저장하는 방식은 클라이언트가 JWT를 로컬 저장소에 저장해두고 HTTP 요청 헤더에 JWT를 포함하여 전송힌다.

장점

• CSRF 위험 감소 : 쿠키를 사용하지 않으므로 상대적으로 CSRF 공격에 안전하다.
• 유연성 : 클라이언트 측에서 토큰을 직접 관리하므로 토큰의 저장 및 전송 방식을 원하는 대로 커스터마이징할 수 있다.
• 도메인 독립성(CORS) : 헤더에 저장된 토큰은 특정 도메인에 묶이지 않고 사용할 수 있으므로 특히 MSA와 같은 환경에서 다양한 도메인간의 통신 시 유리하다.

단점

• XSS 위험 : 로컬이나 세션 스토리지에 저장하는 경우, JavaScript로 접근 가능하므로 XSS 공격에 취약할 수 있다.
• 복잡성 : 클라이언트에서 토큰을 저장하고 요청마다 헤더에 추가하는 로직을 직접 구현해야 한다.

결론

사실 쿠키와 헤더 방식 중에서는 일반적으로 헤더 방식이 더 많이 사용된다. 헤더 방식은 서버에 부담이 덜 하고 쿠키 방식은 도메인의 제약이 크기 때문이다. 특히나 서버의 확장성과 유지보수성을 고려한다면 헤더 방식으로 선택하는 것이 좋다.