JWT / 세션

JWT와 세션의 차이점

---

세션

서버에서 인증 정보를 관리하는 방식

세션 동작 방식

1. 사용자가 로그인하면 서버가 세션 ID 생성 후, 서버의 메모리에 세션 정보 저장
2. 로그인 후 생성된 세션 ID를 브라우저의 쿠키에 저장
3. 클라이언트는 서버에 요청을 보낼 때 세션 쿠키와 함께 전송
4. 서버는 요청시 같이 온 세션 ID를 통해 인증을 확인
5. 서버에서 해당 세션 ID 정보를 찾아 해당 정보 기반으로 요청을 처리

세션 저장 방식

저장 위치 특징 장점 단점

서버 메모리(기본)	HttpSession을 서버가 직접 관리	속도가 빠름	서버 부담 증가
DB (MySQL, PostgreSQL 등)	세션 정보를 데이터베이스에 저장	서버 메모리 부담 없음, 유지 보수 용이	속도가 느림
Redis (인 메모리 DB)	세션 정보를 Redis에 저장	빠른 조회 속도, 다중 서버 확장 가능	Redis 운영 필요

특징

• 서버의 메모리에서 세션 정보를 관리하므로 클라이언트가 많아 질 수록 부담이 커질 수 있음
  • 이 부분은 외부 저장소(DB, Redis, 파일 등)에 저장하여 확장성을 높일 수 있다.
  • DB를 사용하면 I/O 부하가 발생해서 속도가 느려질 수 있으므로 일반적으로 Redis를 사용한다.
• 세션 정보는 서버 내부에 저장되기 때문에 보안성이 높다
• 클라이언트는 세션 ID만 관리하면 된다

---

JWT (Json Web Token)

토큰을 이용해서 인증 정보를 유지하는 방식

JWT 동작 방식

1. 사용자가 로그인하면 서버는 JWT(토큰) 발급
2. 클라이언트는 JWT를 쿠키 또는 로컬 스토리지에 저장
3. 이후 요청할 때 마다 HTTP헤더에 JWT를 포함하여 요청
4. 서버는 JWT의 유효성을 검증하고 인증 수행

JWT 인증 과정

서버에서는 JWT를 생성만 하는데 어떻게 인증을 처리하는가?

먼저 JWT에는 3가지 부분이 있다

HEADER.PAYLOAD.SIGNATURE

예제 JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9**(헤더)**.eyJzdWIiOiJ1c2VyMTIzIiwiaWF0IjoxNjg1MDU5MTYwLCJleHAiOjE2ODUwNjI3NjB9(페이로드).6u9e2wMxgMv4_7apqX--YnD39tU2g7L8l9qbg5yQME(시그니쳐)

1. 클라이언트가 요청을 보낼 때 JWT를 포함 (Authorization 헤더)
2. GET /api/user Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
3. 서버는 JWT를 검증한다
   • HEADER : 어떤 알고리즘으로 서명되었는지 확인
   • PAYLOAD : 사용자의 정보가 들어있음
   • SIGNATURE : 서명을 검증하여 변조 여부 확인
4. 서명 검증 방법
   • 서버가 토큰을 발급할 때 SECRET_KEY를 사용해 서명
   • 요청에서 받은 JWT의 서명을 SECRET_KEY로 다시 검증
   • 서명이 일치하면 유효한 JWT(변조되지 않음) → 인증 성공
   • 서명이 불일치하면 변조된 JWT → 인증 실패
5. JWT의 만료 시간(exp) 확인
   • exp의 값이 현재 시간보다 작다면 토큰 만료 → 인증 실패
   • 하지만 exp는 조작 가능성이 있으므로 반드시 서명을 먼저 검증 후 exp 값을 체크하자

SECRET_KEY

• JWT의 서명(Signature)은 SECRET_KEY와 헤더,페이로드를 결합하여 생성된다
• 이후 클라이언트가 요청할 때 JWT를 보내면, 서버에서 SECRET_KEY를 이용하여 서명을 검증한다
• 클라이언트는 JWT의 내용(PayLoad)는 확인 할 수 있지만 서명은 직접 조작 불가능하다 (변조 방지)

SECRET_KEY는 하나인데 토큰이 여러 개일 경우 어떻게 인증을 성공시키는가?

• SECRET_KEY만을 가지고는 각 토큰의 서명을 검증할 수 없다. (헤더, 페이로드가 필요)
• 토큰 생성시 서명은 아래와 같이 생성된다.
• HMACSHA256(BASE64(Header) + BASE64(Payload), SECRET_KEY)
• 인증을 할 때도 SECRET_KEY와 헤더, 페이로드를 모두 포함하여 디코딩 하는 방식이기 때문에 하나의 SECRET_KEY로 모든 서명을 검증할 수 있다.

특징

• 서버가 인증 정보를 저장하지 않아도 됨 → 확장성이 좋다
• 클라이언트가 JWT를 직접 관리해야 한다
• 세션 방식 보다 보안성이 떨어지지만 Refresh Token을 활용하면 보완 가능

---

JWT, 세션 비교 정리

세션 JWT

인증 정보 저장 위치	서버 (메모리, DB)	클라이언트 (토큰)
서버 부담	사용자가 많아질수록 증가	서버 부담이 적음
보안성	세션이 서버에 저장되므로 안전	토큰이 노출되면 위험
확장성	서버가 세션을 관리해야 해서 낮음	서버 부담 없이 확장 가능
유효성 검사	서버에서 세션을 직접 확인	토큰 자체로 인증 가능

언제 어떤 방식을 사용하는 것이 유리할까?

세션이 좋은 경우

• 소규모 서비스에서 간단하게 인증을 처리하고 싶을 때
• 보안이 중요한 서비스 (은행, 사내 시스템)
• MSA 환경에서 사용하려면 같은 세션 저장소를 공유해야한다. (세션 클러스터링)

JWT가 좋은 경우

• 마이크로서비스 아키텍쳐에서 인증을 분리할 때
  • 서버가 상태를 저장할 필요가 없어서 확장성이 뛰어기 때문
  • 중앙 인증서버에 SECRET_KEY를 가지고 인증을 담당하는 방식도 있음
• 모바일 & 웹 동시 로그인 지원 (세션은 브라우저 기반)
• 확장성이 중요한 서비스 (대규모 트래픽 처리)