웹이 발전하면서 요청과 요청간의 상태가 유지되어야 할 필요가 있어졌다. 상태가 유지가 되지 않으면, 사용자는 페이지를 이동할 때 마다 새롭게 로그인을 해줘야할 것 이다. 그런데 이상하다. 우리는 그런 경험을 해본적이 없다. 어떻게 상태가 유지되는 것 일까?
쿠키 (Cookie)
HTTP 의 비상태성을 보완하기 위해 등장한 것이 쿠키이다. 쿠키는 HTTP 요청과 응답에 함꼐 실려 전송된다.
쿠키는 클라이언트 즉, 브라우저에 저장된다. 웹 서버가 클라이언트로 보내는 응답의 헤더 중
Set-cookie 라는 헤더에 키와 값을 함께 실어 보내면 그 응답을 받은 브라우저는 해당 쿠키를 저장하고,
그 다음 요청부터 자동으로 쿠키를 헤더에 넣어 송신한다.
쉽게말해, 쿠키는 회원정보(아이디, 비밀번호) 등을 HTTP 통신이 일어날때 마다 보내주는 정보로써, 쿠키 정보는 여러 브라우저(클라이언트)에 계속 와리가지 치면서 송.수신 엄청 하는듯?
세션
세션은 쿠키와 다르게 정보를 서버측에 저장하는 방식이다.
세션이란 브라우저로 웹서버에 접속한 시점부터 브라우저를 종료하여 연결을 끝내는 시점까지의 일련의 요청을 하나의 상태로 간주하고, 그 상태를 일정하기 유지하는 기술이다.
그렇다면 이 세션을 어떻게 비상태성을 갖는 HTTP 에서 어떻게 상태를 일정하게 유지할까?
세션 생성과정
맨 처음, 사용자가 HTTP 요청의 Body 에 인증정보 (유저이름이나 패스워드 같은 것들) 을 실어 서버로 보낸다. 서버에서는 해당 인증정보가 유효하면 사용자와 데이터를 식별하는 Session ID 를 생성한다.
Session ID 는 응답의 Set-cookie 헤더에 생성된 세션 아이디를 실어 보내진다.
클라이언트는 해당 세션 아이디를 쿠키에 저장하고, 매 요청메다 세션 아디이를 Cookie 헤더에 실어 전송한다. 서버는 전달받은 세션 아이디를 통해 해당 요청의 송신자가 누구인지 식별할 수 있다.
( 세션 아이디에 대한 쿠키의 Key는 세션을 관리하는 주체에 따라 다르다. 즉, 무조건 쿠키에 SESSIONID 라는 이름으로 저장되는 것은 아니다. 예를들어 톰캣은 JSESSIONID 라는 이름으로 세션 아이디를 저장하고, node.js 는 connect.sid 라는 이름으로 저장한다고 한다. )
세션은 어디에 저장될까?
일반적으로 생성된 세션 데이터는 서버의 메모리에 저장된다. 하지만 로드 밸런싱등의 이유로 서버를 수평 확장(Scale Out) 하는 경우가 많을 것이다. 이런 경우 최초 세션이 생성된 서버와 그 이후의 요청을 받은 서버가 다른 경우 세션이 불일치하는 문제가 발생할 것 이다.
이런 문제를 해결하기 위해 유저의 요청이 무조건 세션을 생성한 서버로 향하도록 하는 Sticky Session, 여러 웹서버가 모두 동일한 세션 정보를 가지고 있는 Session Clustering 방식이 있지만, 세션 정보를 관리하는 서버를 아예 별개로 두는 Session Storage 방식이 가장 많이 쓰인다고 한다.
이를 위해 MySQL 같은 일반적인 RDBMS를 사용할수도 있겠지만, Key-Value로 저장되는 세션 특성상 Redis나 memcached 와 같은 Key-Value 쌍으로 저장되는 인메모리 스토어를 사용하는 것이 일반적이다.
세션기반 인증
세션기반 인가는 사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식이다.
사용자가 로그인을 하면, 해당 인증 정보를 서버의 세션 저장소에 저장하고,
사용자에게는 저장된 세션 정보의 식별자인 Session ID 를 발급한다.
발급된 Session ID 는 브라우저에 쿠키 형태로 저장되지만, 실제 인증 정보는 서버에 저장되어 있다.
브라우저는 인증 절차를 마친 이후의 요청마다 HTTP Cookie 헤더에 Session ID 를 함께 서버로 전송한다. 서버는 요청을 전달받고, Session ID 에 해당하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자를 인증된 사용자로 판단한다.
토큰기반 인증
(이 글에서 토큰기반 인증은 현재 가장 널리 상용되는 JWT(Json Web Token) 을 기준으로 설명한다.)
세션 기반 인증이 인증 정보를 서버에 저장하는 방식이라면,
토큰 기반 인증은 인증 정보를 클라이언트가 직접 들고 있는 방식이다.
이때 인증 정보가 토큰의 형태로 브라우저의 로컬 스토리지(혹은 크기)에 저장된다.
토큰의 종류에 따라 다르겠지만, 대표적인 토큰인 JWT의 경우 디지털 서명이 존재해 토큰의 내용이 위변조 되었는지 서버측에서 확인할 수 있다.
토큰 기반 인증에서는 사용자가 가지고 있는 토큰을 HTTP 의 Authorization 헤더에 실어 보낸다.
이 헤더를 수시한 서버는 토큰이 위변조 되었거나, 만료 시각이 지나지 않은지 확인한 이후 담겨있는 사용자 인증 정보를 확인해 사용자를 인가한다.
출처
