Cookie_and_session

layout: post title: cookie 와 session categories: [server] —

유저가 서버에 요청을 할 때 내려받는 정보, 예를 들면 로그인 정보와 같은 데이터들은 여러 방식으로 저장될 수 있다.

각 페이지는 개별적이기 때문에 한 페이지에서 다른 페이지로 이동하면 각 페이지는 유저에 대한 정보를 다시 인지해야한다.

그러나 유저는 한번 로그인을 하면 다른 페이지로 이동하거나, 다른 url을 다녀와도 이미 로그인한 정보로 권한이 필요한 요청들을 처리할 수 있다.

어디선가 나(유저)에 대한 정보를 가지고 있기 때문이다.

유저에 대한 정보를 보관해두면 유저의 요청에 따라 다른 페이지로 넘어가더라도 이미 저장된 authentication으로 권한이 필요한 작업들을 처리할 수 있다.

로그인을 예로 들었지만 장바구니 기능 혹은 아이디만 저장하는 등 유저의 정보를 들고 있는 경우도 저장소를 필요로 한다.

이런 저장소의 역할을 하는 것으로 쿠키, 세션이 있다.

쿠키는 클라이언트의 저장소에서 들고 있는 메모리공간으로, 유저의 로컬 저장소에 보관된다.

클라이언트에서 노출되는 데이터들로, 클라이언트 측에서 노출된다는 것은 해킹의 위험이 있고 보완이 낮다.

따라서 장바구니 혹은 로그인 시 아이디를 저장하는 등 노출되더라도 비교적 위험도가 낮은 정보들을 저장해둔다.

쿠키에 장바구니 목록을 저장해두기도 하는데, 비즈니스 영역과 환경에 따라서 이를 선택한다.

(비즈니스상 장바구니 목록을 db에 담아두거나 서버에서 메모리공간을 할당해주는 게 비효율적이라면 쿠키에 담아둘 수 있다.

혹은 장바구니에 저장공간을 할당해줄 수 없는 서버 환경이라면 쿠키에 담아두게 될 수 있다.

세션은 서버가 들고 있는 저장공간인데, 클라이언트의 session id를 가지고 유저가 브라우저에 머무는 동안 인증해준다.

여기서 말하는 클라이언트란 크롬, IE, 사파리 등의 브라우저를 말한다.

각 브라우저를 하나씩 클라이언트 1개라고 볼 수 있어서 앞서 3개의 브라우저는 3개의 클라이언트가 된다.

세션은 클라이언트가 활성화되는 동안 서버가 들고 있는 메모리라서 브라우저를 열었다가 닫으면 세션은 만료가 된다.

클라인트가 처음 요청을 하는 경우 서버는 세션 id를 만들어서 클라이언트의 header에 넣어준다.

세션을 이룰 수 있는 방법은 여러 가지가 있을 수 있지만 그 중 하나가 access token을 발급하는 것이다.

Access token을 클라인트에게 보내면서 어디에 저장할 것인지 여러 장소가 있겠지만, 그 중 하나가 쿠키에 넣는 것이다.

웹에서는 쿠키로 저장을 하고 앱에서는 쿠키가 아닌 다른 곳에서 저장을 할 것이다.

세션만을 이용해 클라이언트를 인증한다면 서버의 부담이 커지고 비효율적일 수 있다.

세션은 서버가 부담해야하는 메모리이느므로 많은 유저들이 서비스를 동시에 이용한다면 서버는 많은 메모리를 세션을 위해 할애해야한다.

또한 여러 대의 서버가 존재했을 때, 그중 어느 서버에서 줄지, 어느 서버에서 세션을 주었는지 확인을 하는 과정은 탐색을 거치는 등 비효율적일 수 있다.

따라서 서버는 세션을 주지않고 토큰이라는 인증서를 발행해준다.

토큰은 클라이언트가 서버에서 인증을 거치고 나면 서버에서 내려주는 인증서다.

서버는 서버에서 인증된 클라이언트에게 세션을 주면서 자신에게 부담이 오는 것을 encript된 토큰을 발급해주면서 부담을 덜 수 있다.

토큰은 보통 서버에서 암호화시킨 정보를 담아서 쿠키에 담는다. 토큰에 담긴 데이터를 통해 서버는 유저가 누군지 인지하게 된다.

Estrella'sdevelopment blog