쿠키, 세션, 토큰, 캐시.

하쮸·2024년 12월 31일

쿠키, 세션, 토큰

목록 보기

1/2

1. 쿠키.

쿠키는 클라이언트(브라우저) 측에 저장되는 key-value형태의 문자열로 이루어진 작은 데이터 파일.
- 클라이언트가 어떠한 웹사이트에 접속할 경우 해당 사이트의 서버를 통해 클라이언트의 브라우저에 저장되는 작은 기록 정보 파일.
- 각 사용자마다의 브라우저에 정보를 저장하니 고유 정보 식별이 가능함.
쿠키의 특징.
- 브라우저 단위로 생성됨.
  - 즉, 같은 기기로 같은 도메인 사이트를 방문 했어도 크롬, 사파리, 웨일과 같이 다른 브라우저로 접속 시 다시 쿠키를 발급받아야됨.
- 다른 도메인을 대신해서 쿠키를 발급해줄 수 없음.
- 만료 시간까지 로그인 유지와 같은 상태 정보 유지.
  - 만료 시간은 서버에서 쿠키를 만들 때 설정 가능.
웹 사이트 재방문 시 효율적으로 서비스를 제공해주기 위해서 사용됨.
- 상태를 유지할 수 없는 HTTP 프로토콜의 특성때문에 쿠키를 이용해서 상태를 저장함.

클라이언트에서 로그인을 요청하면 서버는 HTTP헤더에 쿠키를 담아서 반환해줌.
Ex
- 아이디를 자동완성 해주는 기능, 로그인 유지 기능.
- 공지 메시지를 하루 안 보기.
- 로그인을 안 한 상태로 쇼핑몰 웹 사이트에서 장바구니에 담는 기능.
  - 갑작스런 오류로 인해 브라우저가 종료돼서 다시 접속해도 장바구니 내역이 그대로 유지되어 있음.


- 1. 클라이언트는 로그인을 하기 위해 이메일, 패스워드를 서버로 요청을 보냄.	- 2. 요청을 바탕으로 유저 정보를 찾아서 쿠키를 반환.
- 3. 반환 받은 쿠키를 저장소에 보관.	- 4. 쿠키에 들어있는 정보를 통해 로그인을 유지.

쿠키는 발급받은 사용자뿐만 아니라 다른 제 3자가 조회하는 것도 가능하기 때문에 민감한 개인 정보를 저장하는 데에는 적합하지 않음.
즉 사용자의 편의를 위하되, 삭제되거나 조작 및 탈취되더라도 치명적이지 않은 수준의 정보들을 브라우저에 저장하는데 사용됨.
- 단순히 쿠키만 사용해서 관리하면 사용자의 개인정보가 클라이언트에 저장되어 있기 때문에 위변조 및 도용 문제가 발생할 수 있음.
- 용량에 제한이 있어서 많은 정보를 담을 수 없음.
- 위와 같은 문제점을 해결하기 위해서 쿠키 + 세션을 같이 사용함.

1-1. 쿠키 + 세션.


- 1. 서버에 세션 DB가 생겼고 sessionId라는 칼럼이 추가 되었음. - 쿠키에 세션 아이디를 담아서 반환해줌.	- 2. 쿠키에 저장되어 있던 세션id를 보고 만약에 세션이 만료되지 않았다면 해당 세션id에 맞는 유저가 있는 지 확인하고 응답함.

Session 쿠키
- 웹 브라우저가 종료될 때 제거됨.
Persistent 쿠키
- 브라우저를 종료해도 쿠키가 남아있음.
- 쿠키를 생성할 때, Expires 또는 Max-Age 옵션을 추가함.
  - Expires
    - 만료 날짜.
    - ```
    document.cookie = "user=John; expires=Fri, 31 Dec 2025 23:59:59 GMT";
```
- Max-Age
  - 최대 수명.
  - ```
  document.cookie = "user=John; max-age=3600"; // 1시간 동안 유효
```
- Expires 또는 Max-Age를 지정해주지 않으면 Session 쿠키로 간주됨.

-	세션 쿠키(Session Cookie)	지속 쿠키(Persistent Cookie)
저장위치	브라우저 메모리.	사용자의 장치.(하드 디스크)
수명	브라우저를 닫으면 삭제.	설정된 만료 시간까지 유지.
사용 목적	세션 유지.(로그인 상태, 장바구니 등)	사용자 설정 유지.(자동 로그인, 언어 설정 등)
보안	상대적으로 안전.	탈취 가능성이 있어 암호화 필요.

2. 세션.

세션 객체는 Key에 해당하는 SESSION ID와 이에 대응하는 Value로 구성되어 있음.
- Value에는 세션 생성 시간, 마지막 접근 시간, User 정보 등이 key:value 형태로 저장되어 있음.
세션(session)이란?
- 웹 애플리케이션에서 클라이언트(사용자)와 서버 간의 상태를 유지하기 위한 방법을 의미.
  - 클라이언트로부터 오는 요청을 하나의 상태로 보고, 그 상태를 유지하는 기술.
- 세션은 서비스가 돌아가는 서버 측에 데이터를 저장하고, 세션의 키값만을 클라이언트 측에 저장.
- 브라우저는 필요할 때마다 이 키값을 이용해서 서버에 저장된 데이터를 요청 및 사용하게 됨.
- 또한 세션은 보안에 취약한 쿠키를 보완해주는 역할도 함.
세션 방식은 서버쪽에서 사용자 정보를 저장하는 방식.
- 서버는 각 클라이언트에 고유한 세션 ID를 할당함.
- 해당 ID를 통해 사용자의 상태를 관리하고, 쿠키보다 상대적으로 보안성이 높음.
  - 세션 정보는 서버에 저장되기 때문에 클라이언트 측에서 직접 접근할 수 없음.
사용자나 다른 제3자에게 노출되어서는 안되는, 서비스 제공자가 직접 관리해야 할 정보들은 세션으로 서버 안에서 다뤄짐.
클라이언트의 요청이 HTTP 무상태성으로 인해 사용자가 로그인을 해서 마이페이지로 이동을 해도 서버는 동일 인물임을 알지 못함.
- 즉, 각 요청이 독립적으로 처리되고 이전 요청과의 연관성이 없음.
- 그래서 서버에 현재 로그인 되어 있는 상태라는 점을 계속 인증해야됨.
- 이때 사용되는 것이 세션.
  - 세션은 이 무상태성을 극복하여 사용자의 상태나 데이터를 유지하기 위해 사용됨.

중요 정보는 서버의 세션 저장소에 key-value로 저장한 뒤 브라우저에 key값만 반환해줌.
- 다음 로그인이나 페이지 요청시 쿠키에 저장하고 있는 sessionId를 통해 서버의 세션저장소에서는 해당sessionId를 key값으로 가지고 있는 value값을 조회해서 로그인 여부와 중요 정보를 확인.
  - 클라이언트와 서버는 쿠키로 연결되어 있지만 쿠키만 사용했을 때와 차이점은 사용자와 관련된 정보를 클라이언트에서는 가지고 있지 않음.
- 세션 아이디만 가지고 쿠키를 통해 주고받기에 상대적으로 보안이 더 높음.
  - 세션아이디가 저장된 쿠키의 만료시간을 짧게 설정한다면, 해커가 해당 키를 도용하더라도 만료되어서 사용하지 못하게 되므로 좀 더 안전함.
서버에서 세션 저장소를 따로 사용해야 돼서 세션이 많아질수록 서버에 부하가 발생함.
세션 특징.
- 상태 유지.
  - 세션은 클라이언트와 서버 간의 상호작용 동안 사용자의 상태나 정보를 지속적으로 유지.
- 세션 생성.
  - 세션 키는 중복이 되어서는 안되며 고유한 세션 ID가 부여됨.
- 세션 키에 매칭될 값(value)가 있어야 됨.
  - 생성된 세션 키를 응답 쿠키에 저장해 클라이언트에 반환함.
- 세션 조회.
  - 클라이언트가 요청한 세션아이디 쿠키 값으로 세션 저장소에 저장된 값을 조회할 수 있어야 함.
- 세션 만료.
  - 브라우저를 닫거나 서버에서 세션을 삭제하면 세션이 삭제됨.
  - 일정 시간이 지나면 만료됨.
- 서버쪽에 저장.
  - 세션 데이터는 보통 서버 측에 저장되며, 클라이언트는 세션 ID만 보유.

2-1. JSESSIONID

JSESSIONID란?
- 톰캣 컨테이너에서 세션을 유지하기 위해 발급하는 키(key).
- HTTP 프로토콜은 stateless(무상태성)이므로 요청할 때마다 새로운 연결이 생성되고 응답 후에 연결은 끊기게 되므로 상태를 유지할 수 없음.
  - 그래서 상태를 저장하기 위해서 톰캣은 JSESSIONID 쿠키를 클라이언트에게 발급해주고 이 값으로 세션을 유지할 수 있도록 해줌.
동작방식.
- 브라우저에 최초 접근시 톰캣은 Response 헤더에 다음과 같이 JSESSIONID값이 발급됨.
- ```
Set-Cookie: JSESSIONID=3CB361E0BE1A9A7DE7DB926DF0772BAE2
```
- 브라우저 재요청시 Response를 통해 받은 JSESSIONID를 Request 헤더의 쿠키에 넣어서 서버에 요청함.
- 쿠키를 통해 JSESSIONID값을 전달받게 되면 서버는 새로운 JSESSIONID 값을 Response 헤더에 발급하지 않음.
- 클라이언트로부터 전달받은 JSESSIONID값을 기준으로 서버에서는 세션 메모리 영역에 상태를 유지할 값들을 저장할 수 있게됨. (HttpSession 등)
유지범위
- 동일한 Full 도메인. (서브도메인이 다를 경우 쿠키가 유지되지 않으므로.)
- 포트번호는 달라도 무관함.
한계
- 톰캣 컨테이너를 2대 이상 사용하게 될 경우 세션을 유지할 수 없음.
- 유지가 되기 위해서는 세션 클러스터링 환경을 구축해야함.

3. 쿠키 vs 세션.

쿠키는 클라이언트 측, 즉 웹 브라우저에 저장.
- 쿠키는 사용자의 브라우저에 저장을해서 요청과 응답시 서버와 데이터를 주고받기 위해 설계.
- 사용자가 직접 삭제하지 않으면 만료기간까지 유지.
세션은 서버 측에 저장.
- 세션은 서버에서 사용자의 상태를 유지하기 위해 사용.
- 로그아웃 or 브라우저 종료 등을 하면 삭제됨.

-	쿠키	세션
저장위치	클라이언트.(브라우저)	서버.
수명	설정 가능(만료 시간까지 유지)	기본적으로 브라우저 종료 시 종료
보안	조작, 탈취 가능성이 있음	상대적으로 안전
데이터 크기	제한 있음(약 4KB)	서버 리소스에 의존
사용 목적	사용자 설정 유지	사용자 인증 및 중요한 정보 관리

쿠키는 클라이언트 측에 저장되기 때문에 보안의 취약점에 노출될 가능성이 있음.
- 이를 방지하기 위한 보안 조치.
  - 암호화.
    - 중요한 정보는 쿠키에 직접 저장하지 않고, 반드시 암호화해서 저장하거나 서버 측에서 관리.
      - 인증 정보 대신 세션 ID를 저장, 서버에서 세션 정보를 관리.
  - HTTPS 사용.
    - HTTPS를 통해 쿠키를 전송하면 데이터가 암호화되므로 네트워크에서 탈취당할 위험을 줄일 수 있음.
    - Secure 속성: 쿠키가 HTTPS 연결에서만 전송되도록 설정.
  - HttpOnly 속성.
    - 자바스크립트를 통해 쿠키에 접근할 수 없으므로 XSS 공격을 방어할 수 있음.
  - SameSite 속성.
    - 쿠키의 범위를 제한해서 same-site(같은 사이트) 요청에 대해서만 쿠키를 사용할 수 있도록 제한해서 CSRF(교차 사이트 요청 위조) 공격을 방지.
세션은 서버에서 관리되므로 쿠키보다 상대적으로 보안성이 높지만, 세션 ID를 탈취당할 경우 사용자의 세션이 도용될 수 있음.
- 보안 조치.
  - 세션 ID의 안전한 전송.
    - 세션 ID도 HTTPS를 통해 전송하여 네트워크에서 탈취를 방지.
    - 세션 ID를 암호화하거나 서명된 형태로 전송.
  - 세션 ID 재생성.
    - 중요하거나 민감한 작업후에는 세션 ID를 새로 생성하여 이전 ID가 탈취되더라도 악용되지 않도록 방지.
  - 세션 만료 시간 설정.
    - 일정 시간 동안 활동이 없으면 세션을 자동으로 만료시켜 세션 하이재킹 위험을 줄임.
    - 세션이 많이 쌓이면 리소스가 부족해질 수 있으므로, 오래된 세션을 정기적으로 삭제하거나 관리.
  - IP 및 사용자의 브라우저 확인.
    - 세션을 특정 IP 주소나 사용자의 브라우저와 연결하여 일치하지 않을 경우 세션을 종료.
  - CSRF 토큰 사용.
    - 세션 기반 애플리케이션에서는 CSRF 방어를 위해 CSRF 토큰을 사용하여 요청의 유효성을 확인.
웹 개발자들은 사이트를 만들 때 이 정보를 쿠키에 저장할 지 세션에 저장할 지 적절한 판단을 내릴 수 있어야 됨. 쿠키로 노출시켜서는 안 될 정보들이 있고, 그렇다고 세션을 남발하면 접속자가 많을 때 서버에 부하가 걸림.

4. 토큰.

세션 방식에도 단점이 존재함.
- 서버가 데이터베이스에 세션 정보를 가지고 있어야 하고 이를 조회하는 과정 또한 필요하기 때문에 동시 접속하는 이용자가 많아질수록 서버에 부하가 걸리고 리소스에 부담이 생김.
위의 대안으로 나온 것이 토큰방식.
- 세션 아이디 대신 토큰을 발급해 주는 것.
  - 세션과는 다르게 서버가 아닌 클라이언트에 저장되기 때문에 메모리나 스토리지 등을 통해 세션을 관리하던 서버의 부담을 줄일 수 있고 토큰 자체에 데이터가 들어있어서 클라이언트에서 받아 위조되었는지 판별만 하면 됨.
- 서버에서만 유효한 토큰을 생성할 수 있음.
토큰을 발급해 간 사용자의 브라우저에 쿠키로 저장해 놓고 클라이언트가 요청을 보낼 때 요청 헤더에 토큰을 담아서 보내주면 서버는 발급된 토큰인지 검증을 거친 뒤 요청을 수락해줌.
- 토큰 방식은 이 서버만이 만들 수 있는 토큰을 발급해서 상태를 저장하지 않고도 사용자의 로그인 여부를 확인할 수 있도록 해줌.

토큰 방식에도 한계점이 있음.
- 여러 기기에서 로그인 하는 것을 제한하기 위해 로그인되어 있는 사용자를 서버가 강제로 로그아웃을 시킬 수 있어야 하는데, 토큰 방식에서는 이게 불가능함.
- 즉 한 번 발행한 토큰은 유효기간이 끝나기 전까지 서버에서 통제할 수 없기 때문에 세션에 비해 토큰 정보를 탈취 당할 가능성이 높음.
- 그러나 토큰은 쿠키처럼 만료 기간을 정할 수 있어서 만료 시간을 짧게 지정해줌으로써 피해를 줄일 수 있음.

-	세션 방식	토큰 방식
장점	- 사용자의 상태를 원하는대로 통제 가능. - 클라이언트로부터 요청을 받으면 클라이언트의 상태를 계속 유지해놓고 사용. (Stateful)	- 상태를 따로 기억해 둘 필요가 없음.(Stateless)
단점	- 메모리에 로그인되어 있는 사용자의 상태를 보관해야 함. - 사용자가 증가함에 따라 성능 문제를 일으킬 수 있고 서버를 확장하기 어려움.	- Payload는 암호화되지 않기 때문에 유저의 민감한 정보는 담을 수 없음. - 토큰 탈취 시 대처하기 어려움.

5. 캐시.

캐시란 개념은 웹 뿐만 아니라 컴퓨터의 메모리나 안드로이드 등 다양한 곳에서 쓰이는데 거의 공통적인 의미로 가져오는 데 비용이 드는 데이터를 한 번 가져온 뒤에는 임시로 저장해두는 것.
웹 캐시는 이미지 등의 정보를 불러올 때 데이터 사용량도 발생하고 시간도 들기 때문에 사용자가 여러 번 방문할 법한 사이트에서는 한번 받아온 데이터를 사용자의 컴퓨터 또는 중간 역할을 하는 서버에 저장해두는 것.

6. 참고

하쮸

Every cloud has a silver lining.

다음 포스트

쿠키, 세션, 토큰, 캐시.

쿠키, 세션, 토큰

1. 쿠키.

1-1. 쿠키 + 세션.

2. 세션.

2-1. JSESSIONID

3. 쿠키 vs 세션.

4. 토큰.

5. 캐시.

6. 참고

JWT(JSON Web Token)

0개의 댓글

쿠키, 세션, 토큰, 캐시.

쿠키, 세션, 토큰

1. 쿠키.

1-1. 쿠키 + 세션.

1-2. Session Cookie & Persistent Cookie

2. 세션.

2-1. JSESSIONID

3. 쿠키 vs 세션.

4. 토큰.

5. 캐시.

6. 참고

JWT(JSON Web Token)

0개의 댓글