TIL [20240612] - Cookie, Session, JWT

이윤성·2024년 6월 12일
0

TIL

목록 보기
36/51

📖 오늘의 학습 키워드

Cookie, Session, JWT

❓ 키워드 선택 이유

튜터님과 대화 중 왜 토큰 방식을 선택하려하는지와 이 환경을 잘 이해하고 있는가?라는 질문을 받았을 때 개념을 자세히 알지 못했습니다. 개념을 명확하게 이해하기 위해서 선택했습니다.

쿠키(Cookie)는 웹 애플리케이션에서 사용하는 작은 텍스트 파일로, 사용자의 브라우저에 저장됩니다.
쿠키는 웹 서버가 브라우저에 전송하고, 이후 브라우저가 서버로 요청을 보낼 때마다 쿠키 정보를 포함하여 전송합니다.
쿠키는 사용자 인증, 사용자 경험 개선, 웹 사이트 트래픽 분석 등 다양한 목적으로 사용합니다.

🍪 쿠키의 구성 요소

  • 이름(Name) : 쿠키를 식별하는 고유한 이름
  • 값(Value) : 쿠키에 저장되는 실제 데이터
  • 도메인(Domain) : 쿠키가 적용되는 도메인 범위
  • 경로(Path) : 쿠키가 적용되는 URL 경로
  • 만료 시간(Expires) : 쿠키의 유효 기간을 나타내는 타임스탬프
  • 보안(Secure) : HTTPS 연결에서만 쿠키를 전송할지 여부
  • HttpOnly : 자바스크립트에서만 쿠키에 접근할 수 있는지 여부

🍪 쿠키의 동작 방식

  1. 브라우저가 서버에 요청을 보낸다.
  2. 웹 서버는 HTTP 응답 헤더에 'Set-Cookie' 필드를 포함하여 쿠키를 브라우저에 전송
  3. 브라우저는 받은 쿠키를 저장하고, 이후 해당 도메인 및 경로에 대한 요청 시 'Cookie' 헤더에 쿠키 정보를 포함하여 서버로 전송
  4. 서버는 받은 쿠키 정보를 사용하여 사용자 인증, 개인화된 서비스 제공 등의 작업을 수행

🍪 쿠키의 종류

  • 세션 쿠키(Session Cookie): 브라우저가 종료될 때까지 유지되는 임시 쿠키
  • 영구 쿠키(Persistent Cookie): 만료 시간이 설정된 쿠키로, 브라우저 종료 후에도 유지됨
  • 제3자 쿠키(Third-Party Cookie): 방문한 도메인과 다른 도메인에서 설정된 쿠키 (예: 광고 추적 등에 사용)

🍪 쿠키의 한계 및 대안

  • 쿠키는 도메인 및 경로 단위로 제한됨(약 20개), 도메인 간 데이터 공유에는 한계가 있음
  • 쿠키의 크기는 제한적이며(일반적으로는 4KB 이하), 너무 많은 쿠키는 성능에 영향을 줄 수 있음
  • 일부 사용자는 쿠키를 차단하거나 삭제할 수 있어, 쿠키에 의존하지 않는 대안 방식(예: 세션, 토큰 등)도 고려해야 함

🍪 쿠키의 보안 고려 사항

  • 중요한 정보는 쿠키에 직접 저장하지 않고, 서버 측에서 관리하는 것이 안전
  • 쿠키에 민감한 정보를 저장할 경우 암호화 등의 보안 조치 필요
  • 쿠키의 'Secure' 속성을 설정하여 HTTPS 연결에서만 전송되도록 제한
  • 쿠키의 'HttpOnly' 속성을 설정하여 자바스크립트에서의 접근을 제한
  • 사용자의 동의를 받고 쿠키 정책을 명확히 공지하는 것이 중요 (예:GDPR, CCPA 등의 개인정보 보호 규정 준수)

📜 Session

세션(Session)은 웹 애플리케이션에서 사용자의 상태를 유지하기 위한 서버 측 메커니즘입니다. 
세션은 사용자가 웹 사이트에 접속하여 인증을 받은 후, 해당 사용자의 상태 정보를 서버에 저장하고 관리하는데
사용됩니다. 세션은 사용자 인증, 개인화된 서비스 제공, 장바구니 기능 등 다양한 웹 애플리케이션의 기능을
구현하는데 핵심적인 역할을 합니다.

📜 세션의 생성 및 관리

  1. 사용자가 웹 사이트에 로그인하거나 인증을 받으면, 서버는 해당 사용자를 위한 고유한 세션 생성
  2. 서버는 세션 ID(Session ID)라는 고유 식별자를 생성하고, 이를 클라이언트에 전송(일반적으로 쿠키를 통해 전송)
  3. 클라이언트는 이후의 요청에 세션 ID를 포함하여 서버로 전송
  4. 서버는 받은 세션 ID를 사용하여 해당 사용자의 세션 정보를 식별하고 관리

📜 세션의 데이터 저장

  • 세션 데이터는 서버 측에서 관리되며, 일반적으로 메모리, 파일, 데이터베이스 등에 저장
  • 각 사용자의 세션 데이터는 해당 사용자의 세션 ID와 연결되어 저장
  • 세션 데이터에는 사용자 인증 정보, 사용자 설정, 장비구나 내용 등 다양한 정보가 포함될 수 있음

📜 세션의 유효 기간

  • 세션은 일반적으로 사용자가 웹 사이트를 떠나거나, 브라우저를 닫을 때까지 유지됨
  • 서버에서 세션 유효 기간(Session Timeout)을 설정하여 일정 시간 동안 비활성 상태인 세션을 자동으로 삭제할 수 있음
  • 사용자가 명시적으로 로그아웃을 수행하면 해당 사용자의 세션이 즉시 삭제됨

📜 세션의 장단점

  • 장점:
    • 사용자 인증 및 상태 관리를 안전하고 효과적으로 수행할 수 있음
    • 서버 측에서 데이터를 관리하므로, 클라이언트 측 쿠키에 비해 보안성이 높음
    • 사용자별로 개인화된 서비스를 제공하는데 유용함
  • 단점:
    • 세션 데이터를 서버에 저장하므로, 서버 부하와 자원 소모가 발생할 수 있음
    • 서버 확장성(Scalability)에 영향을 줄 수 있음 (세션 데이터를 여러 서버에서 공유해야 하는 경우)
    • 클라이언트에서 쿠키를 사용하므로, 쿠키를 지원하지 않는 환경에서는 사용이 제한 될 수 있음

📜 세션의 보안 고려사항

  • 세션 ID는 민감한 정보이므로 안전하게 전송되어야 함 (일반적으로 HTTPS 사용)
  • 세션 ID는 예측 가능하거나 추측하기 쉬운 값이 아니어야 하며, 충분한 길이와 무작위성을 가져야 함
  • 세션 데이터는 서버 측에서 안전하게 저장되어야 하며, 필요한 경우 암호화 등의 보안 조치 적용
  • 세션 하이재킹(Session Hijacking) 공격을 방지하기 위해 정기적인 세션 ID 갱신, IP 주소 확인 등의 대책 필요

🔑 JWT

JWT(JSON Web Token)는 웹 애플리케이션에서 사용자 인증 및 정보 교환을 위한 토큰 기반의 표준화된 방식입니다.
JWT는 JSON 형식을 사용하여 당사자 간에 안전하게 정보를 전달할 수 있도록 설계되었으며, 주로 클라이언트와 서버 간의
인증 및 권한 부여에 사용됩니다.

🔑 JWT의 구조

  • JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)의 세 부분으로 구성
  • 각 부분은 점(.)으로 구분되며, 전체 토큰은 "헤더.페이로드.서명" 형태로 표현됨
  • 헤더(Header):
    • 토큰의 타입(typ)과 해싱 알고리즘(alg)을 지정
    • 일반적으로 {"typ": "JWT", "alg": "HS256"} 형태로 작성되며, Base64URL로 인코딩 됨
  • 페이로드(Payload):
    • 토큰에 포함할 정보(클레임, Claim)를 담고있음
    • 클레임에는 등록된(registered) 클레임, 공개(public) 클레임, 비공개(private) 클레임이 있음
    • 등록된 클레임: 표준에 따라 미리 정의된 클레임
      • iss(issuer): JWT를 발급한 발급자의 식별자
      • sub(subject): JWT에 담긴 정보의 주체
      • aud(audience): JWT가 사용되는 대상자(대상 서비스나 앱)을 나타낸다.
      • exp(expiration time): JWT의 만료 시간을 나타낸다.
      • nbf(not before): JWT가 사용 가능한 시간을 나타낸다.
      • iat(issued at): JWT가 발급된 시간을 나타낸다.
      • jti(JWT ID): JWT의 고유 식별자다. 중복되지않은 고유한 값이어야한다.
    • 공개 클레임: 충돌 방지를 위해 URI 형태로 정의된 클레임
    • 비공개 클레임: JWT를 사용하는 당사자 간에 협의하에 사용되는 커스텀 클레임이다. 공개 클레임과 달리 이름이 중복되어 충돌이 일어날 수 있으니 사용할 때 유의해야된다.
  • 서명(Signature):
    • 헤더와 페이로드를 Base64URL로 인코딩한 후, 비밀키를 사용하여 해싱한 값
    • 서명을 통해 토큰의 무결성을 검증하고, 토큰의 변조를 방지함

🔑 JWT의 동작 방식

  • 사용자가 로그인 등의 인증 과정을 거치면, 서버는 해당 사용자의 정보를 포함한 JWT를 생성
  • 생성된 JWT는 클라이언트에게 전달되며, 클라이언트는 이를 저장 (주로 로컬 스토리지나 쿠키)
  • 이후 클라이언트는 서버에 요청을 보낼 때마다 JWT를 요청 헤더(Authorization 헤더)에 포함하여 전송
  • 서버는 받은 JWT의 서명을 검증하여 토큰의 유효성을 확인
  • 유효한 토큰이면 페이로드에 포함된 정보를 사용하여 사용자 인증 및 권한 부여를 수행

🔑 JWT의 장단점

  • 장점:
    • 상태 비저장(Stateless): 토큰 자체에 필요한 정보를 포함하므로, 서버에서 세션을 유지할 필요가 없음
    • 확장성(Scalability): 상태 비저장 특성으로 인해 서버의 확장성이 좋음
    • 여러 도메인(Cross-domain) 간 사용 가능: 토큰 기반이므로 쿠키의 도메인 제한에 영향을 받지않음
    • 모바일 앱 및 웹 애플리케이션에서 널리 사용됨
  • 단점:
    • 토큰의 길이: 토큰에 많은 정보를 포함하면 길이가 길어질 수 있음
    • 토큰 만료 전까지는 유효하므로, 토큰 만료 시점까지 권한 변경이 어려울 수 있음
    • 토큰 자체는 암호화되지 않으므로, 중요한 정보는 토큰에 직접 포함하지 않는 것이 좋음
    • 서버 측에서 토큰의 블랙리스트를 관리하거나, 추가적인 검증 로직이 필요할 수 있음

🔑 JWT의 보안 고려사항

  • 토큰의 유효 기간을 적절히 설정하여, 만료된 토큰의 사용을 방지
  • 토큰의 서명에 사용되는 비밀키는 안전하게 관리되어야 함
  • 페이로드에 민감한 정보를 포함하지 않도록 주의 (토큰은 일반적으로 암호화되지 않음)
  • 토큰 탈취 공격(XSS, CSRF 등)에 대한 대책 마련 필요

📚 오늘의 회고

강의를 받아서 듣고 있는데 왜인지는 모르겠지만 강의가 크게 와닿지않는 느낌을 받습니다. 이것을 어디서, 왜 사용해야하는지 감이 안와서인지는 모르겠지만 개인 과제를 진행하면서 이해가 될 것같은 생각을 했습니다. 세션 하이재킹, XSS, CSRF공격은 처음 들어보는데 이 부분에서도 따로 다뤄야할 만큼의 분량들이 검색되는거보니 공부해야될 목록에 포함시켜야겠습니다.

0개의 댓글