[개념] 세션 / 쿠키 / 토큰의 차이점

'Session(세션)'과 'Cookie(쿠키)'는 왜 등장했을까?

 HTTP 통신은 *Stateless 프로토콜이기 때문에, 요청(Request) -> 응답(Response)이 종료되면  연결을 끊는 처리방식이다. 그러나 실제 User 입장에서는 로그인과 같은 경우, 웹페이지의 변동사항이 생길때마다 연결이 초기화되어 매번 다시 로그인해야 한다고 하면 매우 불편할 것이다.

 이러한 로그인과 같은 어떠한 상태를 유지해야 할 때, 누가 로그인 중인지와 같은 '상태'를 기억하기 위해 쿠키, 세션, 토큰을 사용하게 된다.

 

 

*Stateless(무상태) 프로토콜 : 어떠한 이전 요청(Request)과도 무관한 각각의 요청을 독립적인 트랜잭션으로 취급하는 통신 프로토콜로, 서버가 복수의 요청 시간대에서의 각각의 통신 파트너에 대한 세션 정보나 상태 보관을 요구하지 않는다.

<->

Stateful(상태) 프로토콜 : Stateless 프로토콜과 반대되는 개념으로, 서버의 내부 상태 유지를 요구하는 프로토콜을 말함.

 

---

세션(Session) 이란?

• '일정 시간' 동안 같은 사용자(여기서는 브라우저로 보면 됨)로부터 들어오는 일련의 요청(Request)을 하나의 상태(State)로 보고, 그 상태를 일정하게 유지시키는 기술.
• '일정 시간' 이란, 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점을 말함.
  => 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 이를 세션으로 칭하는 것.
• 사용자별로 식별자인 Session ID가 부여되는데, 이를 서버에서 인증정보로 활용하기 위해 사용자별로 각각 다르게 저장함.
  
  
• 장점)
  - 브라우저를 닫거나, 서버에서 세션을 삭제했을 때에만 삭제되므로, 비교적 보안이 좋음.
  - 각 유저별로 고유 Session ID를 부여하므로, 유저를 구분하여 각 유저 요구에 맞는 서비스 제공이 가능.
  - 클라이언트의 웹 브라우저에 의존하지 않음.
  - Session ID만 전송하기 때문에, 세션의 크기가 커도 네트워크 부하가 거의 없음.
• 단점)
  - 세션 하이재킹 공격에 대한 대비가 필요.
  - 서버에 세션에 대한 별도의 추가 공간이 필요하며, Multi Server 환경에서는 정합성 이슈가 발생될 수 있어 세션 클러스터링 도입이 필요함.
  
  

---

쿠키(Cookie) 란?

• 서버는 클라이언트(여기서 클라이언트는 웹 브라우저가 됨)의 요청에 대한 응답을 작성할때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 'set-cookie'에 담게 되는데, 이때 담기는 정보를 말함.
• 서버가 아닌 클라이언트(사용자의 웹 브라우저)에 저장하는 방식이며, 데이터 형태는 Key-Value 형태로 String 문을 사용하고, 4 KB 이상 저장이 불가함. 또한 브라우저마다 저장되는 쿠키가 다름.
• 서버는 쿠키에 담긴 Session ID와 같은 인증정보를 통해 클라이언트를 식별할 수 있음.
  
  
• 장점) 
  - 쿠키가 담긴 HTTP 요청(Request)가 통신 도중 제 3자에게 노출되더라도, 쿠키에 담긴 Session ID와 같은 정보는 자체로 유의미한 값을 갖고 있지 않음.
  - 서버의 저장공간을 절약할 수 있음.
• 단점)
  - 제한된 저장공간 및 사이트별로 20개, 총 300개의 쿠키 개수를 가질 수 있음.
  - 웹 브라우저마다 지원 형태가 다르므로, 웹 브라우저를 변경할 경우 다른 웹 브라우저에서 저장한 쿠키 사용 불가.
  - 사용자가 보안상 문제로 쿠키 사용을 거부할 경우, 사용이 불가함.
  - 쿠키 사이즈가 클 경우, 네트워크에 부하가 걸릴 수 있음.
  
  

---

토큰(Token) 이란?

• 서버는 인증받은 사용자들에게 '토큰'을 발급하고, 클라이언트가 서버에 요청을 할 때 Header에 토큰을 함께 보내도록 하여 유효성 검사를 하게 됨. 
  => 더이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고, 클라이언트 측에서 들어오는 요청만으로도 작업 처리가 가능함. 즉, 서버 기반의 인증 시스템과 달리 상태를 유지하지 않으므로 Stateless한 구조를 가짐.
• 제한된 수명이 있으며, 한번 만료되면 새롭게 생성되어야 하는 특징이 있음.
• 대표적으로 JWT(JSON Web Token) 방식이 있음.
  
  
• 장점)
  - JWT는 발급한 후 검증만 하기 때문에, 추가 저장소를 필요로 하지 않으며, 이는 서버를 확장하거나 유지,보수 하는데에 유리함.
  - Google, Microsoft, Facebook 등과 같은 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하여 확장성이 용이.
• 단점)
  - 이미 발급된 JWT에 대해서는 유효기간이 만료될 때까지 계속 사용이 가능하여, 악용될 경우 보안 취약점으로 작용할 수 있어 대비가 필요함.
  - 쿠키나 세션과 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아질수록 네트워크 부하가 심해질 수 있음.
  - payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보를 담으면 안됨.
  - 토큰을 탈취 당하면 토큰의 유효기간이 만료되기 전까지는 강제로 만료시키기가 어렵기 때문에, 대처가 어려움.

 

참고

https://velog.io/@cjung5318/%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98-%ED%86%A0%ED%81%B0%EC%9D%98-%EC%B0%A8%EC%9D%B4%EC%A0%90

쿠키, 세션, 토큰의 차이점

https://tofusand-dev.tistory.com/89

Cookie, Session, Token 의 차이점