[10주차] 위클리페이퍼 - 세션 기반 인증과 토큰 기반 인증의 차이점을 설명하세요. 어떤 상황에서 각각을 사용하면 좋을지 예를 들어 설명해 주세요.

세션 vs 토큰 기반 인증

• 세션 기반 인증
  • 서버가 사용자의 로그인 상태를 세션에 저장합니다. 이 때, 서버는 각 세션에 대한 식별자(세션 ID)를 발급하고, 이 ID는 사용자의 브라우저 쿠키에 저장됩니다. 사용자가 서버에 요청을 보낼 때마다 이 쿠키를 통해 세션 ID가 서버로 전송(Cookie)되어 사용자를 식별하게 됩니다.
  • 이 방식의 주요 장점은 서버가 사용자의 상태를 계속 추적할 수 있다는 것입니다. 그러나 이로 인해 서버의 자원을 많이 사용하며, 서버의 확장성이 제한될 수 있습니다.
  • 따라서 금융 서비스나 내부 관리 시스템 같이 높은 보안과 세밀한 사용자 상태 관리가 필요한 환경에서 적합합니다.
    
• 토큰 기반 인증
  • 서버가 사용자 인증 후 토큰을 발급하고, 이 토큰에 사용자 식별 정보를 포함시킵니다. 사용자는 이 토큰을 저장하고, 서버에 요청할 때마다 헤더에 토큰을 포함시켜 전송합니다. 서버는 토큰을 검증하고 요청을 처리합니다.
  • 토큰 기반 인증이란 인증 토큰을 사용하는데, 인증 토큰이란 유저에 대한 정보를 암호화한 문자열입니다. 특정 콘텐츠에 접근할 수 있게 해주기 때문에 Access token이라고도 합니다. 토큰의 형식은 JWT(JSON Web Token)형식을 많이 사용합니다.
  • 이 방식의 장점은 서버가 사용자의 로그인 상태를 저장하지 않으므로 확장성이 높다는 것입니다.
  • 따라서 대규모 서비스, 마이크로서비스 아키텍처, 모바일 애플리케이션, 단일 페이지 애플리케이션(SPA)과 같이 확장성과 플랫폼 간 통합이 중요한 환경에서 유리합니다.
    

    

  • 선택 가이드

    상황	추천 인증 방식	이유
    단일 서버 기반 전통적 웹 서비스	세션 기반	구현 단순, 보안 대응 편리
    SPA / 모바일 앱 / 마이크로서비스	토큰 기반 (JWT)	서버 확장성과 RESTful API에 적합
    보안이 최우선인 금융 서비스	세션 기반 + 2FA	세션 무효화 용이, OTP/2FA와 조합 시 안전
    대규모 분산 환경	토큰 기반	서버 상태 저장 불필요, 부하 분산 용이

• 비교
  • 효율성
    • 세션 기반 인증을 사용하면 서버는 항상 로그인 세션 정보를 저장하며, 매 리퀘스트의 유저가 누구인지를 이 정보와 비교를 해야 됩니다. 그리고 이걸 하기 위해서는 용량과 시간이 드는데요. 로그인한 유저가 엄청 많거나 특정 시간에 몰리게 되면 서버의 리퀘스트 처리 속도가 느려질 수도 있습니다.
    • 반면 토큰 기반 인증은 어딘가 저장한 데이터와 비교하는 게 아니라 토큰 자체 내용을 해석하기만 하면 되기 때문에 더 효율적으로 작동할 수 있습니다.
  • 유연성
    • 토큰 기반 인증은 세션 기반 인증보다 조금 더 유연하게 사용될 수 있습니다. 토큰을 발행하는 방법이 똑같고, 시크릿 키만 있으면, 발행한 곳과 확인하는 곳이 달라도 된다는 말인데요.
    • 예를 들어 같은 유저 데이터베이스를 사용하는 여러 서비스들이 있고, 이 사이트들이 같은 방식과 키를 사용해서 토큰을 발행한다면, 한 사이트에서 제공한 토큰을 가지고 있으면, 다른 서비스가 그걸 해석해서 유저를 파악할 수 있는 거죠. 요즘은 크고 복잡한 웹 애플리케이션들을 더 작은 내용을 담당하는 작은 부분들로 나눠서 개발하는 경우가 많은데요. 이럴 때 토큰을 사용하는 게 훨씬 더 유연합니다.
  • RESTful API
    • 세션 정보와 같이 서버가 "상태" 정보를, 예를 들어 유저가 로그인을 했는지 안 했는지 저장하고 있을 때, stateful 하다고 표현하는데요. REST에 부합하기 위해서는 서버가 상태 정보를 저장하지 않는, stateless 한 특성이 있어야 합니다. 서버는 클라이언트에서 보내는 정보만으로 충분히 상태를 파악할 수 있어야 하죠.
    • 이 기준에서 살펴보면 RESTful한 API 서버를 만들고 있다면 세션 기반 인증보다 토큰 기반 인증이 더 어울립니다.
  • 무효화
    • 세션 기반 인증의 장점 중 하나는 바로 서버에서 세션 데이터를 따로 관리하기 때문에 특정 세션을 손쉽게 무효화할 수 있다는 점입니다. 그냥 세션을 관리하는 테이블에 가서 상태를 만료로 바꾸거나 만료일을 지금 당장으로 해버리면 되겠죠?
    • 하지만 토큰 기반 인증을 사용하면 따로 서버가 상태 정보를 저장하지 않기 때문에 특정 토큰을 무효화하는 게 더 복잡합니다. 그리고 이건 꽤 큰 문제들로 이어질 수 있는데요. 예를 들어 금융 서비스에서 누군가 유저 세션을 가로챘는데 이걸 바로 무효화할 수 없다면 저금한 돈을 뺏기는 문제가 생길 수도 있죠. 물론 이중 비밀번호나, OTP라든지 이걸 방지하기 위한 방법들이 있지만, 세션 기반 인증을 사용하면 한 가지 안전장치를 더 쉽게 사용할 수 있습니다.
• 비교 항목

	세션 기반 인증 (Session-based Authentication)	토큰 기반 인증 (Token-based Authentication)
효율성	- 서버가 세션 데이터를 저장하고 매 요청 시 조회 필요- 로그인 사용자 수가 많을수록 DB 또는 메모리 사용량 증가- 트래픽 급증 시 서버 응답 속도 저하 가능	- 토큰 자체에 인증 정보를 포함해 별도의 조회 과정 없음- 요청 시 토큰만 해석하면 되므로 처리 속도 우수- 대규모 트래픽 환경에서도 상대적으로 효율적
유연성	- 발급 및 검증 과정이 서버에 종속적- 단일 서비스 환경에서 단순하고 관리 용이- 다른 서비스 간 인증 공유 어려움	- 발급 서버와 검증 서버가 달라도 시크릿 키만 같으면 문제없음- 동일 사용자 DB를 공유하는 여러 서비스 간 토큰 재사용 가능- 마이크로서비스 및 분산 환경에서 활용도 높음
RESTful API 적합성	- 서버가 로그인 상태를 저장하는 stateful 구조- REST 원칙에서 벗어나며, 서버 확장 시 세션 동기화 필요	- 서버가 상태를 저장하지 않는 stateless 구조 가능- RESTful API 설계 및 서버 확장성에 유리
무효화	- 서버에서 세션 정보를 직접 제어 가능- 특정 세션 삭제 또는 만료 처리로 손쉽게 무효화 가능- 사용자 강제 로그아웃 등 관리 용이	- 서버에서 상태를 저장하지 않으므로 토큰 무효화 어려움- 토큰 탈취 시 위험 커짐- 해결책: 짧은 만료 시간 + Refresh Token + OTP
보안성	- 세션 ID가 탈취되면 계정 도용 가능- HTTPS + SameSite 쿠키 설정으로 완화 가능- 서버에서 강제 무효화 가능해 보안 대응 빠름	- 토큰 탈취 시 만료 전까지 무제한 접근 가능- 토큰 크랙 시 심각한 보안 문제 발생- 해결책: 짧은 만료 시간, Refresh Token, 서명 검증, TLS
확장성	- 서버 간 세션 동기화 필요- 로드 밸런싱 환경에서는 세션 클러스터링 또는 Sticky Session 설정 필요- 서버 수가 많아질수록 관리 복잡	- 서버에 상태 저장 필요 없음- 토큰만 해석하면 되므로 서버 간 세션 공유 불필요- 서버 확장 및 마이크로서비스 환경에 적합
사용 사례	- 단일 서버 기반 웹 애플리케이션- 사용자 수가 비교적 적고, 세션 관리가 쉬운 환경- 예시: 전통적인 PHP/Java 웹사이트, 소규모 사내 시스템	- SPA(Single Page Application) 및 모바일 앱- 마이크로서비스 기반 시스템- OAuth 2.0, OpenID Connect 등 현대적 인증 방식에 적합- 예시: 구글, 페이스북, 넷플릭스, 슬랙, 깃허브
대표 프로토콜	- 기본적으로 **쿠키(Cookie)**와 세션(Session) 기반 동작- 전통적인 서버 렌더링 환경에서 주로 사용	- JWT(JSON Web Token) 기반으로 가장 많이 사용- OAuth 2.0, OpenID Connect 등과 결합 가능
장점 요약	- 서버에서 세션을 직접 제어 가능 → 관리 편리- 세션 무효화가 용이 → 보안 사고 대응 쉬움- 구현 난이도 낮음	- 서버 간 확장성 높음- RESTful API와 자연스럽게 호환- 마이크로서비스 및 모바일 환경에서 활용도 높음
단점 요약	- 서버 확장 시 세션 동기화 필요- 대규모 트래픽 환경에서 비효율적- SPA, 모바일 환경에서는 부적합	- 토큰 무효화 및 탈취 대응 어려움- 토큰 크기 커질 경우 네트워크 오버헤드 증가 가능- 발급 시 서명 관리 필요

 

• 사용하는 이유

구분	세션 기반 인증을 사용하는 이유	토큰 기반 인증을 사용하는 이유
효율성	- 서버가 직접 세션을 관리하여 로그인 상태 확인이 직관적- 매 요청 시 세션 ID만 검사하면 되므로 처리 구조가 단순	- 토큰 자체에 인증 정보 포함 → 서버에서 별도 조회 불필요- 토큰 해석만으로 인증 가능 → 대규모 트래픽 환경에서 효율적
보안성	- 세션 무효화가 용이 → 서버에서 바로 만료 처리 가능- 금융 서비스 등에서 강제 로그아웃 같은 기능을 쉽게 제공	- 서버가 상태를 저장하지 않아 세션 탈취 위험을 줄일 수 있음- 짧은 만료 시간과 Refresh Token을 활용해 보안 강화 가능
확장성	- 단일 서버 환경에서 세션 관리가 단순함- 사내 시스템, 소규모 서비스에서 부담 적음	- 서버 간 세션 공유 필요 없음 → 서버 확장 및 로드 밸런싱에 유리- 마이크로서비스 아키텍처에 최적화
사용성	- 서버에서 세션 정보를 직접 관리하므로 사용자 강제 로그아웃, 비밀번호 변경 시 무효화 같은 기능 구현이 쉬움	- 모바일 앱, SPA 등 다양한 환경에서 통합 인증 가능- 단일 로그인(SSO) 및 크로스 도메인 인증에 적합
RESTful API 적합성	- 세션은 stateful 구조 → REST 원칙과는 다소 상충- 전통적인 서버 렌더링 방식에서는 문제 없음	- 토큰은 stateless 구조 → RESTful API 설계 원칙에 부합- API 서버 간 상태 동기화 불필요
서비스 환경	- 단일 서버, 전통적인 웹 서비스에서 선호- 세션 기반 쿠키 사용에 최적화된 기존 프레임워크와 호환성 높음	- SPA, 모바일 앱, 분산 서버 환경에서 선호- OAuth 2.0, OpenID Connect 등 현대 인증 표준과 호환성 높음
사용 사례	- 전통적인 PHP/Java 웹사이트- 소규모 사내 그룹웨어- 금융 서비스(강제 세션 만료 활용)	- 구글, 넷플릭스, 페이스북, 깃허브- 마이크로서비스 기반 플랫폼- 대규모 RESTful API 제공 서비스

 

• 인증 방식 선택 가이드

[시작]
   │
   ├─► 1) 시스템 구조는?
   │       ├─ 단일 서버/전통적 SSR 웹 중심 ──► [세션 기반 우선 검토]
   │       └─ 분산/마이크로서비스/다수 API 게이트웨이 ──► [토큰 기반 우선 검토]
   │
   ├─► 2) 클라이언트 유형은?
   │       ├─ 데스크톱 브라우저 위주, 쿠키 친화 ──► [세션 기반 적합]
   │       └─ SPA/모바일 앱/다중 클라이언트 ──► [토큰 기반 적합]
   │
   ├─► 3) 확장성과 무상태(Stateless)가 중요한가?
   │       ├─ 예 (수평 확장, 로드밸런싱, 멀티 리전) ──► [토큰 기반 유리]
   │       └─ 아니오 (단일/소규모 운영) ──► [세션 기반도 충분]
   │
   ├─► 4) 즉시 무효화(강제 로그아웃, 세션 킬)가 필수인가?
   │       ├─ 예 (금융/고위험 업무) ──► [세션 기반 우선 + 2FA/OTP]
   │       └─ 아니오 ──► [토큰 기반 가능, 단 만료시간 단축/블랙리스트 고려]
   │
   ├─► 5) SSO/외부 서비스 연동 필요(OAuth2/OIDC)?
   │       ├─ 예 ──► [토큰 기반 표준(OAuth2/OIDC) 채택]
   │       └─ 아니오 ──► [서비스 성격에 따라 위 결정 유지]
   │
   ├─► 6) 운영 편의성/레거시 호환이 중요한가?
   │       ├─ 예 (기존 프레임워크, 서버 제어권 중시) ──► [세션 기반]
   │       └─ 아니오 (표준 토큰, 게이트웨이/프록시 협업) ──► [토큰 기반]
   │
   └─► [결정]
         ├─ 세션 기반 선택 시: SameSite/HTTPS/CSRF 방어 + 세션 스토리지(메모리/Redis) 전략
         └─ 토큰 기반 선택 시: 짧은 Access + Refresh 토큰, 키 롤테이션, 토큰 블랙리스트/리보크 전략