ETC

Session 기반 인증과 Token 기반 인증의 차이점과 장단점

Beekei 2025. 2. 21. 15:18
반응형

 

Session 기반 인증

서버 측(Session Storage)에서 클라이언트의 인증 상태를 저장하고 관리하는 방식입니다.

  • 클라이언트가 로그인하면 서버가 Session ID를 생성하고 이를 클라이언트에게 쿠키로 전달
  • 이후 클라이언트가 요청할 때마다 해당 Session ID를 포함하여 서버에 전송
  • 서버는 Session Storage에서 Session ID를 조회하여 인증 및 권한을 검증

Session 인증 흐름

  1. 사용자가 로그인 요청 (ID/PW)
  2. 서버가 사용자 인증 후, 세션을 생성하고 Session ID를 응답 쿠키로 설정
  3. 클라이언트가 이후 요청 시, Session ID를 포함한 쿠키를 서버에 전달
  4. 서버는 저장된 Session ID를 조회하여 사용자 인증 및 권한을 검증
  5. 로그아웃하면 세션을 삭제

✅ 장점

 보안성

  • 세션이 서버에서 관리되므로 클라이언트가 직접 조작할 수 없음
  • 토큰보다 상대적으로 탈취 위험이 낮음 (쿠키의 HttpOnly 설정 가능)

세션 만료 및 강제 로그아웃 가능

  • 서버에서 세션을 제거하면, 사용자는 더 이상 인증되지 않음

적은 데이터 전송

  • Session ID만 전송하면 되므로, 토큰보다 네트워크 사용량이 적음

❌ 단점

서버 메모리 사용 증가

  • 각 사용자별로 세션을 저장해야 하므로, 사용자가 많아질수록 메모리 부담 증가
  • 확장성(Scalability)이 낮아짐 (수평 확장이 어려움)

로드 밸런싱이 어려움

  • 서버가 세션을 저장하므로, 여러 서버를 운영할 경우 Sticky Session 또는 Redis 같은 외부 저장소(Session Storage)가 필요

CSRF 공격에 취약

  • 세션이 Cookie를 사용하기 때문에, CSRF 보호를 위한 추가적인 조치(CSRF Token 등)가 필요

Token 기반 인증 (JWT)

서버에서 인증 정보를 포함한 토큰을 발급하고, 클라이언트가 이를 저장하여 요청 시마다 포함하는 방식

  • 클라이언트가 로그인하면 서버는 JWT(Json Web Token)을 생성하여 클라이언트에게 반환
  • 이후 클라이언트는 요청할 때마다 JWT를 HTTP Header에 포함하여 전송
  • 서버는 JWT를 검증하여 사용자 인증 및 권한 확인

Token 인증 흐름 (JWT 예제)

  1. 사용자가 로그인 요청 (ID/PW)
  2. 서버는 사용자 인증 후, JWT 토큰을 생성하여 클라이언트에게 응답
  3. 클라이언트는 JWT를 LocalStorage 또는 Cookie에 저장
  4. 이후 요청 시, Authorization: Bearer <JWT> 형식으로 HTTP Header에 포함
  5. 서버는 JWT를 검증하여 인증 및 권한을 확인
  6. 로그아웃 시 클라이언트가 토큰을 삭제 (단, 서버에서 강제 만료는 어렵다)

✅ 장점

서버 확장성 (Scalability) 높음 

  • 서버에서 세션을 저장하지 않으므로, 서버가 늘어나도 관리가 쉬움
  • 로드 밸런싱이 필요할 때 Stateless한 방식이므로 모든 서버가 동일하게 처리 가능

OAuth 2.0, Single Sign-On (SSO) 등과 연계 가능

  • JWT는 여러 서비스에서 인증을 공유하는 데 유리

클라이언트에서 정보 확인 가능

  • JWT에는 사용자 정보(예: user_id, role)가 포함될 수 있어, 일부 정보를 클라이언트에서 확인 가능

CSRF에 상대적으로 안전

  • JWT는 주로 Authorization Header로 전송하므로 CSRF 공격에 덜 취약

❌ 단점

토큰 탈취 시 보안 위험 증가

  • JWT는 자체적으로 무효화할 수 없음 (세션과 달리 서버에서 일괄 삭제 불가)
  • 토큰이 유출되면 유효기간 만료 전까지는 공격자가 계속 사용할 수 있음

Payload 크기 문제

  • JWT는 보통 Header.Payload.Signature로 이루어지며, Payload에 많은 정보를 담으면 전송 데이터가 커질 수 있음

토큰 재발급(Refresh Token) 관리 필요

  • JWT가 만료되면 새로 로그인해야 하므로, Refresh Token을 사용하여 재발급 시스템을 구축해야 함

🎯 Session 기반 vs Token(JWT) 기반 비교

유형 Session 기반 인증 Token (JWT) 기반 인증
저장 위치 서버 (Session Storage) 클라이언트 (LocalStorage, Cookie)
서버 확장성 낮음 (서버에서 관리 필요) 높음 (Stateless)
보안성 세션 관리로 안전 (HttpOnly 가능) 토큰 탈취 시 위험
CSRF 취약성 있음 (CSRF 방어 필요) 적음 (Authorization Header 사용)
토큰 무효화 서버에서 즉시 삭제 가능 불가능 (만료될 때까지 사용 가능)
데이터 전송량 Session ID만 전송 (작음) JWT 크기가 클 수 있음
로드 밸런싱 어려움 (Sticky Session 필요) 쉬움 (Stateless)
Single Sign-On (SSO) 어렵다 가능 (OAuth 2.0 활용)

어떤 방식을 선택해야 할까❓

Session 기반 인증이 적합한 경우

  • 일반적인 웹 애플리케이션 (예: 기업 내부 시스템, 관리 페이지)
  • 서버 확장성이 크게 중요하지 않은 경우
  • 보안이 중요하며, 즉시 세션을 만료(즉시 로그아웃)해야 하는 경우

Token(JWT) 기반 인증이 적합한 경우

  • 대규모 서비스 또는 마이크로서비스 아키텍처(MSA) 환경
  • 모바일 앱 + 웹앱에서 동일한 인증 시스템을 사용해야 하는 경우
  • OAuth 2.0 또는 SSO(싱글 사인온)가 필요한 경우
반응형
저작자표시 (새창열림)