1. Session
- 동일한 클라이언트가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안에 들어오는 일련의 Request를 하나로 보고, 그 상태를 일정하게 유지하여 클라이언트와 웸 서버가 논리적으로 연결된 상태
- 서버는 session에 대한 정보를 저장하고 클라이언트에게는 session을 구분할 수 있는 id를 부여
- request를 보낼 때 해당 session id를 부여
Session의 장점
- sessionID자체에는 유의미한 개인정보를 담고 있지 않다.
- 서버에서 정보를 관리하기때문에 데이터 손상우려가 적다
- 서버에서 상태를 유지하고 있어 로그인 여부확인이 쉽다.
Session의 단점
- 사용자 수가 증가할수록 서버에 부하가 증가한다.
- 서버의 양을 늘리면 관리가 어려워진다.
- 중복 로그인이 가능해진다.
2. Cookie
- 클라이언트의 컴퓨터에 저장되는 데이터 파일
- 이름, 값, 만료날짜, 시간, 경로정보 등으로 구성
- 도메인당 20개를 가질 수 있고 1개당 4kbyte 이하
- 클라이언트에서 서버에 http request에 저장된 cookie를 함께 전달
Cookie의 장점
- 서버의 자원을 사용하지 않는다.
- 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지
Cookie의 단점
- 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약
- 웹 브라우저마다 지원 형태가 다름
- 사용자가 보안상의 문제로 거부할 경우 사용 불가능
3. Token
제한된 리소스에 대해 일정 기간 동안 접근할 수 있는 권한을 캡슐화 및 접근할 수 있는 리소스의 범위와 접근 가능한 기간을 통제
Token의 장점
- token을 클라이언트측에서 저장하여 서버의 메모리 부담이 적고 서버증량에 용이하다.
- 모바일과 브라우저의 멀티환경에서 사용이 용이하다.
- 만료 시간을 짧게 설정하여 안정성을 높일수 있다.
Token의 단점
- 서버에서 사용자의 상태를 저장하고 있지 않기때문에 로그인 여부확인 등의 제재를 가하기가 어렵다.
- 사용자가 임의로 토큰을 수정하거나 변경하면 서버에서 확인이 어렵다.
- Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가
💡 세션 대신 쿠키를 사용하는 이유
세션이 보안성이 더 높고 데이터 손상우려가 더 적지만 쿠키를 사용하는 이유는 세션은 어쨌든 서버에서 관리하기 때문에 서버 자원의 한계를 느낄 수 있고 속도가 느려질 수 있다. 따라서 세션과 쿠키의 적절한 사용으로 보안성과 속도 둘 다 효율적으로 사용해야한다.
Front-End Developer