HTTP 프로토콜의 특성이자 약점을 보완하기 위해서 쿠키 또는 세션을 사용합니다.
HTTP 환경은 "connectionless, stateless"한 특성을 가진다고 지난 포스팅에서 배웠습니다. 이처럼 비연결성, 무상태성을 유지하면 장점도 있지만 단점도 있습니다.
예를 들어 우리가 흔히 아는 '로그인'기능 처럼 서버의 인증 절차를 통해 특정 데이터를 계속해서 받아야하는 기능이 있습니다. 로그인을 하면 일반 화면과는 다른 화면(저장한 장바구니, 즐겨찾기등)을 볼 수 있습니다. 하지만 무상태를 유지하면 화면을 리렌더링 할 때마다 상태가 초기화가 되어 다시 로그인을 해야하는 번거로움이 있습니다. 이러한 문제점을 해결하기 위해 다양한 방법들이 만들어졌습니다.
쿠키
인터넷 사용자가 어떠한 웹사이트를 방문할 경우 그 사이트가 사용하고 있는 서버를 통해 인터넷 사용자의 컴퓨터에 설치되는 작은 기록 정보 파일을 일컫는다. HTTP 쿠키, 웹 쿠키, 브라우저 쿠키라고도 한다. HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.
쿠키의 대표적인 기능으로는 팝업이 있다. 방문자가 홈페이지에 첫 방문할 시 '하루동안 보이지 않음'이라는 선택창을 포함한 팝업을 종종 볼 수 있다. 이때 보이지않음 버튼을 클릭후 서버로 전송하면 서버는 버튼 클릭을 확인한 후 "하루동안 팝업을 열지않음"이라는 데이터를 담은 쿠키를 클라이언트에 전송해 클라이언트에 저장한다.
이후 사용자가 사이트에 재방문하면 브라우저는 쿠키에 적힌 도메인을 확인, 방문하는 사이트와 도메인이 일치한다면 일치하는 쿠키를 찾아 서버로 전송한다.(다시 돌아옴) 이후 홈페이지의 자바스크립트는 쿠키를 찾으며 "하루동안 팝업을 열지않음"이라는 쿠키를 발견하면 팝업을 열지 않는다.
쿠키의 특징은 다음과 같다.
- 쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일입니다.
- 사용자 인증이 유효한 시간을 명시할 수 있으며, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지된다는 특징이 있습니다.
- 쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다.
- 클라이언트에 300개까지 쿠키저장 가능, 하나의 도메인당 20개의 값만 가질 수 있음, 하나의 쿠키값은 4KB까지 저장합니다.
- Response Header에 Set-Cookie 속성을 사용하면 클라이언트에 쿠키를 만들 수 있습니다.
- 쿠키는 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Header를 넣어서 자동으로 서버에 전송합니다.
- 로컬에 저장된 쿠키들
구글 개발자도구 Application탭에서 브라우저에 저장된 현재 호스트의 쿠키들을 볼 수 있습니다.
쿠키의 속성들은 다음과 같습니다.
- Name: 쿠키의 이름입니다
- Value: 쿠키의 값입니다.
- Domain: 이 쿠키가 어느 도메인일때 사용 되어지는지 나타내는 칸입니다.
- Path: 현 도메인의 어떤 path일때 사용되는지 나타내는 칸입니다.
- Size: 말 그대로 사이즈입니다(byte)
...
등등 다양한 옵션들이 있습니다.
- 서버에서 보내져온 쿠키
구글 개발자 도구 Network탭에서 응답 받은 데이터중 하나를 클릭 set-cookie라는 메세지가 온것을 볼 수 있다. 이것은 서버에서 쿠키를 만들어 클라이언트에게 보낸 쿠키이다.
이처럼 쿠키는 서버와 클라이언트간의 무상태성의 약점을 보완할 수 있는 기능을 가지고 있다.
세션
일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다. 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다.
세션의 대표적인 기능으로는 로그인 구현이 있다. 홈페이지의 사용자가 로그인 정보를 서버로 보내면 서버는 db에서 정보를 식별, 일치하면 요청이온 클라이언트의 고유id를 만들어 서버에 '세션id'라는 것을 만들어 서버에 저장, 그후 쿠키에 세션 데이터를 작성하여 클라이언트에게 전송하며 클라이언트에 저장하고 로그인이 성공이였음을 알린다.(쿠키를 확인하면 expire칸에 session이라고 적힌게 있음 그게 세션 쿠키임) 그리고 사용자가 사이트를 재방문하면 쿠키는 알맞은 도메인을 확인하고 서버로 전송, 전송된 쿠키중 세션쿠키와 서버의 세션id의 데이터가 일치하면 세션을 유지, 즉 로그인을 유지시킨다.
세션의 기능은 다음과 같다.
- 웹 서버에 클라이언트의 상태를 유지하기 위한 정보를 저장한다.
- 웹 서버의 저장되는 쿠키(=세션 쿠키)
- 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
- 저장 데이터에 제한이 없다. (서버 용량이 허용하는 한에서)
- 각 클라이언트에 고유 Session ID를 부여한다. Session ID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공
이렇게 보면 세션과 쿠키를 햇갈려 하는 사람이 많지만 세션도 쿠키를 기반으로 작동을 하는 것을 볼 수 있다. 하지만 둘은 많은 차이점이 존재한다
세션과 쿠키의 차이점
- 쿠키보다는 세션이 보안면에서 우수
- 쿠키와 세션 둘다 만료기간을 정할 수 있지만 쿠키는 영원히 저장할 수 있고 세션은 브라우저가 종료되면 자동으로 삭제된다.
- 쿠키는 용량의 한계가 있지만 세션은 없다.
토큰
위에서 클라이언트가 서버에 로그인 요청을 하면 서버는 세션id를 생성하여 세션db에 세션id를 저장후 그 클라이언트의 요청이 올 때 마다 세션db에서 요청온 세션쿠키를 확인해 둘이 일치하면 알맞은 정보를 응답해주는 프로세스를 배웠습니다.
하지만 요청이 갑자기 늘어나면 세션db의 부하는 엄청 커질것입니다. 이때 서버측에선 무상태를 유지하며 클라이언트에선 상태를 유지하는 방법을 개발자들은 고안했습니다. 바로 토큰을 통한 인증방식입니다.
위의 세션 프로세스 그림과 다르게 토큰 프로세스는 서버에서 데이터를 저장하지 않고 토큰을 검증만 하고 클라이언트에 보내는 방법을 사용하고 있습니다.
토큰 기반 인증 방법의 진행 순서는 다음과 같습니다.
- 유저가 아이디와 비밀번호로 로그인을 합니다
- 서버측에서 해당 계정정보를 검증합니다.
- 계정정보가 정확하다면, 서버측에서 유저에게 signed 토큰을 발급해줍니다.
- 여기서 signed 의 의미는 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature 를 지니고 있다는 것입니다
- 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때 마다, 해당 토큰을 함께 서버에 전달합니다.
- 서버는 토큰을 검증하고, 요청에 응답합니다.
웹서버에서 토큰을 서버에 전달 할 때에는, HTTP 요청의 헤더에 토큰값을 포함시켜서 전달합니다.
정리
쿠키
쿠키는 서버와 클라이언트를 이동할 수 있는 작은 데이터 파일입니다. 클라이언트에 저장되며 클라이언트와 서버를 이동하며 데이터를 검증 시킬 수 있습니다.
세션
사용자의 인증을 일정 기간동안 유지시키는 서버 기술입니다. 서버에 저장되며 클라이언트의 요청이 올 때마다 쿠키에 담긴 데이터를 검증해 세션을 유지시킵니다.
토큰
토큰이 명사라기 보다는 토큰 기반 인증 시스템이라는 동사에 가깝습니다. 토큰 또한 쿠키에 담긴 데이터이지만 세션처럼 서버에서 상태를 유지하며 클라이언트의 인증을 확인하는 시스템이 아닌 서버는 인증만 하고 클라이언트의 상태를 유지시키는 기술입니다.
