세션 기반 인증과 JWT 토큰 기반 인증

본 블로그는 학습용입니다. 명시적 동의 없는 시스템 접근·정보수집은 불법이며 형사·민사 책임이 따릅니다. 실습은 격리된 테스트 환경에서만 허용됩니다. (형법·정보통신망법·정보통신기반호법 등)

1. 주제 

주제: 웹 인증 방식 비교 분석: 세션 기반 인증과 JWT 토큰 기반 인증

핵심 요약: HTTP의 비연결성(Stateless) 특성에도 불구하고 서버가 사용자를 기억하게 만드는 '상태 유지' 기술을 이해하고, 전통적인 세션 기반 인증과 토큰 기반 인증(JWT)의 원리, 장단점, 그리고 어떤 상황에 어떤 기술을 선택해야 하는지 심층적으로 분석합니다.

---

2. 정의 및 핵심 원리

2.1. 상세 정의

HTTP 프로토콜은 이전 요청을 기억하지 못하는 비상태성 특징이 있습니다. 이 때문에 매번 사용자를 새로 인증해야 하는 문제가 발생하는데, 웹 인증 기술은 서버가 발급하는 증표를 통해 이 문제를 해결하고 로그인 상태를 유지시켜 줍니다.

 

2.2. 핵심 원리 

세션 기반 인증 (Stateful): 서버는 사용자의 로그인 정보를 자신의 메모리나 데이터베이스(세션 스토어)에 저장하고, 사용자를 식별할 수 있는 고유한 ID(세션 ID)만을 클라이언트에게 발급합니다. 클라이언트는 이후 요청마다 이 세션 ID를 쿠키에 담아 보내고, 서버는 저장된 세션 저장소를 조회하여 사용자를 식별하는 방식입니다.

 

JWT 기반 인증  (Stateless):  서버는 사용자의 정보와 권한을 담은 암호화된 토큰(JWT)을 생성하여 클라이언트에게 발급합니다. 서버는 이 정보를 따로 저장하지 않습니다. 클라이언트는 이후 요청마다 이 토큰을 HTTP 헤더에 담아 보내고, 서버는 토큰의 서명을 검증하여 유효성을 확인하고 사용자 정보를 식별하는 방식입니다.

---

3. 주요 기술 및 구성 요소

• 쿠키 : 클라이언트에 저장되는 작은 데이터 조각입니다. 서버로부터 발급받은 세션 ID를 저장하는 역할을 합니다
• 세션 ID : 서버에 저장된 각 사용자의 세션 정보를 구분하기 위한 고유한 식별자입니다. 무작위의 긴 문자열로 되어 있습니다.
• 세션 스토어 : 세션 ID와 그에 매칭되는 사용자 정보가 실제로 저장되는 서버 측의 저장 공간입니다
  주로 서버의 메모리, 또는 Redis, Memcached 같은 별도의 데이터베이스를 사용합니다

JWT의 구성 요소

JWT는 마침표(.)로 구분된 세 부분(Header.Payload.Signature)로 구성됩니다
각 부분은 Base64Url로 인코딩되어 있어 안전하게 URL을 통해 전달될 수 있습니다.

 

헤더: 토큰의 타입(JWT)과 서명에 사용될 해싱 알고리즘(예: HS256, RS256)을 지정하는 JSON 객체입니다.

{ "alg": "HS256", "typ": "JWT" }

 

페이로드: 토큰에 담을 실질적인 정보(클레임)을 포함하는 JSON 객체입니다.
클레임은 등록된(Registered), 공개(Public), 비공개(Private) 클레임으로 나뉩니다

• Registered Claims: 미리 정의된 클레임들로, 필수는 아니지만 사용하는 것이 권장됩니다.
  
• Private Claims: 서버와 클라이언트 간에 협의 하에 사용하는 클레임입니다.
  

{ "sub": "12345", "name": "John Doe", "iat": 1516239022 }

서명 : 토큰의 위변조 여부를 검증하는 가장 중요한 부분입니다. 인코딩된 헤더와 페이로드를 합친 후, 서버만이 알고 있는 비밀 키를 사용하여 헤더에 명시된 알고리즘으로 암호화하여 생성합니다.

---

4. 유형 및 비교

4.1. 주요 인증 방식

상태 저장 인증 : 서버가 클라이언트의 상태(세션 정보)를 직접 저장하고 관리하는 방식입니다. 쿠키/세션 방식이 대표적입니다.

 

상태 비저장 인증 : 서버가 클라이언트의 상태를 저장하지 않는 방식입니다. 모든 요청에 필요한 모든 정보(토큰)가 포함되어 있어, 서버는 이전 요청을 기억할 필요가 없습니다. JWT가 대표적입니다

 

4.2. 방식별 비교

구분	쿠키/세션 기반 인증	JWT 기반 인증
상태 관리	서버가 세션 정보를 저장	서버가 상태를 저장하지 않음 (Stateless)
확장성	낮음 (서버 확장 시 세션 공유 필요)	높음 (토큰만 검증하면 되므로 서버 확장 용이)
서버 부하	높음 (매 요청마다 DB/메모리 조회)	낮음 (토큰 자체 검증, DB 조회 불필요)
보안	세션 ID 탈취 시 대처 용이 (서버에서 강제 로그아웃 가능)	토큰 탈취 시 만료 전까지 대처 어려움 (Refresh Token 필요)
범용성	주로 웹 브라우저 환경에서 사용	웹, 모바일 앱 등 다양한 클라이언트 환경에서 사용 용이
핵심 고려사항	세션 클러스터링, 서버 리소스 관리	토큰 보안(비밀 키 관리), 토큰 탈취 대응

---

5. 활용 사례 및 장단점

5.1. 주요 활용 사례

쿠키/세션 방식

• 전통적인 모놀리식 웹 애플리케이션: 단일 서버 또는 소수의 서버로 구성되어 세션 관리가 비교적 간단한 대부분의 웹사이트(커뮤니티, 블로그 등)의 로그인 기능에 널리 사용됩니다.

JWT 방식

• 마이크로서비스 아키텍처 : 여러 서비스들이 독립적으로 운영되는 환경에서, 중앙 세션 저장소 없이 각 서비스가 토큰만으로 사용자를 인증할 수 있어 매우 효과적입니다.
• 모바일 앱 및 싱글 페이지 애플리케이션 : 네이티브 앱이나 React, Vue.js 기반의 웹 앱에서 서버와 API 통신을 할 때, 쿠키보다 헤더에 토큰을 담아 보내는 방식이 더 간편하고 표준적입니다.

5.2. 장점 및 단점

쿠키/세션

장점: 서버 측에서 사용자의 상태를 완벽하게 제어할 수 있으며, 문제가 발생했을 때 특정 사용자를 강제로 로그아웃시키는 등의 조치가 용이합니다.

단점: 사용자가 많아질수록 서버의 메모리 부하가 커지며, 서버를 여러 대로 확장할 경우 세션 정보를 모든 서버가 공유해야 하는 세션 클러스터링의 복잡성이 발생합니다.

 

JWT

장점: 서버의 상태를 저장하지 않으므로 확장성이 매우 뛰어납니다. 토큰에 필요한 정보가 모두 담겨 있어 별도의 DB 조회가 필요 없어 성능에 이점이 있습니다

단점: 한번 발급된 토큰은 만료 시간 전까지 제어가 불가능하기 때문에 토큰이 탈취되면 보안에 취약할 수 있습니다. 페이로드에 민감한 정보를 담지 않도록 주의해야 합니다.

---

6. 결론

쿠키/세션과 JWT는 각각 명확한 장단점을 가진 인증 방식입니다. 서버 확장 계획이 적고, 서버 측에서 사용자 제어가 중요한 전통적인 웹 환경에서는 쿠키/세션이 여전히 효과적인 선택지입니다. 여러 서비스가 독립적으로 통신하는 마이크로서비스 환경이나 모바일 앱 연동이 필수적인 현대적인 애플리케이션에서는 확장성과 범용성이 뛰어난 JWT가 더 적합한 아키텍처라고 할 수 있습니다.

 

특히 JWT를 사용할 경우 액세스 토큰과 리프레시 토큰을 함께 활용하여 보안성을 높이는 전략을 반드시 고려해야 합니다. 결국 어떤 기술이 절대적으로 우월하다기보다 우리가 만들고자 하는 서비스의 특성과 확장 계획에 맞춰 최적의 인증 방식을 선택하는 것이 중요합니다.