웹 서비스는 기본적으로 상태가 유지되지 않는(stateless)하기 때문에, 상태가 유지되어야 할 정보를 저장하기 위한 방법들을 여러 가지 제공하고 있다. 그 중에서 가장 기본적인 것이 쿠키(cookie)와 세션(session)인데, 쿠키가 클라이언트 쪽에 저장되는 정보라면, 세션은 서버 쪽에 저장되는 정보라고 할 수 있다. 그러나 "로그인 세션"처럼 추상적인 개념으로 사용하는 경우에는 그걸 구현하기 위한 수단으로 서버 세션 정보와 쿠키가 모두 사용된다고 할 수 있다. 요즘에는 클라이언트 쪽에서는 쿠키보다는 로컬저장소(localStorage)와 세션저장소(sessionStorage)를 용도에 맞게 나눠서 사용하는 경향이 있다.
¶ 쿠키
서버가 응답 헤더에 쿠키를 저장하라는 지시(Set-Cookie)를 클라이언트로 내리고, 클라이언트(주로 웹브라우저)는 쿠키를 파일로 관리하고 있다가 서버에 다시 요청을 보낼 때 요청 헤더에 쿠키 내용을 적어서(Cookie) 서버로 보낸다.
쿠키는 크기 제한(4KB)이 있어서, 모든 정보를 다 담을 수는 없으니 상태가 유지되어야 하는 정보를 최소로만 저장해야 한다. 부동산 서비스를 예로 들면, 사용자가 조회했던 부동산 매물 정보를 쿠키로 구워둘 수 있지만 바람직한 방법은 아니다. 서버와 주고받을만한 정보도 아니다. 이런 경우에는 로컬저장소에 저장해두고 클라이언트쪽에서 렌더링할 때 참고하는 게 좋다. 요즘은 로그인 세션을 위한 세션 ID 정도만 쿠키를 활용하는 게 바람직하다.
¶ 세션
세션은 상태가 유지되는 일정 기간을 의미하기도 하고 그 기간동안에 서버 쪽에 저장되는 임시 정보를 뜻하기도 한다. 가장 일반적인 세션 정보가 "로그인 세션"이다보니 "로그인 세션"이라고 부르기도 하는데, 이런 경우에는 로그인된 시간만큼을 세션으로 보는 것이다. 세션의 길이는 임의로 정할 수 있으며 일반적으로는 일정 시간 동안 쿠키를 갱신하지 않으면 다음 쿠키 조회 시에 삭제처리하는 게 필요하다.
개념이 모호하다보니 구현 방법이나 담고 있는 정보의 구성은 구현하기 나름이다. 사용자 ID, 생성 시각, 업데이트 시각 등등. 모든 정보를 다 합쳐서 해싱하거나 암호화해서 통째로 쿠키로 내려보내기도 하고(바람직하지 않음), DB 필드로 세분화해서 저장하고 primary key인 session ID를 쿠키로 내려보내기도 한다.
¶ 쿠키와 세션의 협업
쿠키는 서버와 클라이언트가 상태를 유지하기 위해 주고받을 필요가 있는 최소한의 정보를 클라이언트에 저장할 때 사용하는 것이며, 서버 쪽에는 마찬가지로 정보가 저장되어야 하기 때문에 세션 형태가 되고, 결국은 DB와 같은 저장소에 저장되게 된다.
예를 들면, 사용자가 로그인을 했을 때 일정 시간 동안 로그인된 상태로 서비스를 이용할 수 있는데, 매번 ID/패스워드를 입력해서 인증을 거치지 않고 최초의 인증 이후에는 특정 사용자라는 걸 서버 쪽에서 식별하는 게 필요하다. 최초의 인증 성공 시에 로그인 세션 정보를 만들어서 서버(DB)에 저장해두고 쿠키를 만들라고 클라이언트로 내려보낸다. 그러면 세션의 유효기간 동안에는 클라이언트가 쿠키를 이용해서 로그인되었음을 알리고 서버는 쿠키에서 읽어낸 세션 ID를 가지고 DB를 조회하여 세션 정보를 취득하고 로그인 여부를 판정할 수 있다.
기밀정보가 쿠키에 드러나지 않도록 사용하는 것에 주의해야 하며, 기밀정보가 꼭 쿠키로 저장되어야 한다면 암호화를 해야 한다. 암호화를 하기 전에 서버 쪽에만 기밀정보를 저장해두고 쿠키에는 기밀정보에 대한 레퍼런스(or ID)만을 저장하는 게 더 바람직하다. 쿠키에 사용자 ID나 패스워드를 저장한다고 가정해보자. 클라이언트 OS 환경에서 쿠키 파일이 공격자에 의해 탈취된다면?