쿠키와 세션의 등장
키워드
http, connectionless, stateless**
일반적인 웹 개발 안에서 서버와 클라이언트는 요청-응답 순간을 제외하면, 서로가 어떤 상황인지 인지할 수 없다. 그렇기 때문에 서비스를 만들어도 누가 방문했는지 누가 게시물을 보았는지를 알 수가 없는 단점이 나타났다. 개발 초창기 게시판을 만들었을 때 클릭할 때마다 조회수가 올라가는 것 처럼 말이다. 이러한 문제를 해결하기 위해 나타난 것이 쿠키, 세션, 토큰이다.
쿠키
서버에서 받은 데이터를 클라어인트 (브라우저)에 저장하는 작은 임시 파일을 말한다. 처음 쿠키가 만들어진 것은 정확한 방문 통계를 내기 위해서 였다고 한다. 방문자가 이전에 방문했던 자 인지 아닌지를 확인하고, 실 방문자 수를 파악하기 위함이었다고 한다. 이름의 유래 역시도 어떤 이벤트 데이터가 아닌 쿠키 부스러기와 같은 작은 파일들이라하여 cookie 라는 이름이 붙었다고 한다.
이렇게 서버에서 매번 가져와야 하는 데이터를 클라이언트 단에 저장해놓음으로써, 기존 보다 더 빠른 이벤트 페이지 렌더링이 가능해졌다. 단, 클라이언트에 존재하는 데이터이다 보니, 데이터의 유출이나 침해에 취약했기 때문에, 현재와 와서는 노출이 되도 괜찮은 정보, 변질되도 문제가 없는 정보들을 저장하는데 사용되곤 한다. 예를 들자면, 장바구니에 물건을 담아두거나, 하루동안 광고글을 숨기는 등이 있다.
세션
보안성이 약한 쿠키를 사용할 때 대표적으로 문제가 되었던 것이, 로그인 일 것이다. 쿠키를 통해 로그인을 하는 경우, 인증을 지속할 수 있다는 장점은 있지만 클라이언트에 저장되는 방식이기 때문에, 개인정보가 탈취된다는 문제가 있다. 이러한 문제를 해결하기 위한 방안이 세션이다.
세션은 쿠키와 다르게 쿠키 이전 처럼 서버에서 해당 정보를 관리한다. 단, 세션ID 라는 키 정보를 클라이언트에 저장하여, 매 요청마다 인증 혹은 인가가 필요한 경우, 이 키값이 존재하는 지를 확인하여 인증 상태를 지속하는 것이다. 주요 정보를 서버가 관리하기 때문에 쿠키 대비 보안성이 강하다는 장점이 있으나, 동일한 환경에서 쿠키에 비해 전송 속도가 느리며, 서버와의 요청-응답이 많다보니, 서버가 담당해야 하는 작업이 많아진다.
특히 문제가 되는 것이 서버를 분산시키거나, 여러개 두는 경우인데 로그인을 하기 위해 A 서버를 통해 세션 인증을 받은 상태라 하여도, 어떤 일련의 작업을 위해 B 서버를 탐색하는 경우 다시 세션 ID를 발급 받아야 하는 문제들이 발생한다.
쿠키 세션 요약하기
| 쿠키 | 세션 | |
|---|---|---|
| 저장 위치 | 클라이언트 | 서버 (웹 서버) |
| 저장 형식 | text | Object |
| 용량 제한 | 한 쿠키당 4KB 한 도메인 당 20개 전체 300개 | 서버를 제어하지 않는 이상 용량 제한 없음 |
| 속도 | 세션 대비 빠름 | 쿠키 대비 느림 |
| 보안 | 세션 대비 취약 | 쿠기 대비 강화 |
그럼 토큰 (JWT)은 뭐지?
웹 시장이 광범위 해지며 서버의 scale-out의 빈번히 발생하게 되었고, 그 결과 서버가 확장될 때 마다 세션을 동기화 해야하는 문제가 나타나게 되었다. 이 문제를 해결한 방식이 토큰 방식인데, 키 값을 발급하여 클라이언트로 보내는 것을과 기존과 동일하나, 암호화된 토큰을 복호화하는 작업이 정상적으로 수행되는 과정을 통해서 인증을 진행하는 방식을 사용한다. 기존의 세션 활용 대비 인증 데이터를 저장할 필요가 없기 때문에 인증 서버를 마련하지 않아도 된다는 장점과, 암호화 및 단방향 복호화만 가능하기 때문에 보안성에 강하다는 장점이 있다.
그러나 서버에서 인증키를 관리하지 않기 때문에 인증 이후 만료 시점까지 로그인을 제어할 수 없다는 단점이 존재한다. 오늘날과 같이 모바일, PC, 태블릿 등 다양한 플랫폼 환경에서 한 환경에 로그인을 한 경우, 다른 환경은 강제 로그아웃하게 만들어야 하는 서비스를 구현해야 한다면 토큰 방식 보다는 세션 방식을 사용하는 것이 좋다.
세션 vs 토큰
| 세션 | 토큰 | |
|---|---|---|
| 로그인 통제 | 가능 (인증 서버에서 키를 삭제하면 됨) | 불가능 (토큰이 만료 되거나, 유저가 로그아웃 전 까지 다음 조치를 취할 수 없음) |
| 서버 | 인증 관리를 위한 비용 필요 | 없어도 인증 가능 리프레시 토큰을 저장하기 위한 용도로 사용할 수 있으나 비용은 세션 서버보단 적음 |
| 주 사용 용도 | 은행, 음악 스트리밍 서비스 등 로그인, 로그아웃 상태를 통제가 가능하도록 만들어야 하는 서비스. | 블로그, 쇼핑몰 등 다수의 유저가 동일한 아이디로 접근해도 상관없거나 로그인, 로그아웃 상태를 통제할 필요가 없는 서비스. |
