[Node.js] Cookie, session,jwt(token)

Node.js

[Node.js] Cookie, session,jwt(token)

이경찬 :) 2024. 1. 2. 15:45

CooKie, session, jwt 이용하는 HTTP의 특성

웹 개발에서 쿠키, 세션 및 JSON 웹 토큰(JWT)을 사용하는 것은 HTTP 프로토콜의 특성 및 그것이 제시하는 과제와 밀접하게 연관되어 있습니다. 각 메커니즘이 HTTP의 특정 측면을 처리하는 방법은 다음과 같습니다.

HTTP의 무국적성(상태 비저장):
- HTTP 특성: HTTP는 본질적으로 상태 비저장입니다. 즉, 클라이언트에서 서버로의 각 요청은 독립적이며 서버는 요청 간에 클라이언트에 대한 정보를 유지하지 않습니다.
- 쿠키 및 세션 사용: 쿠키와 세션은 여러 HTTP 요청에서 상태를 유지하는 데 사용됩니다. 쿠키는 클라이언트 측에 정보를 저장하는 반면 세션은 서버 측 저장소를 사용하여 상태를 유지하므로 보다 지속적인 사용자 경험이 가능합니다.
인증 및 승인:
- HTTP 특성: HTTP는 사용자 인증 및 권한 부여를 처리하기 위한 기본 제공 메커니즘을 제공하지 않습니다.
- JWT 사용법: JWT는 통신을 보호하고 인증을 처리하는 데 자주 사용됩니다. 사용자는 로그인하여 JWT를 수신합니다. 이 JWT는 후속 HTTP 요청에 포함되어 서버 측 저장소 없이도 사용자를 인증하고 권한을 부여합니다.
통신 오버헤드:
- HTTP 특성: 각 HTTP 요청은 독립적이며 요청 간 컨텍스트를 유지하는 고유한 방법이 없습니다.
- 쿠키 및 세션 사용: 쿠키 및 세션은 서버가 후속 요청을 특정 사용자와 연결할 수 있도록 하여 통신 오버헤드를 해결합니다. 이는 사용자 세션 전체에서 사용자 인증 및 상태를 유지해야 하는 시나리오에 필수적입니다.
확장성:
- HTTP 특성: HTTP는 서버 측 확장성을 단순화하는 상태 비저장 프로토콜입니다. 그러나 상태 저장 작업에는 문제가 발생할 수 있습니다.
- JWT 사용법: JWT는 자체 포함되어 있으며 서버 측 저장소 없이도 유효성을 검사할 수 있으므로 확장성에 기여합니다. 이는 분산 및 확장 가능한 아키텍처에 유용합니다.
보안 고려 사항:
- HTTP 특성: HTTP에는 고유한 보안 메커니즘이 없기 때문에 다양한 보안 위협에 취약합니다.
- 쿠키, 세션 및 JWT 사용: 이러한 메커니즘은 사용자 인증 및 데이터 무결성과 관련된 보안 문제를 해결합니다. 민감한 정보를 보호하기 위해 암호화 및 서명과 같은 보안 방식이 쿠키 및 JWT에 적용됩니다.

요약하면, 쿠키, 세션 및 JWT는 HTTP의 상태 비저장을 극복하고, 사용자 인증 및 권한 부여를 용이하게 하며, 통신 오버헤드를 해결하고, 확장성을 강화하고, HTTP 프로토콜에 내장된 메커니즘이 없을 때 보안을 보장하기 위해 웹 개발에 사용됩니다. 사용할 메커니즘의 선택은 개발 중인 웹 애플리케이션의 특정 요구 사항과 특성에 따라 달라집니다.

쿠키:

쿠키 설정:

쿠키는 HTTP 응답 헤더에서 서버에 의해 설정됩니다. 서버에는키-값 쌍 및 추가 속성이 포함된 헤더입니다. 예를 들어:
'세트쿠키'

Set-Cookie: user_id=123; Expires=Wed, 21 Oct 2022 07:28:00 GMT; Path=/

쿠키 보내기:

쿠키는 동일한 도메인 및 경로에 대한 각 후속 HTTP 요청과 함께 브라우저에 의해 자동으로 전송됩니다. 서버는 사용자 상태를 유지하기 위해 이러한 쿠키를 수신하고 처리합니다.

도메인 및 경로:

쿠키의 Domain 및 Path 속성에 따라 쿠키가 전송될 수 있는 위치가 결정됩니다. 지정하지 않으면 쿠키는 이를 설정한 도메인으로만 전송됩니다.

만료 및 지속성:

쿠키에는 만료 날짜가 있어 세션 기반 또는 영구 쿠키가 될 수 있습니다. 세션 쿠키는 브라우저를 닫으면 삭제되지만 영구 쿠키는 만료일 또는 수동 삭제까지 유지됩니다.

보안 속성:

쿠키에는 'Secure' 속성(HTTPS를 통해서만 전송됨) 및 'HttpOnly' 속성(JavaScript를 통해 액세스할 수 없으므로 크로스 사이트 스크립팅 공격의 위험을 줄임)과 같은 보안 목적의 속성이 포함될 수 있습니다.

클라이언트측 액세스:

쿠키는 JavaScript를 통해 클라이언트 측에서 액세스할 수 있습니다. 이를 통해 개발자는 쿠키 읽기, 수정, 삭제 등의 작업을 위해 쿠키를 조작할 수 있습니다.

사용 사례:

쿠키는 세션 관리, 사용자 인증, 사용자 선호도 추적, 장바구니 정보 저장, 사용자 경험 개인화 등 다양한 목적으로 널리 사용됩니다.

제한사항:

쿠키에는 크기 제한(일반적으로 몇 킬로바이트)과 같은 제한이 있으며 모든 HTTP 요청과 함께 전송되므로 성능에 잠재적으로 영향을 미칠 수 있습니다.

왜 쿠키를 사용할까?

쿠키는 웹 개발에서 다양한 목적으로 널리 사용되며 사용자 장치에 작은 데이터 조각을 저장하는 수단을 제공합니다. 쿠키가 사용되는 몇 가지 주요 이유는 다음과 같습니다.

세션 관리:
- 쿠키는 일반적으로 웹사이트에서 사용자 세션을 관리하는 데 사용됩니다. 이를 통해 서버는 여러 요청에서 사용자를 식별하고 인식하여 사용자 상호 작용에 대한 상태 저장 정보를 유지할 수 있습니다.
사용자 인증:
- 쿠키는 이용자 인증을 위해 꼭 필요합니다. 사용자가 로그인하면 세션 식별자를 저장하기 위해 세션 쿠키가 생성되는 경우가 많습니다. 이 쿠키는 각 후속 요청과 함께 전송되어 서버가 사용자를 인증하고 로그인 상태를 유지할 수 있도록 합니다.
개인화:
- 쿠키를 사용하면 웹사이트에서 사용자 기본 설정과 설정을 기억하여 사용자 경험을 개인화할 수 있습니다. 예를 들어 웹 사이트는 사용자의 언어 기본 설정, 테마 선택 또는 기타 사용자 정의 옵션을 기억할 수 있습니다.
장바구니 및 전자상거래:
- 전자상거래 애플리케이션에서 쿠키는 사용자의 장바구니에 담긴 품목에 대한 정보를 저장하는 데 사용됩니다. 이를 통해 사용자는 장바구니에 항목을 추가하고, 페이지 사이를 탐색하고, 쇼핑 세션 내내 장바구니의 내용을 유지할 수 있습니다.
추적 및 분석:
- 쿠키는 사용자 행동을 추적하고 분석 데이터를 수집하는 데 자주 사용됩니다. 여기에는 페이지 조회수, 클릭률 및 기타 측정항목에 대한 정보가 포함됩니다. 쿠키는 고유한 사용자를 식별하고 탐색 패턴을 추적하는 데 도움이 됩니다.
사용자 선택 기억:
- 쿠키는 사용자의 선택이나 행동에 대한 정보를 저장합니다. 예를 들어, 웹사이트는 쿠키를 사용하여 사용자가 쿠키를 수락했는지, 알림을 확인했는지, 모달을 닫았는지 기억할 수 있습니다.
인증 토큰:
- 쿠키는 인증 토큰이나 제3자 서비스와 관련된 토큰을 저장하는 데 사용됩니다. 이를 통해 인증 프로세스를 간소화하고 사용자가 자격 증명을 다시 입력하지 않고도 보호된 리소스에 액세스할 수 있습니다.
사용자 추적 및 리마케팅:
- 쿠키는 광고 목적으로 사용자를 추적하는 역할을 합니다. 광고주는 쿠키를 사용하여 웹사이트 전체에서 사용자를 추적하고 타겟 광고를 제공합니다. 리마케팅 캠페인은 쿠키를 활용하여 이전에 특정 웹사이트를 방문한 사용자에게 광고를 표시합니다.
보안 조치:
- 쿠키는 이용자의 인증 및 권한 부여와 관련된 정보를 저장함으로써 보안을 강화할 수 있습니다. 이는 사용자가 필요한 자격 증명을 가지고 있는지 확인하여 웹 사이트의 특정 부분에 대한 무단 액세스를 방지하는 데 도움이 됩니다.
사이트 간 요청 위조(CSRF) 보호:
- 종종 쿠키에 저장되는 안티 CSRF 토큰은 교차 사이트 요청 위조 공격으로부터 보호하는 데 도움이 됩니다. 이러한 토큰은 요청이 예상 소스에서 발생하는지 확인하기 위해 서버에서 유효성을 검사합니다.
CORS(교차 원본 리소스 공유):
- 쿠키는 교차 출처 요청을 제어하는 역할을 합니다. 쿠키의 CORS 헤더는 특정 리소스에 액세스할 수 있는 도메인을 정의하여 원본 간 요청에 대한 보안 수준을 제공하는 데 도움이 됩니다.
로그인 정보 기억하기:
- 쿠키는 사용자 이름이나 이메일 주소와 같은 로그인 정보를 기억하여 재방문 사용자의 로그인 프로세스를 단순화하는 데 사용될 수 있습니다.

쿠키는 웹 개발에 다양한 이점을 제공하지만 책임감 있게 사용하고 사용자 개인 정보 보호를 고려하는 것이 중요합니다. 개발자는 쿠키 사용에 대해 투명해야 하며 개인정보 보호 규정과 모범 사례를 준수해야 합니다. 또한 보안 전송(HTTPS를 통한) 및 민감한 데이터의 적절한 처리와 같은 고려 사항은 안전하고 사용자 친화적인 웹 환경을 유지하는 데 중요합니다.

세션:

세션 시작:
- 세션은 사용자가 처음으로 웹 애플리케이션에 접속할 때 시작됩니다. 이 시작 과정에서 서버는 세션 ID라는 고유 식별자를 생성합니다.
세션 ID:
- 세션 ID는 특정 사용자 세션과 관련된 핵심 정보입니다. 이는 무작위로 생성된 긴 문자열인 경우가 많습니다. 세션 ID는 각 사용자 세션마다 고유하며 해당 세션을 식별하고 추적하는 데 사용됩니다.
클라이언트 측 저장소:
- 세션 ID는 일반적으로 쿠키로 클라이언트에 전송됩니다. 이 쿠키는 클라이언트의 브라우저에 저장되며 이후 요청이 있을 때마다 서버로 다시 전송됩니다. 또는 세션 ID를 URL에 포함하거나 다른 방법을 사용하여 전송할 수 있습니다.
서버측 관리:
- 서버 측에서는 세션 ID를 사용하여 사용자별 데이터를 관리합니다. 이 데이터는 메모리 내 캐시, 데이터베이스 또는 다른 영구 저장 메커니즘으로 구현될 수 있는 세션 데이터 저장소에 저장됩니다.
세션 데이터:
- 세션 데이터에는 사용자와 웹 애플리케이션의 상호 작용과 관련된 정보가 포함됩니다. 여기에는 인증 상태, 사용자 기본 설정, 장바구니 항목 또는 요청 전반에 걸쳐 지속되어야 하는 기타 데이터가 포함될 수 있습니다.
세션 데이터 업데이트 중:
- 사용자가 애플리케이션과 상호 작용하면 서버가 세션 데이터를 업데이트합니다. 예를 들어 장바구니에 항목 추가, 사용자 기본 설정 변경, 사용자 인증 상태 업데이트 등이 있습니다.
세션 만료:
- 세션에는 일반적으로 서버 리소스 관리 및 보안 강화를 위해 만료 기간이 있습니다. 사용자가 특정 기간(유휴 시간 초과) 동안 활동이 없으면 세션이 만료되어 재인증이 필요할 수 있습니다.
로그아웃 및 세션 종료:
- 사용자가 로그아웃하면 서버 측에서 해당 세션을 파괴하는 경우가 많습니다. 이렇게 하면 클라이언트 측의 세션 ID 쿠키가 무효화되고 사용자 세션이 종료됩니다.
보안 조치:
- 세션에는 보안 고려 사항이 적용됩니다. 도청을 방지하려면 세션 ID를 HTTPS를 통해 안전하게 전송해야 합니다. 또한 세션 하이재킹이나 세션 고정과 같은 일반적인 공격으로부터 보호하기 위한 조치를 취해야 합니다.
세션 ID 재생성:
- 보안상의 이유로 사용자 인증이나 권한 수준 변경과 같은 특정 이벤트 후에 세션 ID를 다시 생성하는 것이 일반적입니다. 이는 세션 관련 공격의 위험을 완화하는 데 도움이 됩니다.
CORS(교차 원본 리소스 공유):
- 웹 기반 클라이언트를 다룰 때 CORS 헤더를 고려하여 세션 데이터에 액세스할 수 있는 도메인을 제어하는 것이 중요합니다. 이는 다른 도메인으로부터의 무단 액세스를 방지하는 데 도움이 됩니다.
제한사항:
- 세션에는 서버 리소스 사용량, 동시 사용자 세션을 처리하기 위한 저장 메커니즘 필요성 등 제한 사항이 있을 수 있습니다. 확장성과 성능을 위해서는 적절한 세션 관리가 중요합니다.

요약하면, 세션은 서버가 요청 전반에 걸쳐 사용자에 대한 상태 정보를 유지할 수 있도록 함으로써 웹 애플리케이션에서 중요한 역할을 합니다. 보안, 확장성 및 개인화된 사용자 경험 제공을 위해서는 적절한 세션 관리가 필수적입니다.

세션을 왜 사용할까?

세션은 사용자와 웹 애플리케이션의 상호 작용에 대한 상태 저장 정보를 유지하는 메커니즘을 제공함으로써 여러 가지 이유로 웹 개발에 널리 사용됩니다. 세션이 사용되는 주요 이유는 다음과 같습니다.

상태 기반 상호 작용:
- 세션을 통해 웹 애플리케이션은 사용자 상호 작용에 대한 상태 정보를 유지할 수 있습니다. 이는 서버가 여러 요청에 걸쳐 사용자에 대한 특정 세부 정보를 기억하여 보다 동적이고 개인화된 사용자 경험을 만들 수 있음을 의미합니다.
사용자 인증:
- 세션은 사용자 인증의 기본입니다. 사용자가 로그인하면 고유한 세션 ID가 생성되어 클라이언트 측에 저장되고(종종 쿠키로) 서버의 사용자 세션과 연결됩니다. 이를 통해 서버는 후속 요청에 대해 사용자를 인식하고 인증할 수 있습니다.
세션 데이터 저장:
- 세션을 사용하면 서버 측에 사용자별 데이터를 저장할 수 있습니다. 이 데이터에는 사용자 기본 설정, 인증 상태, 장바구니 내용, 사용자 방문 중에 지속되어야 하는 기타 세부 정보 등의 정보가 포함될 수 있습니다.
사용자 식별:
- 세션은 한 사용자를 다른 사용자와 식별하고 구별하는 방법을 제공합니다. 세션 ID는 사용자 세션의 고유 식별자 역할을 하여 서버가 요청을 올바른 사용자와 연결할 수 있게 해줍니다.
개인화:
- 세션을 통해 웹 애플리케이션은 사용자의 기본 설정이나 이전 상호 작용을 기반으로 콘텐츠나 기능을 제시하여 사용자 경험을 개인화할 수 있습니다. 여기에는 설정 기억, 언어 기본 설정, 사용자 정의 보기가 포함됩니다.
장바구니 및 전자상거래:
- 전자상거래 애플리케이션에서는 장바구니를 관리하기 위해 세션을 사용하는 경우가 많습니다. 사용자가 제품을 탐색하고 장바구니에 항목을 추가하면 세션 데이터가 업데이트되어 쇼핑 세션 전체에서 장바구니의 콘텐츠가 유지됩니다.
보안 조치:
- 세션은 인증 토큰, 사용자 역할 등 민감한 정보를 서버 측에 저장하여 보안에 기여합니다. 이렇게 하면 중요한 데이터가 클라이언트 측의 잠재적인 위협에 노출될 위험이 줄어듭니다.
세션 만료 및 시간 초과:
- 세션에는 일반적으로 만료 기간 또는 유휴 시간 제한이 있습니다. 이를 통해 특정 기간 동안 비활성화된 세션을 자동으로 종료하여 서버 리소스를 관리하는 데 도움이 됩니다. 또한 무단 액세스 기회를 줄여 보안을 강화합니다.
사이트 간 요청 위조(CSRF) 보호:
- 종종 세션 데이터 내에 저장되는 안티-CSRF 토큰은 교차 사이트 요청 위조 공격으로부터 보호하는 데 도움이 됩니다. 이러한 토큰은 요청이 예상 소스에서 발생하는지 확인하기 위해 서버에서 유효성을 검사합니다.
세션 재생성:
- 사용자 인증 후 등 중요한 시점에 세션 ID를 다시 생성하면 보안 강화에 도움이 됩니다. 이 방법은 세션 고정과 같은 세션 관련 공격의 위험을 완화합니다.
확장성 및 서버 리소스 관리:
- 세션은 인메모리 캐싱, 데이터베이스, 분산 캐시 등 다양한 방법으로 관리할 수 있습니다. 적절한 세션 관리는 동시 사용자 세션을 효율적으로 처리하고 서버 리소스를 최적화함으로써 확장성에 기여합니다.
사용자 경험 향상:
- 세션은 사용자 상호 작용의 연속성을 제공하여 원활하고 향상된 사용자 경험에 기여합니다. 사용자는 컨텍스트를 잃지 않고 작업을 수행하고, 페이지를 탐색하고, 개인화된 콘텐츠에 액세스할 수 있습니다.

세션은 수많은 이점을 제공하지만 확장성 문제, 스토리지 메커니즘, 보안 고려 사항 등 관련 문제를 고려하는 것이 중요합니다. 책임감 있는 세션 관리는 안전하고 성능이 뛰어나며 사용자 친화적인 웹 애플리케이션을 구축하는 데 매우 중요합니다.

쿠키와 세션을 사용한 로그인과정

쿠키 생성

사용자가 로그인을 하기위해 아이디와 비밀번호를 입력해 서버에 요청하면, 서버는 로그인 정보를 회원저장소에서 찾아 memberId를 key로 하는 Cookie를 생성해 웹브라우저에게 응답한다.

쿠키의 구조 : key memberId value 1

웹브라우저는 서버의 응답 메시지를 받아 Cookie를 쿠키 저장소에 저장한다.

쿠키 전달

Cookie를 쿠키 저장소에 저장했으니, 이제는 서버에 요청을 할 때마다 쿠키 저장소에서 쿠키를 찾아서 요청메세지에 담는다. 여기서 사용하는 쿠키는 세션 쿠키로 로그인 상태에서, 웹브라우저가 종료되지 않은 상태라면 계속 유지 된다.

위에서 말했듯 서버로 보내는 모든 요청 메세지에 쿠키 정보가 자동으로 포함된다. 따라서 서버는 요청을 한 클라이언트가 누구인지, 정보를 알 수 있다.

하지만 이러한 쿠키 사용엔 심각한 문제점이 있다.

바로 쿠키를 탈취당했을 경우인데, 위의 쿠키의 key는 memberId이지만 만약 쿠키의 key가 주민번호나 신용카드 번호라면 심각한 상황에 놓이게 된다. 따라서 Session을 사용하는데 세션의 동작은 아래에서 알아보자.

Session

세션 생성

추정 불가능한 세션id를 생성해야하므로 UUID를 생성한다.
생성된 세션ID와 세션에 보관할 값인 memberA를 서버의 세션 저장소에 보관한다.
이 때 세션 저장소는 key와 value로 구성되어 있으며 key는 sessionId이고 value는 객체로 이루어져 있다.

세션 id를 응답 쿠키로 전달

서버는 클라이언트에 mySessionId라는 이름으로 세션ID만 쿠키에 담아 전달하고 클라이언트는 받은 mySessionId를 쿠키 저장소에 보관한다.

쿠키의 구조 : key(name) mySessionId value(id) sessionId

따라서 클라이언트와 서버는 결국 쿠키로 연결이 되어야한다.

여기서 중요한 것은 서버는 세션id만 클라이언트에게 전달하므로 쿠키에는 중요한 회원정보등 회원과 관련된 아무런 정보도 담겨있지 않다는 것이다.
오직 추정 불가능한 세션 ID만 쿠키를 통해 클라이언트에 전달한다.

이때 주의해야할 점이 있는데 바로 쿠키와 세션저장소의 key와 value를 헷갈리지 말아야한다는 것이다. 쿠키에는 sessionId를 value값으로 보내는데 세션저장소에서는 sessionId가 key값이 된다. 이를 헷갈리지 말자.

쿠키의 구조 : key SessionName value SessionId
세션 저장소의 구조 : key SessionId value Object

클라이언트의 세션 id 쿠키 전달

클라이언트는 요청시에 항상 mySessionId 쿠키를 전달해 서버에선 해당 쿠키의 정보로 세션 저장소를 조회해 로그인시에 보관한 세션 정보를 사용한다.

총정리

로그인 기능을 구현할 때 쿠키만 사용할 것인지 세션을 사용할 것인지 선택하는 것은 애플리케이션의 특정 요구 사항과 보안 고려 사항에 따라 달라집니다. 다음은 세션이 선호되는 주요 차이점과 이유입니다.

쿠키만 사용:

쿠키 기반 인증:
- 쿠키 기반 인증에서는 사용자의 인증 상태가 쿠키에 저장됩니다. 쿠키에는 일반적으로 각 요청과 함께 전송되는 토큰 또는 식별자가 포함되어 있습니다.
장점:
- 단순성: 쿠키 기반 인증은 구현이 간단합니다.
- Stateless: 세션 데이터에 서버 측 저장소가 필요하지 않습니다.
단점:
- 보안 문제: 인증 토큰을 쿠키에 직접 저장하면 XSS(교차 사이트 스크립팅) 공격이나 악성 브라우저 확장 프로그램을 통한 도난 등의 보안 위험에 노출될 수 있습니다.
- 제한된 서버 측 제어: 사용자 세션의 서버 측 관리가 제한되어 있어 세션 만료 또는 동적 세션 관리와 같은 기능을 구현하기가 어렵습니다.

세션 사용:

세션 기반 인증:
- 세션에는 로그인 시 각 사용자에 대한 고유한 세션 ID가 생성됩니다. 이 세션 ID는 클라이언트 측에 저장되며(종종 쿠키로) 서버에 저장된 사용자별 데이터를 검색하는 데 사용됩니다.
장점:
- 강화된 보안: 세션 데이터는 서버에 저장되어 클라이언트 측 공격에 민감한 정보가 노출될 위험을 줄입니다.
- 서버 측 제어: 세션을 통해 인증 상태, 사용자 역할 및 기타 세션 관련 정보를 포함한 사용자별 데이터를 서버 측에서 관리할 수 있습니다.
- 유연성: 세션은 세션 만료, 동적 세션 관리 및 민감한 데이터의 안전한 저장과 같은 기능 구현에 더 많은 유연성을 제공합니다.
단점:
- 복잡성: 세션을 구현하려면 세션 데이터를 관리하고 저장하기 위한 추가 서버 측 리소스가 필요할 수 있습니다.

세션을 사용하는 이유:

향상된 보안:
- 세션은 인증 토큰과 같은 민감한 정보를 서버 측에 저장하여 더 나은 보안을 제공합니다. 이렇게 하면 클라이언트 측 공격에 노출될 위험이 줄어듭니다.
서버측 제어:
- 세션은 사용자별 데이터에 대한 더 많은 제어 기능을 제공하고 세션 관련 정보의 서버측 관리를 가능하게 합니다. 이를 통해 세션 만료 및 해지를 포함한 동적 세션 처리가 가능해집니다.
확장성:
- 세션은 다양한 저장 메커니즘을 사용하여 구현될 수 있으므로 동시 사용자 세션의 확장성과 효율적인 관리가 가능합니다.
추가 기능:
- 세션을 사용하면 세션 재생성, CSRF 방지 토큰 관리, 인증 상태를 넘어 사용자별 정보의 서버 측 저장과 같은 추가 기능을 구현할 수 있습니다.
보안 표준 준수:
- 많은 보안 모범 사례 및 규정 준수 표준에서는 사용자 데이터를 더 잘 제어하고 보호하기 위해 서버 측 세션 관리를 권장합니다.

쿠키 기반 인증과 세션이 모두 일반적으로 사용되지만 향상된 보안, 서버 측 제어 및 추가 기능이 필수적인 시나리오에서는 세션이 선호되는 경우가 많습니다. 잠재적인 보안 문제를 해결하고 강력한 인증 시스템을 보장하려면 세션을 신중하게 구현하고 관리하는 것이 중요합니다.

JWT란?

JWT(Json Web Token)은 사용자 인증에 필요한 정보를 Json 포맷으로 구성한 토큰이다. 이때 이 값은 암호화되어 있는데, 개인키를 보유한 서버는 이를 통해 토큰의 유효성을 검증할 수 있다.

JWT는 각 구성요소가 점(.)으로 구분되어 있으며 Header, Payload, Signature로 구성된다

1) Header : 토큰의 타입이나, 서명에 어떠한 암호화 알고리즘이 사용되었는지가 저장된다.

2) Payload : 인증에 필요한 사용자에 대한 실질적인 정보가 저장되는 곳이다. 여기에서 주의사항은 Payload에는 민감한 정보를 담지 않는 것이다. header와 payload의 경우 Base64로 인코딩되어있을 뿐, 암호화되어있는 것이 아니기 때문에, 탈취되었을 경우 누구나 값을 확인할 수 있다. key-value 형태로 저장되며 표준 스펙상 key는 3글자로 되어있다. Payload에 담기는 일반적인 key값들은 아래와 같다.

- iss(issuer): 토큰 발급자

- sub(subject): 토큰 제목. 사용자에 대한 식별자가 된다.

- aud(audience): 토큰 대상자

- exp(expiration time): 토큰 만료 시간

- nbf(not before): 토큰 활성화 시간(이 날짜 이전의 토큰은 활성화되지 않음을 보장)

- iat(issued at): 토큰 발급 시간

- jti(JWT id): JWT 토큰 식별자(issuer가 여러 명일 때, 이를 구분하기 위한 값)

3) Signature : 암호화된 서명 값. 토큰의 유효성을 검증하기 위해 사용된다. 구조는 아래 그림에서 확인할 수 있듯이, header와 payload를 합친 값을 개인키로 암호화한 상태이다.

쿠키 장,단점

장점:

단순성: 쿠키는 구현하기 쉽고 웹 브라우저에서 널리 지원됩니다.
자동 처리: 브라우저는 동일한 도메인에 대한 후속 요청에 쿠키를 자동으로 포함하여 세션 관리를 단순화합니다.
서버 측 제어: 서버에 저장된 세션을 통해 사용자 데이터에 대한 더 많은 제어 및 보안이 가능합니다.

단점:

상태 저장: 쿠키는 서버를 상태 저장 상태로 만들어 세션 데이터를 위한 서버 측 저장소를 요구하므로 확장성에 영향을 미칠 수 있습니다.
보안 문제: 적절하게 보안되지 않으면 XSS(Cross-Site Scripting) 공격에 취약합니다.
제한된 저장 용량: 쿠키에는 크기 제한이 있어 저장할 수 있는 데이터 양이 제한됩니다.

세션 장,단점

장점:

서버 측 저장소: 세션은 사용자 데이터를 서버에 저장하여 클라이언트 측에서 민감한 정보가 노출될 위험을 줄입니다.
세션 제어: 서버는 세션 만료, 데이터 무결성 및 보안을 더 강력하게 제어할 수 있습니다.
확장성: HTTP의 상태 비저장 특성이 유지되므로 쿠키에 비해 세션의 확장성이 향상됩니다.

단점:

서버 오버헤드: 서버 측 스토리지가 필요하므로 서버 로드가 증가하고 잠재적인 확장성 문제가 발생할 수 있습니다.
복잡성: 세션 관리에는 특히 분산 또는 로드 밸런싱 환경에서 추가적인 복잡성이 수반되는 경우가 많습니다.
지연 시간 증가: 세션 데이터를 검색하려면 각 요청에 대해 서버 상호 작용이 필요하므로 잠재적으로 대기 시간이 늘어날 수 있습니다.

JWT의 장점과 단점

장점

1) 세션과 같이 별도의 저장소가 필요하지 않다.

2) 별도의 저장소가 없기 때문에 Stateless하고 확장성이 뛰어나다.

3) 세션 인증과 비교했을 때 성능면에서도 유리하다. (세션의 경우 매번 저장소에 접근하여 사용자 정보를 확인해야함)

4) 서명을 통한 보안성을 갖춘다.

단점

1) 사용자 인증에 필요한 정보를 base64 인코딩을 통해 전달하므로, 세션과 비교했을 때 데이터 전달량이 많다(세션의 경우 Session ID만 전달하면 됨). 네트워크 부하가 발생할 수 있다. -> 사용자 인증에 필요한 정보만 포함시키도록 함

2) Payload는 암호화되지 않기 때문에, 민감한 정보를 저장할 수 없다. -> 민감한 정보를 저장하지 않도록 주의

3) 토큰이 탈취당하면 만료될 때까지 대체가 불가능하다. -> 액세스 토큰의 만료 시간을 짧게 가져가고, 대신 사용성을 위해 별도의 리프레쉬 토큰을 만들고 이는 별도의 저장소에 저장한다.