웹 개발을 하다 보면 세션과 쿠키 및 토큰 에 대해서 많이 듣고, 사용하게 된다.
어렴풋이는 알고 있지만 누가 물어봤을 때 확실히 대답하기가 어려워서 세션과 쿠키 및 토큰에 대해서 정리해 보기로 했다.
냠냠
클라이언트 에 저장되는 'key-value'쌍의 데이터 파일
HTTP 쿠키, 웹 쿠키, 브라우저 쿠키 모두 같은 말이다.
① 한 개에 4KB까지 저장할 수 있다.
② 최대 300개 / 하나의 도메인당 20개 까지 / 하나의 쿠키는 4KB까지 가능
③ 클라이언트에 저장하고 참조
④ 이름, 값, 만료 날짜, 경로 정보를 포함한다.
⑤ 웹 브라우저가 종료되면 삭제되지만, 만료 날짜를 정해 두면 만료일에 삭제된다.
⑥ 브라우저에 해당 서버의 쿠키 정보가 있으면 HTTP 요청에 쿠키를 무조건 실어 보낸다.
개발자 모드에 들어가면 Application > Storage > Cookies 에서 현재 Cookies 에 저장된 값을 볼 수 있다.
쿠키를 매개로 사용하지만, 세션 ID 를 서버에서 관리하는 방식
세션은 클라이언트를 식별하기 위해 세션 ID(인증된 클라이언트에게만 발급되는 열쇠)라는 것을 사용한다.
① 따로 용량의 제한이 없다. (서버의 능력에 따라 달라진다.)
② 서버에 세션 객체를 생성하고 클라이언트마다 고유한 세션 ID를 부여한다.
③ 쿠키를 사용하여 세션 ID 값을 클라이언트에 전송한다.
④ 웹 브라우저가 종료되면 세션 쿠키를 삭제한다.
브라우저가 세션 ID를 가지고 있지 않은 상태에서 서버에 HTTP 요청을 보내면, 서버는 세션 ID를 새로 생성하고, 이 세션 ID를 쿠키에 담아 응답한다.
그렇다면 굳이 쿠키와 세션을 사용하는 이유는 뭘까 ?
우리는 웹을 사용할 때 HTTP 프로토콜을 통해서 통신하는데
HTTP 의 특성 중 한가지가 무상태성(stateless) 이다.
상태가 없기 때문에 클라이언트의 정보를 기억하고 있을 수 없다.
그렇기 때문에 클라이언트 정보를 기억하고 있는 수단이 있어야 하는데 그게 바로 쿠키와 세션이다
쿠키와 세션을 많이 비교하는데, 쿠키와 세션은 클라이언트를 기억하기 위한 방법일 뿐, 차이는 있긴 하지만 아예 반대 개념이라고 할 수는 없습니다.
- | 쿠키 | 세션 |
---|---|---|
저장 위치 | 클라이언트 | 서버 |
보안 | 보안 취약 | 쿠키 취약점 보안 |
사용 사례 | 장바구니 | 아이디, 비밀번호 |
서버 확장 시 세션 정보의 동기화 문제
: 서버가 여러 개일 때 각 서버마다 세션 정보가 저장됨
서버 / 세션 저장소의 부하
: 세션을 DB 에 저장하는 경우 모든 요청에 대해서 DB 조회를 해야하기 때문에 부하가 발생
웹 / 앱 간 상이한 쿠키-세션 처리 로직
: 웹 / 앱의 쿠키 처리 방법이 달라서 따로 처리해야함
이러한 문제점을 해결하기 위해 나온게 토큰
인증에 필요한 정보들을 암호화시킨 토큰
쿠키에 담아서 요청을 보낼 수도 있고, HTTP 헤더에 담아서 요청을 보낼 수도 있다.
① 세션처럼 별도의 저장소 관리가 필요하지 않고 토큰을 발급 후 클라이언트에게 전송 후 검증하는 과정만 있으면 된다.
② 발급된 토큰은 삭제가 불가능하다.
③ 토큰 자체로 정보를 가지고 있어 별도의 인증 서버 필요
④ 보통 JWT 를 많이 사용