스프링부트로 구현을 해보고 싶다면 여기로!
🍪 쿠키란?
- 서버가 사용자의 웹 브라우저에 저장하는 데이터
- 이때 브라우저마다 저장되는 쿠키가 다르다.
- 예를 들어 크롬으로 받은 쿠키는 익스플로어에서 사용 불가
- 데이터 형태는
key-value이며String으로 이루어져 있다. - 쿠키는 서버를 대신해 정보를 웹 브라우저(클라이언트 컴퓨터)에 저장한다.
- 사용자가 서버에 요청시, 쿠키를 함께 보내서 사용자를 식별할 수 있게 해준다.
- 자동으로 Request header에 넣어서 전송해준다.
❌ 쿠키의 치명적인 단점 ❌
- 쿠키 값은 임의로 변경할 수 있다.
- 클라이언트가 쿠키를 강제로 변경하면 다른 사용자가 된다.
- 쿠키에 보관된 정보는 훔쳐갈 수 있다.
- 이 정보가 웹 브라우저에도 보관되고, 네트워크 요청마다 계속 클라이언트에서 서버로 전달된다.
- 해커가 쿠키를 한번 훔쳐가면 평생 사용할 수 있다.
- 해커가 쿠키를 훔쳐가서 그 쿠키로 악의적인 요청을 계속 시도할 수 있다.
대안점은?
- 쿠키에 예측 불가능한 임의의 토큰을 노출해야 한다.
- 단, 서버에서는 해석이 가능하게 한다.
- 토큰의 만료시간을 짧게(예: 30분) 유지하게 한다.
- 해킹이 의심되는 경우에는 서버에서 해당 토큰을 컨트롤할 수 있어야 한다.
이런 보안 문제 때문에 로그인 같은 예민한 정보를 저장할 때는 세션을 이용한다.
📌 쿠키와 세션 차이
-
쿠키
- 저장위치: 클라이언트
- 사용 자원: 클라이언트의 리소스
- 속도: 세션보다 빠르다.
- 보안: 세션보다 취약
- 저장형식: text
-
세션
- 저장위치: 서버
- 사용 자원: 서버의 리소스 (주로 서버 메모리, 비싼 자원)
- 속도: 쿠키보다 느림
- 보안: 쿠키보다 좋음
- 저장형식: Object
📌 세션의 예시
- 클라이언트가 서버에 최초 접속을 한다.
- 서버에서는 세션 저장소에 새로운 세션ID를 생성한다.
- 응답으로 헤더에 세션ID를 준다.
- 클라이언트가 서버에 로그인 요청을 보낸다.
- 이때 request header에 세션ID를 준다.
- 서버에서는 DB를 조회해 올바른 회원 정보인지 확인한다.
- 올바른 회원 정보라면 request header에 있는 세션ID를 이용해 세션 저장소에 로그인 한 회원이라는 정보를 저장
- 이때 세션 저장소에 저장하는 데이터는 서버가 구현하기 나름이다.
- 주로 메모리에 저장되기 때문에, 최소한 간단하면서 사용자를 구분할 수 있는 데이터를 저장
- 클라이언트가 로그인한 자신의 유저 정보를 요청
- 물론 이때도 request header에 세션ID를 준다.
- 서버에서는 받은 세션ID를 이용해 이 이용자가 로그인한 회원인지 확인
- 로그인 했다면 세션 저장소에 있는 회원 정보를 이용해 유저 정보를 응답해줌
❌ 세션의 문제점 ❌
- 기본적으로 HTTP 프로토콜은 비연결성(Connectionless), 비상태성(Stateless) 한 특징을 가진다.
- 이 특징 때문에 쿠키, 세션을 사용한다.
- 서버가 여러대 있고, 이를 로드 밸런싱으로 처리한다면?
- 만약 사용자1이 서버1을 통해 로그인했다면, 세션은 서버1에 저장될 것이다.
- 그렇다면 다음 요청시 항상 서버1에 요청한다는 보장이 있느냐? 아니다.
- 따라서 모든 서버가 공동으로 사용하는 세션을 만들어야 한다.
- DB를 사용한다면 I/O가 일어나기 때문에 속도가 매우매우 느려진다.
- 속도를 위해 메모리 공유 서버를 사용할 수도 있다. (대표적으로 Redis)
- 하지만.. 그 비싼 자원은 서버가 다 감당해야 하는가?
이에 대한 문제로 최근에는 토큰 기반의 인증 방식을 사용하는 추세이다.
다음 게시물에서는 JWT(JSON Web Token)을 공부해보자.
reference
https://www.youtube.com/watch?v=cv6syIv-8eo&list=PL93mKxaRDidERCyMaobSLkvSPzYtIk0Ah&index=13
https://devuna.tistory.com/23
I Think So!