반응형
SMALL
우선 데이터를 저장하는 유형에는 세션 스토리지, 로컬 스토리지, 쿠키, DB를 이용하는 방식에 대해 설명하겠습니다.
구분 | 세션 스토리지 | 로컬 스토리지 | 쿠키 | 데이터베이스(DB) |
데이터 저장 위치 | 브라우저 | 브라우저 | 브라우저(서버로 전송 가능) | 서버 |
유효범위 | 브라우저 탭(세션) 종료 시 삭제 | 영구 저장(삭제 전까지 유지) | 만료 기간 설정 가능 | 영구 저장 |
저장용량 | 5MB~10MB | 5MB~10MB | 4KB | GB~TB 단위 |
서버 전송 여부 | 서버로 자동 전송 되지 않음 | 서버로 자동 전송되지 않음 | HTTP 요청 시 자동 저전송 가능 | 서버에서 직접 관리 |
보안 | JAVASCRIPT에서 접근 가능(XSS 공격 위험) | JAVASCRIPT에서 접근 가능(XSS 공격 위험) | HTTPONLY설정하면 JAVASCRIPT로 접근 불가(보안 강화) | 높은 보안 수준 |
사용목적 | 현재 페인지 내 임시 데이터 저장 | 장기적인 클라이언트 데이터 저장 | 사용자 인증(세션 ID, JWT 등) 및 설정 저장 | 사용자 정보, 로그 데이터 등 영구적인 데이터 저장 |
예제 코드 | sessionStorage.setItem("key", "value") | localStorage.setItem("key", "value") | document.cookie = "key=value" | INSERT INTO users VALUES (...) |
웹 애플리케이션에서 사용자 인증을 처리할 때 세션 기반 인증(Session ID)과 토큰 기반 인증(JWT)이 대표적인 방식입니다.
세션 ID(Session ID)
세션 ID는 서버가 생성하는 고유한 식별자(ID)로, 사용자의 로그인 상태를 관리하는 방식이다.
로그인 시 서버가 세션을 생성하고, 세션 ID를 클라이언트에 제공하여 이후 요청에서 인증을 수행한다.
세션 ID 기반 인증 흐름
- 사용자가 로그인 요청을 보냄 (ID, 비밀번호 입력).
- 서버가 사용자 인증을 수행하고, 로그인 성공 시 세션을 생성.
- 세션 ID(Session ID)를 생성하여 클라이언트에 전달 (쿠키에 저장).
- 클라이언트는 이후 요청을 보낼 때 세션 ID를 쿠키에 포함하여 서버에 전송.
- 서버는 세션 저장소(Session Storage)에서 세션 ID를 조회하여 사용자를 인증.
세션 ID 특징
- 세션 정보는 서버에 저장됨 → 서버가 세션을 관리해야 하므로 상태 유지(Stateful) 방식.
- 세션 ID는 일반적으로 쿠키에 저장되어 자동으로 전송됨.
- 보안 위험: 세션 ID가 유출되면 다른 사람이 해당 사용자의 계정을 사용할 수 있음 (세션 하이재킹 공격 가능).
JWT(JSON Web Token)
JWT는 사용자 정보를 포함하는 토큰(Token) 기반의 인증 방식으로, 로그인 후 서버가 토큰을 발급하고, 클라이언트가 이 토큰을 저장한 후 요청 시마다 전송하는 방식이다.
JWT 기반 인증 흐름
- 사용자가 로그인 요청을 보냄 (ID, 비밀번호 입력).
- 서버가 사용자 인증을 수행하고, 로그인 성공 시 JWT를 생성.
- 서버는 JWT를 클라이언트에 전달 (쿠키 또는 Authorization 헤더에 저장).
- 클라이언트는 이후 요청을 보낼 때 JWT를 Authorization 헤더 또는 쿠키에 포함하여 서버에 전송.
- 서버는 JWT의 서명(Signature)을 검증하여 사용자 인증을 수행.
JWT 특징
- 서버가 상태를 저장할 필요 없음 → JWT 내부에 사용자 정보를 포함하고 있어 무상태(Stateless) 방식.
- 토큰 자체가 인증 정보이므로, 서버에서 세션을 저장하지 않음.
- 보안 강화 가능: JWT는 서명이 포함되어 있어 변조 방지 가능하지만, 탈취될 경우 보안 위험이 있음.
세션 저장소(Session Storage) vs JWT(JSON Web Token) 장단점 비교
✅ 세션 저장소(Session Storage) 장점
- 보안성이 높음 → 세션 정보가 서버에 저장되므로, 클라이언트에서 데이터 조작 불가능.
- 세션 무효화 가능 → 서버에서 특정 사용자의 세션을 삭제하면 강제 로그아웃 가능.
- 쿠키 기반이므로 클라이언트에서 헤더를 추가하지 않아도 됨 → 자동으로 인증 처리 가능.
❌ 세션 저장소(Session Storage) 단점
- 서버 부하 증가 → 모든 로그인 사용자의 세션을 저장해야 하므로, 많은 사용자를 처리할 때 성능 저하 가능.
- 로드 밸런싱 어려움 → 여러 서버가 있을 경우, 세션을 공유하는 메커니즘(예: Redis 세션 저장소)이 필요함.
- 확장성 낮음 → 서버가 상태를 저장하므로, 분산 환경에서 관리가 어려움.
✅ JWT(JSON Web Token) 장점
- 서버 부담 없음 → 서버가 상태를 저장하지 않으므로, 확장성이 뛰어남.
- 어디서나 사용 가능 → 모바일, API, 마이크로서비스, 서버리스 환경에 적합.
- 속도가 빠름 → 서버가 DB 조회 없이 JWT의 서명(Signature)만 검증하면 인증 완료.
❌ JWT(JSON Web Token) 단점
- 보안 위험 → JWT가 유출되면 만료 전까지 탈취자가 사용할 수 있음.
- 토큰 무효화 어려움 → 발급된 JWT를 즉시 무효화할 방법이 없음. (Refresh Token으로 보완 가능)
- 토큰 크기 문제 → JWT는 사용자 정보를 포함하므로, 세션 ID보다 크기가 큼.
✅ 세션 저장소(Session Storage) 사용이 적절한 경우
- 보안이 중요한 경우 → 서버에서 세션을 관리하며, 세션 삭제로 강제 로그아웃 가능.
- 웹 애플리케이션 중심 인증 → 브라우저에서 로그인 유지가 필요한 경우.
- 트래픽이 적고 서버 부담이 크지 않은 경우.
✅ JWT 사용이 적절한 경우
- 확장성이 중요한 경우 → 여러 서버에서 인증해야 하는 마이크로서비스, API 서버, 모바일 환경.
- RESTful API 기반 인증 → 클라이언트가 API 호출 시 인증이 필요할 때.
- 서버 부담을 줄여야 하는 경우 → 인증을 빠르게 처리해야 하는 대규모 서비스.
보안이 중요하고 서버 부하가 크지 않다면 세션 기반 인증,
확장성이 중요하고 서버 부담을 줄이고 싶다면 JWT 기반 인증을 선택하는 것이 적절하다.
반응형
LIST
'cs정리' 카테고리의 다른 글
OAuth 2.0 원리 (0) | 2025.02.06 |
---|---|
JWT를 이용한 인증 방식의 동작 원리 (0) | 2025.02.05 |
SPRING SECURITY 개념과 사용하는 이유 (0) | 2025.02.05 |
spring IOC 컨테이너란? (0) | 2024.11.11 |
스프링 빈 주입시 생기는 문제들 (0) | 2024.11.09 |