우선 기존 프로젝트에서 커피 products와 member 데이터를 sql에서 불러오고 저장하며, 회원가입과 로그인을 구현했었다.
오늘은 이 개발자도구의 애플리케이션에서 보이는 쿠키와 세션에 대해 자세히 다루어보겠다.
쿠키와 세션 차이
쿠키 (Cookie)
- 정의: 웹사이트가 사용자 컴퓨터(브라우저)에 저장하는 작은 텍스트 파일
- 역할:
- 사용자 설정, 로그인 정보, 방문 기록 등 간단한 정보 저장
- 웹사이트 재방문 시 사용자 식별
- 특징:
- 저장 위치: 클라이언트(브라우저)
- 보안: 취약 (정보 유출 위험)
- 용량: 제한적
- 예시: "자동 로그인" 기능에서 사용자 ID 저장
쿠키는 길거리에 흘린 쪽지로 비유할 수 있다.
(누구나 볼 수 있고, 내용도 간단하며 분실 가능)
세션 (Session)
- 정의: 웹 서버가 사용자 정보를 저장하는 공간
- 역할:
- 로그인 상태, 장바구니 등 사용자 상태 유지
- 쿠키보다 높은 보안성 제공
- 특징:
- 저장 위치: 서버
- 보안: 강함
- 용량: 서버 자원에 따라 다름
- 예시: 로그인 후 사용자 정보를 서버에 저장하여 안전하게 관리
세션은 도서관 사물함으로 예시를 들수 있다.
(중요한 물건을 안전하게 보관, 열쇠(세션 ID)만 가지고 다님)
-> 이는 세션 ID를 통해 쿠키를 만든다고 생각하면된다.
차이점 요약
| 구분 | 쿠키 | 세션 |
|---|---|---|
| 저장 위치 | 클라이언트 (브라우저) | 서버 |
| 보안성 | 낮음 | 높음 |
| 저장 용량 | 제한됨 | 서버 용량에 따라 다름 |
| 정보 유출 위험 | 높음 | 낮음 |
| 용도 | 사용자 설정, 간단한 정보 저장 | 로그인 정보, 장바구니 등 중요 정보 저장 |
프로젝트에서?
그럼 프로젝트의 개발자 도구의 애플리케이션을 보면 쿠키에서 JSESSIONID를 볼 수 있다. 이게 세션에서 던져주는 세션의 아이디 값 (도서관 사물함 열쇠)이다.
이 과정을 위의 그림과 같이 나타낼 수 있다. (ㅇㅈ님 감사합니다. 참고했어요..)
동작과정
1. 로그인 요청 (Web Browser -> Server)
- 요청 방식: POST
/login - 본문 (body):
{"email": "a@a.com", "pwd": "a" }- 사용자가 입력한 이메일과 비밀번호 전송
2. 세션 생성 및 쿠키 전달 (Server)
- 세션 저장소 (Server Memory)에 새 세션 생성
K(키) -V(값) 형태 저장member키에@100(메모리 주소) 값 저장
@100메모리 주소에Member객체 생성email,pwd,nickname등 사용자 정보 저장
- 응답 상태 코드 (status):
200 OK - 응답 헤더 (header):
Set-Cookie: JSESSIONID=1; Domain=example.com;JSESSIONID=1쿠키 생성 (세션 ID: 1)Domain=example.com쿠키 적용 범위 설정
- 응답 본문 (body):
{"msg": "ok"}- 로그인 성공 메시지
3. 쿠키 저장 (Web Browser)
example.com도메인에JSESSIONID=1쿠키 저장naver.com도메인에name=2쿠키 저장 (별도의 쿠키, 예시)- 브라우저는 도메인별로 쿠키를 분리하여 관리
4. 장바구니 요청 (Web Browser -> Server)
- 요청 방식: POST
/cart - 헤더 (header):
example.com도메인의JSESSIONID=1쿠키 자동 전송- 요청 시 쿠키 자동 포함
그렇다면 세션관리 측면에서 Fetch와 Axios의 차이는 뭘까?
Fetch는 쿠키 자동 전송 X, 직접 구현 필요한 부분이(json 직접 변환) 많아 불편하다.
반면 Axios는 쿠키 자동 전송 O, 인터셉터 등 편의 기능(json 자동 변환) 다수 제공하여 편리하다.
때문에 세션관리와 JWT 인증시에도 Axios가 개발 편의성과 효율성 훨씬 높다!!
MSA에서의 JWT
JWT(JSON Web Token)는 정보를 안전하게 전달하기 위한 개방형 웹 표준으로 JSON 형식으로 정보를 표현한다.
대표적으로 우리가 알고있는 큐알코드가 JWT방식이다!
디지털 서명을 통해 위변조를 방지하는 주로 사용자 인증 및 권한 부여에 사용되어 기존 방식보다 현대적인 웹 표준이라고 볼 수 있다.
왜 JWT를 쓸까? (기존 세션 방식과 다른점)
- 서버 부담 증가:
- 기존 세션은 서버 메모리나 DB에 저장됨. 사용자 많아지면 서버 과부하가 온다.
- 특히 MSA (마이크로서비스 아키텍처)에서는 서비스마다 세션 관리해야 하기 때문에 JWT가 필요함.
- 확장성 문제:
- 서버 여러 대로 늘리면 세션 공유 복잡해짐. 클러스터링/복제 필요.
-> JWT는 이런 문제를 해결해 준다!
- 서버 부담 감소:
- JWT는 서버에 세션 저장 안 함. JWT 자체에 사용자 정보 담음.
- MSA에서 각 서비스가 독립적으로 사용자 인증 가능.
- 확장성 확보:
- 각 서비스가 JWT만 검증하면 되니 세션 공유 필요 없음.
- MSA에서 서비스 늘려도 문제 없음.
- DB 부하 감소:
- JWT는 DB 조회 안 함. DB 부하 줄여줌.
-> 다만 토큰 털리면 다털리는 정보라 보안에 매우 취약
위 그림은 JWT(왼쪽)와 기존 세션 방식(오른쪽)을 보여준다.
[오른쪽: 기존 세션 방식]
기존 세션 방식은 세션 ID를 통해 접근한다.
- 웹 브라우저: "상품 보여줘!" / "주문해줘!"
- 웹 서버: "누구세요?" (세션 확인) -> "아, 당신이군요!" (HttpSession)
- 세션은 서버 메모리나 DB에 저장됨.
- 상품/주문 서비스: 웹 서버가 "나 대신 상품 보여줘!" / "주문해줘!"
- DB: "세션 정보 여기 있어!"
-> DB부하 증가
[왼쪽: JWT 방식]
JWT 방식은 API GATEWAY를 통해 접근한다.
- 웹 브라우저: "상품 보여줘!" (JWT 첨부) / "주문해줘!" (JWT 첨부)
- API Gateway: "이 JWT는 유효한가?" (검증) -> "맞는 사용자군!"
- API Gateway는 JWT 검증하고, 각 서비스로 요청 전달.
- 상품/주문 서비스: "이 JWT는 유효한가?" (검증) -> "맞는 사용자군!"
- 각 서비스가 JWT 검증하여 사용자 인증.
- DB: "JWT라니? 나는 몰라!" (DB 부하 감소!)
API Gateway는 클라이언트 요청을 받아서 각 서비스로 전달하고, 검증, 인증, 권한을 부여한다.
JWT의 장점과 단점 (결론)
이처럼 JWT는 서버 부담을 줄이고 확장성을 높여 MSA 환경에 적합하며, API Gateway와 함께 사용하여 MSA 구성을 단순화할 수 있다는 장점을 가지고 있다.
하지만 토큰 하나가 탈취되면 전체 시스템이 위험에 노출될 수 있다는 보안상의 취약점을 해결하기 위해 JWT를 사용할 때는 다음과 같은 추가적인 보안 조치를 고려해야 한다.
- 토큰의 유효 기간을 짧게 설정: 토큰 탈취 시 피해 범위를 최소화
- Refresh Token 도입: Access Token의 유효 기간을 짧게 설정하고, Refresh Token을 통해 새로운 Access Token을 발급받아 보안성을 강화
- HTTPS 사용: 토큰이 네트워크를 통해 전송될 때 암호화하여 탈취 가능성을 낮춤
- 토큰 저장 시 암호화: 클라이언트 측에 토큰을 저장할 때 안전한 저장소를 사용하고 암호화하여 저장
이러한 단점 때문에 SNS 계정은 계정 탈취 및 악용을 방지하기 위해 특정 환경에서만 로그인을 허용하여 JWT를 지양한다.
