JWT와 Session의 개념 및 차이

출처 : https://blog.logto.io/ko/token-based-authentication-vs-session-based-authentication

 

JWT(JSON Web Token) 방식과 Session 방식의 개념과 차이

JWT

출처 : https://www.sktenterprise.com/bizInsight/blogDetail/dev/11500

인증 상태를 토큰 자체(클라이언트 보관)에 담아 전달한다. 서버는 보통 토큰 검증(서명 확인)만 한다. (stateless 또는 hybrid)

세션

출처 : https://www.manilatimes.net/2024/07/16/public-square/pr-newswire/session-launches-testnet-incentive-program-ahead-of-token-launch/1957825

인증 상태는 서버(또는 서버가 관리하는 스토어)에 저장된다. 서버에서 제어/무효화가 쉽다. (stateful)

 

아키텍처 차이

세션 (쿠키 + 세션ID)

출처 : https://brunch.co.kr/@ttungcoding/14

1. 로그인 성공
2. 서버가 세션 생성
3. 세션ID를 쿠키로 발급
4. 요청마다 쿠키 전송 → 서버는 세션ID로 세션 조회 → 사용자 정보 확인
5. 서버가 세션 상태(로그아웃, 만료 등)을 완전 제어

JWT (토큰 기반)

출처 : https://www.sktenterprise.com/bizInsight/blogDetail/dev/11500

 

1. 로그인 성공
2. 서버가 서명된 JWT 발급(페이로드에 사용자 정보/만료 등 포함)
3. 클라이언트가 저장(로컬 스토리지, 세션 스토리지, 쿠키 등)
4. 요청마다 Authorization 헤더(Bearer <token>) 또는 쿠키로 전송 → 서버는 서명 검증, 만료 확인만으로 인증
5. 서버는 발급한 JWT를 별도로 저장하거나 추적하지 않으므로 발급된 토큰을 서버에서 즉시 무효화하기가 어려움

보완 관점

토큰/세션 탈취 (XSS, 네트워크 공격)

출처 : https://blog.skby.net/xss-cross-site-scripting/

• 세션 (쿠키)
  
  • 쿠키 기반이라면 HttpOnly + Secure + SameSite로 보호 가능
  • HttpOnly 쿠키는 JS에서 접근 불가 → XSS 공격으로부터 비교적 안전
  • 네트워크에서는 HTTPS로 보호하지 않으면 탈취 위험(패킷 스니핑)
• JWT
  
  • 저장 위치에 따라 다르다
    • localStorage/sessionStorage : JS에서 접근 가능 → XSS에 매우 취약(토큰 탈취 → 즉시 계정 탈취).
    • HttpOnly Cookie : JWT를 HttpOnly 쿠키로 두면 XSS로부터 보호 가능(세션과 비슷)
  • JWT 자체가 XSS에 더 취약하지 않지만 실무에서는 로컬 스토리지에 두는 경우가 많아 XSS 위험이 커진다

민감한 액세스 토큰은 가능하면 HttpOnly + Secure + SameSite=Strict/Lax 쿠키로 전달해야 한다.

CSRF (Cross-Site Request Forgery)

출처 : https://rjswn0315.tistory.com/173

 

• 세션 (쿠키)
  
  • 쿠키는 브라우저가 자동 전송 → CSRF 취약
  • 대응 : SameSite 속성, CSRF 토큰(폼/헤더 기반) 사용, Origin/Referer 검증 등
• JWT
  • Authorization 헤더로 전송하면 브라우저는 자동 전송하지 않으므로 CSRF 위험 낮음
  • 하지만 JWT를 쿠키(특히 자동전송되는 HttpOnly cookie)에 두면 CSRF 취약 → CSRF 방어 필요

JWT를 Authorization 헤더로 보내거나(SPA가 적합) 쿠키로 둘 땐 CSRF 토큰 또는 SameSite로 보강

토큰 무효화(Revocation) & 로그아웃

• 세션
  
  • 서버에서 세션 삭제 한 번으로 즉시 무효화 가능하다
• JWT
  
  • 기본 JWT는 stateless → 발급된 토큰은 만료되기 전까지 유효. 강제 무효화하려면
    • 서버에 블랙리스트 보관 및 확인(stateful 사용)
    • 짧은 만료시간 + 리프레시 토큰(서버에서 관리/검증) 조합
    • 토큰 버전 필드를 DB에 두고 비교(사용자 비밀번호 변경 시 버전 증가하면 기존 토큰 무효화)
  • 복잡도 : JWT 무효화는 설계/운영 부담이 크다.

실무에서는 short-lived access token + revocable refresh token (서버에 저장) 패턴이 일반적이라고 한다.

탈취 시 피해 범위

• 세션 : 탈취된 세션ID는 세션 만료 전까지 사용 가능. 하지만 서버에서 세션 정보(예: IP, 기기, 토큰 버전)를 검사하여 제약 가능
• JWT : 토큰에 권한(scope)이 들어있다면 토큰 하나로 광범위 권한 행사 가능. 만료 기간이 길면 피해가 큼.

권장 : 최소 권한 원칙, 최소 만료 기한, refresh token rotation

세션 고정(Session Fixation)

• 세션 방식에서는 로그인 전에 부여된 세션ID를 탈취자가 고정해두고 사용자가 로그인하면 탈취자가 세션을 사용 가능 → 대응 : 로그인 시 세션ID 재생성(regenerate session id).
• JWT는 세션ID 고정 이슈가 직접적으로 없지만 발급 로직에서 취약하면 유사 문제 존재

스케일링 & 성능

• 세션 : 서버(또는 중앙 스토어)가 상태를 저장 → 수평확장 시 세션 공유가 필요
• JWT : stateless라서 검증만 하면 되어 확장 용이 → 성능/확장성 유리

단, JWT 무효화를 위해 블랙리스트/토큰 저장을 추가하면 결국 stateful이 됨.

 

결론

• 단순하고 안전하게 로그아웃/무효화가 필요하면 서버사이드 세션이 더 직관적이고 안전하다.
• 확장성(무상태 인증), 마이크로서비스 환경, 외부 인증(SSO) 요구가 있다면 JWT가 유리하나 반드시 짧은 accss token + 서버관리 refresh token + 안전한 저장(쿠키 + HttpOnly) 패턴을 사용해야 한다.
• 보안의 핵심은 저장 위치와 만료/회수 정책. 토큰 자체보다 어디에 저장하느냐가 더 위험을 좌우한다.
• 마지막으로 HTTPS 필수, XSS/CSRF 방어, 토큰 최소권한/짧은 수명, 로그/모니터링은 반드시 도입해야 한다.

느낀 점

완벽한 보완은 없다는 것을 느꼈고 내가 하려는 프로젝트에 어떤 것이 더 어울리고 좋은 방식일지에 대한 고민을 할 수 있는 지식을 갖추게된 시간이었다. 내용 전부를 이해할 수는 없었지만 JWT와 Session에 대한 전반적인 이해를 할 수 있어 좋았다.