쿠키·세션·JWT 차이: 로그인 유지 방식과 저장 위치

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

1. 쿠키 세션 JWT 차이는 층위 차이입니다. 쿠키는 저장·전송 수단, 세션은 서버가 상태를 기억하는 방식, JWT는 정보를 전달하는 토큰 형식입니다.

2. 로그인 유지는 상태를 서버가 들고 있느냐 토큰이 들고 있느냐로 갈립니다.

3. 토큰 저장 위치는 JavaScript가 읽을 수 있느냐로 고르고, HttpOnly 쿠키가 먼저 검토할 후보입니다.

로그인을 만들다 보면 쿠키로 할지, 세션으로 할지, JWT로 할지 한 번은 부딪힙니다. 쿠키 세션 JWT 차이를 검색해도 설명이 제각각인데, 세 단어가 같은 줄에 놓이는 개념이 아니라서 그렇습니다. 이번에는 로그인 뒤 상태를 이어가는 방식과 저장 위치를 구분해 살펴봅니다.

쿠키 세션 JWT 차이, 셋은 같은 층위가 아닙니다

쿠키는 브라우저가 저장했다가 요청마다 돌려보내는 작은 데이터입니다.

MDN 웹 문서 정의로 쿠키는 서버가 브라우저로 보낸 작은 데이터입니다. 서버가 Set-Cookie 헤더로 보내면 브라우저는 저장해 두었다가 Cookie 헤더에 실어 돌려보냅니다.

세션은 서버가 로그인 상태를 들고 있는 방식입니다.

쿠키에는 세션 ID만 담고 사용자 정보와 권한은 서버가 보관하는 구조로, RFC 6265에도 설명이 나옵니다. 참고로 세션 쿠키는 MDN 기준 만료 속성이 없는 쿠키를 말합니다.

JWT는 클레임을 전달하는 토큰 형식입니다.

JWT는 사용자 식별자·발급자·만료 시각 같은 클레임을 전달하는 표준 형식입니다. 서명하거나 암호화할 수 있으며, 이 글과 도식은 로그인에서 흔히 쓰는 서명된 JWT를 기준으로 설명합니다. 서명은 내용을 암호화하지 않으므로 비밀번호 같은 비밀값을 담지 않습니다.

로그인 유지 흐름은 세션 방식과 JWT 방식에서 갈립니다

세션 방식은 요청마다 서버 저장소를 조회합니다.

로그인에 성공하면 서버가 세션 ID를 만들어 Set-Cookie로 내려보내는데, OWASP 세션 관리 가이드 권고대로 이 ID는 의미 없는 임의 값이어야 합니다. 로그아웃할 때도 브라우저 쿠키만 지워서는 부족하고 서버의 세션까지 지워야 합니다.

JWT 방식은 서명과 필요한 클레임을 검증합니다.

JWT는 매 요청마다 세션 저장소를 조회하지 않는 검증 방식으로 구성할 수 있습니다. 서명·만료뿐 아니라 허용 알고리즘, 발급자(iss), 대상(aud) 등 애플리케이션에 필요한 조건도 확인합니다. 위 그림의 서명·exp는 이 과정을 줄여 쓴 표현입니다. 즉시 무효화가 필요하면 차단 목록·토큰 버전·리프레시 토큰 관리처럼 서버 상태가 추가될 수 있습니다. JWT 보안 권고 RFC 8725

로그인 유지 기간은 쿠키 만료와 서버 만료를 따로 정합니다.

Max-Age나 Expires가 없는 쿠키는 브라우저를 닫으면 사라지는데, MDN 경고처럼 탭 복원 기능이 있으면 남기도 합니다. 로그인 유지 체크박스에는 Max-Age를 준 쿠키를 쓰고, 서버 세션의 유휴·절대 만료는 OWASP 권고대로 서버에서 강제합니다.

쿠키는 운반 방법이고 세션은 보관 방법이라고 나눠 읽으면 쿠키 세션 차이가 정리됩니다.

토큰 저장 위치는 수명과 브라우저 접근 방식을 함께 봅니다

HttpOnly 쿠키는 JavaScript가 읽지 못합니다.

HttpOnly는 자바스크립트가 쿠키 값을 직접 읽는 것을 막습니다. 다만 XSS 자체나 악성 스크립트의 요청 실행까지 막지는 않습니다. Secure·SameSite를 서비스 흐름에 맞게 설정하고, 쿠키를 자동 전송하는 요청에는 필요에 따라 CSRF 토큰 등 추가 방어를 적용합니다. OWASP 세션 관리 가이드

localStorage에 둔 토큰은 스크립트가 그대로 읽습니다.

XSS 한 번이면 값이 통째로 털리기 때문에, OWASP HTML5 보안 가이드도 세션 식별자를 로컬 스토리지에 두지 말라고 합니다.

sessionStorage는 탭을 닫으면 사라집니다.

XSS에 읽히는 점은 같고, 로그인이 탭 단위로 풀리니 로그인 유지에는 맞지 않습니다.

우리 서비스는 무엇을 골라야 할까요

첫째, 로그아웃과 차단을 바로 반영해야 하면 서버 세션이 단순합니다.

권한을 바꾸면 곧바로 막아야 하는 관리자 화면이 그렇습니다.

둘째, 여러 서비스가 토큰을 검증할 때 JWT를 검토할 수 있습니다.

공통 발급자의 토큰을 여러 서버가 검증하는 구성이 가능하기 때문입니다. 다만 웹·앱을 함께 운영한다는 사실만으로 JWT가 필수인 것은 아닙니다. 로그아웃, 권한 변경 반영 시점, 키 교체 방식까지 비교해 선택합니다.

셋째, 어느 쪽이든 보안 설정은 직접 정해야 합니다.

세션이라면 로그인 직후 세션 ID를 재발급하고 쿠키에 HttpOnly, Secure, SameSite를 붙입니다. JWT는 RFC 8725 기준으로 알고리즘을 고정한 뒤 iss와 aud를 검증합니다.

로그아웃과 권한 변경이 언제 반영되는지를 정하면 로그인 정책이 구체화됩니다. 쿠키에 세션 ID를 담을 수도, JWT를 담을 수도 있습니다. 쿠키·세션·JWT를 세 가지 대체재로 비교하기보다 저장·전송·검증을 각각 설계하는 편이 정확합니다.

로그인 이후의 경험도 편안하게

로그인은 사용자가 서비스를 처음 만나는 순간이자, 자주 돌아오게 되는 기능입니다. 똑똑한개발자는 회원 가입부터 로그인 유지·권한 관리까지 사용 흐름 안에서 살펴보며 웹과 앱을 만듭니다.

소셜 로그인, 관리자 권한, 기기별 로그인 유지가 고민이라면 현재 구상 중인 흐름을 알려주세요. 사용자와 운영자 모두에게 편한 인증 경험을 함께 정리해 볼 수 있습니다.

감사합니다. :)