[CS - 네트워크] 쿠키와 세션 (Cookie, Session)

쿠키와 세션

쿠키와 세션이 무엇일까? 개념과 함께 쿠키와 세션이 나오게 된 배경부터 알아보자.

 

배경

HTTP에서는 클라이언트가 서버에 Request를 보낼 때마다 정보를 요청해야 한다. 왜냐하면 HTTP의 특징인 비연속성(connectionless), 비상태성(stateless) 때문에 정보가 저장되지 않기 때문이다.

 

이 방식은 너무 비효율적이기 때문에, 정보를 저장할 수 있는 방식을 고안했고, 이게 바로 쿠키와 세션이다.

즉, 쿠키와 세션은 HTTP의 비연속성, 비상태성 특성을 보완하면서 상태를 저장하기 위한 것이다.

 

 

이것이 쿠키와 세션의 대략적인 개념와 필요한 이유다. 그렇담 각각 어떤 것을 의미하며, 구현과 원리가 어떻게 될까?

 

쿠키, Cookie

쿠키는 클라이언트(브라우저)에 있는 로컬 쿠키 저장소(Cookie Storage)에 key-value 쌍으로 저장되는 데이터 파일이다. 유효시간 내에서는 브라우저를 닫아도 데이터가 계속 유지된다.

쿠키의 예시로 로그인 정보 저장, 자동 로그인, 팝업 창 하루 동안 보지 않음 등이 있다.

 

 

절차

출처 : 개발남노씨

• 클라이언트가 서버에 정보를 요청하기 위해 Request를 보낸다.
• 서버는 클라이언트의 요청에 응답한 정보를 Response의 header에 set-cookie 형태로 담아서 보낸다.
• 클라이언트는 이 정보를 쿠키 저장소에 저장한다.
• 클라이언트가 다시 정보를 요청할 때 Request에 쿠키를 같이 보낸다.
• 서버는 쿠키를 보고 그에 맞게 응답한다. (팝업창 다시 보지 않는다는 정보의 쿠키를 보고, 팝업창을 띄우지 않는다)

 

세션, Session

세션은 기본적으로 쿠키를 이용하여 구현된다.

또한, 세션에는 각 클라이언트를 구분하기 위한 세션 ID(session ID)가 발급되는데, 클라이언트는 쿠키에 이 세션 ID를 저장한다.

사용자 정보를 클라이언트의 브라우저에 저장하는 쿠키와 달리, 세션은 서버의 저장소에 저장된다. 서버에 저장되기 때문에 서버의 성능에 부하를 일으킬 수 있다.

세션은 응답 시간을 두어, 시간이 만료되면 세션을 끊을 수 있고, 브라우저가 종료될 때까지 인증 상태를 유지할 수 있다.

 

 

절차

출처 : 개발남노씨

• 클라이언트는 서버에 정보를 요청하기 위해 Request를 보낸다.
• 서버는 클라이언트 정보를 DB 또는 메모리에 저장하고, 클라이언트의 session ID를 발급한다.
• 서버는 Response에 set cookie 형태로 session ID를 같이 보낸다.
• 클라이언트는 session ID를 쿠키에 저장한다.
• 클라이언트는 다음에 정보를 요청할 때 Request의 header에 session ID를 같이 보낸다.
• 서버는 session ID에 맞는 정보를 담아서 보낸다.

→ session ID만 왔다 갔다 하기 때문에 보안에 용이하나, 서버 측에 정보를 저장하기 때문에 성능에 부하를 일으킬 수도 있다.

 

쿠키와 세션의 로그인 방식 및 절차

쿠키와 세션을 활용한 로그인 절차는 어떻게 될까? 이를 그림을 그려가며 설명할 수 있어야 쿠키와 세션을 제대로 이해했다고 말할 수 있겠다.

이를 설명하는 키워드로 인증(Authentication)과 인가(Authorization)가 있다.

 

인증(Authentication)과 인가(Authorization)

인증이란, 유저의 정보가 맞는지 확인하는 것이다. (초소 경계 근무를 할 때 피아식별을 하는 것과 비슷하다고 보며 된다. 누구인지 보는 것)

인가란, 유저에게 권한이 있는지 확인하는 것이다. (피아식별이 된 후 진입할 수 있는 권한이 있는지 확인하는 것이다. 소대장이 진짜 여기 진입할 수 있는지 확인)

로그인 절차를 설명할 때 인증과 인가를 기점으로 설명하면 된다. 그림과 함께 살펴보자.

 

절차

출처 : 개발남노씨

• 클라이언트가 서버에 로그인 정보 인증 요청을 한다. (서버 양반, 로그인 정보 확인해주이소)
• 서버는 회원 DB를 통해 클라이언트가 보낸 정보가 회원이 맞는지 확인한다. (인증, Authentication)
• (회원이 맞으면) 서버는 세션에 회원 정보를 생성 및 저장하고, session ID를 발급한다.
• 서버는 Response의 header에 session ID를 담아서 클라이언트에 보낸다.
• 클라이언트는 쿠키에 session ID를 저장한다.
• 클라이언트는 다음부터 Request에 sessioin ID를 쿠키에 담아서 보낸다.
• 서버는 클라이언트가 보낸 session ID를 세션 저장소에서 확인한다.
• session ID에 맞는 정보가 있으면, 그에 맞는 정보를 보낸다. (인가, Authorization)

 

장단점

쿠키와 세션을 이용하면, 보안에 좋다는 장점이 있다. (만약, 쿠키와 세션을 사용하지 않는다면, 매번 중요한 회원 정보를 담아서 통신해야 하기 때문에 보안 상 위험하다, 하지만, 쿠키와 세션을 사용한다면 session ID만으로 통신하기 때문에 보안상 이점이 있다.)

그러나 session ID도 마냥 안전한 것만은 아니다. 서버 입장에서는 session ID만 보기 때문에, 이게 착한 애가 보낸 건지 나쁜 애가 보낸 건지 확인할 겨를이 없기 때문이다.

그래서, 이를 보완하기 위한 방법으로 HTTPS를 사용하거나, 중간에 session ID가 탈취될 수 있는 session hijacking을 막기 위해 세션 만료 시간을 짧게 하는 방법 등이 있다.