쿠키
쿠키
- 데이터 형태 : key-value로 구성된 string(text) 형태
- 저장 위치 : 클라이언트
- 사용자의 브라우저 (정확히는 브라우저가 지정하는 메모리 또는 하드디스크)
- 경량만 저장 가능
- 유효기간 존재
- 브라우저가 종료되어도 유효기간 내에는 쿠키가 유지됨 (지정하지 않을 경우 브라우저 종료시 만료)
- 쿠키에 저장된 데이터는 각 요청마다 클라이언트와 서버 사이에서 왔다갔다함
- 쿠키는 로그아웃 유무와 관계없이 삭제하지 않으면 유지됨
- 브라우저마다 저장되는 쿠키가 다름
- ex. 크롬으로 접속한 쿠키와 익스플로어는 다른 쿠키
쿠키 사용 목적
쿠키는 매개체이다. 쿠키 자체가 인증을 수행하는 것이 아니라 응답 헤더 쿠키 섹션에 인증된 사용자라고 알려주는 것이다. 그래서 꼭 인증 정보만을 전달하지는 않는다.
1. 세션 관리 : 로그인, 사용자 닉네임, 접속 시간, 장바구니 등 서버가 알아야할 정보 저장
2. 개인화 : 사용자마다 다르게 그 사람에 적절한 페이지를 보여줌
3. 트래킹 : 사용자의 행동·패턴을 분석하고 기록
ex. ID 저장, 로그인 상태 유지, 일주일간 다시 보지 않기, 최근 검색한 상품들을 광고에서 추천, 쇼핑몰 장바구니
세션 인증
세션
- 데이터 형태: Object 형태
- 저장 위치 : 서버의 세션 DB
- 쿠키보다 더 많은 양의 데이터 저장 가능
- 유효기간 존재
- 시간이 지나거나 사용자가 로그아웃 시 세션 데이터는 서버에서 제거됨
- 세션은 데이터를 서버 측에 저장하고, 각 클라이언트마다 고유한 식별자(session ID)를 할당함
- session ID는 클라이언트에서 일반적으로 쿠키에 저장되거나, URL에 추가되어 세션을 식별하는데 사용
- 아이디, 닉네임 등의 정보를 세션에 담아두면 요청이 있을 때마다 DB에 접근할 필요가 없어서 효율적
- 세션은 로그아웃하면 새로운 사용자로 인식해서 새로 생성됨
쿠키&세션 인증 방식의 공통점
웹 개발에서 상태를 유지하고 사용자 정보를 관리하기 위해 사용되는 매커니즘
쿠키&세션 인증 방식의 단점
- 서버가 세션을 저장하고 관리해야해서 서버 리소스 부담이 될 수 있음(활성 사용자의 수만큼 세션을 유지해야함)
- 세션 ID는 사용자별로 관리되므로 멀티 디바이스에 대한 고려가 필요
- 쿠키는 서버가 가지고 있는 것이 아니라 사용자에게 저장되기 때문에 보안에 취약함
- 쿠키 수집은 방문했던 웹사이트에 대한 정보 및 개인정보가 기록되기때문에 사생활 침해의 소지가 있으며 이러한 쿠키 수집을 사용자가 거부하면 본래 목적인 지속적인 연결 기능을 수행할 수 없음
토큰 기반 인증 (JWT)
쿠키는 브라우저에서만 의미가 있다.
Native app은 쿠키를 사용할 수 없으므로 그때 필요한게 JWT token이다.
JWT token은 유효한지 아닌지만 판단하기 때문에 DB를 사용하지 않도록 만들 수 있다.
하지만 DB가 없기 때문에 JWT token만 갖고는 강제 로그아웃과 같은 기능을 구현할 수 없다.
추가적인 구현이 필요하다.
그래서 어플리케이션을 개발할 때 처음엔 JWT token을 사용해 구현하고 사용자와 요청을 더 관리해야 할 필요가 있을때 session DB와 함께 사용한다.
보통 session DB로 많이 언급되는 것이 Redis이다.
JWT 인증
오늘 들은 라이브 강의에서는 JWT 인증 사용시 API 호출마다 이루어지는 4개의 DB Connection (사용자 인증, 내용 확인, 내용 처리, 처리 반영) 에서 사용자 인증 단계를 생략함으로써 비용적으로 25%를 절감함과 동시에 속도를 25% 개선할 수 있는 이점이 있다고한다.
참고자료
쿠키와 세션의 개념/차이/용도/작동방식
[기초 CS 개념] 쿠키 vs. 세션
세션과 쿠키의 차이점, 그리고 JWT token: session vs cookie vs JWT token
완벽 정리! 쿠키, 세션, 토큰, 캐시 그리고 CDN
