[TIL][03.06] @CrossOrigin, WebMvcConfigurer, 쿠키, 세션 스토리지, 로컬 스토리지, fetch, axios, jwt

Spring Boot CORS 설정 방법

• 컨트롤러에서 @CrossOrigin 사용
• 전역 설정에서 WebMvcConfigurer 사용 (MyConfig 클래스)

둘 다 CORS를 설정하지만, 적용 범위와 기능이 다름

컨트롤러에서 @CrossOrigin을 사용한 경우

• @CrossOrigin은 해당 컨트롤러 또는 특정 엔드포인트에서만 CORS 허용
• 전역 적용이 안 됨 → 다른 컨트롤러에서는 CORS 설정이 적용되지 않음
• 세션/쿠키 인증을 위해서 allowCredentials=true도 각각 적용해야 함
• 메서드마다 일일이 @CrossOrigin을 추가해야 함

전역 CORS 설정 (WebMvcConfigurer)을 사용한 경우

• 모든 컨트롤러 & 모든 엔드포인트에 CORS 적용 → 전역 설정
• allowCredentials(true) 설정 → 세션, 쿠키 인증을 사용할 수 있음
• 코드가 깔끔해지고, 모든 API에 한 번에 적용 가능

로그인 상태 관리 (sessionStorage)

서버에서 JSESSIONID를 부여해도 웹 브라우저의 쿠키에 저장되기 때문에 새로고침하면 없어짐.

새로고침해도 계속 있는 sessionStorage를 사용

window.sessionStorage.setItem("id", id);

로그인에 성공한 경우 setItem으로 sessionStorage에 저장

sessionStorage.removeItem("id");
window.location.reload();

로그아웃 한 경우 removeItem으로 sessionStorage에서 로그인 정보 삭제

웹 브라우저 정보 저장 방식

쿠키 (Cookie)

• 서버와 클라이언트(브라우저) 간에 데이터를 주고받을 수 있는 작은 데이터 저장소
• 서버에서 생성하여 브라우저에 저장하거나, 클라이언트에서 직접 생성할 수도 있음
• 브라우저가 자동으로 쿠키를 요청 헤더에 포함하여 서버로 보냄
• 쿠키 기반 세션은 해킹될 가능성이 있음 (세션 하이재킹)
• Session Cookie: 브라우저가 닫힐 때 삭제됨 (수명이 가장 짧음)
• Persistent Cookie: 만료 시간이 설정되면 유지됨

세션 스토리지 (Session Storage)

• 브라우저에 데이터를 임시 저장 (브라우저 탭을 닫으면 삭제됨)
• 클라이언트 측에서만 접근 가능 (서버에 자동 전송되지 않음)
• 키-값 형태로 저장됨
• 서버로 자동 전송되지 않음 → 인증 정보 저장에 부적절
• 현재 탭(세션)이 닫히면 삭제됨 (수명이 짧음)

로컬 스토리지 (Local Storage)

• 브라우저에 데이터를 영구적으로 저장 (사용자가 직접 삭제하지 않는 한 유지됨)
• 클라이언트 측에서만 접근 가능 (서버로 자동 전송되지 않음)
• 암호화되지 않음
• 브라우저를 꺼도 유지됨 (삭제하기 전까지 영구 저장)

쿠키가 보안상 더 나은 이유

 

• 세션 쿠키(Session Cookie)는 브라우저를 닫으면 자동 삭제됨
  → 수명이 짧아, 탈취되더라도 지속적인 위험이 줄어듦
• 서버에서 관리 가능
  → 쿠키 기반 세션을 사용하면 서버에서 세션을 관리하면서 인증 정보를 보호할 수 있음

fetch vs axios

JSON 변환 자동화

• fetch()를 사용하면 response.json()을 호출해야 JSON 데이터로 변환됨
• axios는 응답을 자동으로 JSON으로 변환하여 .data에 저장해 줌

CORS 요청에서 쿠키 포함 설정

• fetch를 사용할 때 쿠키를 포함하려면 각각의 모든 요청에 credentials: "include" 설정이 필요함
• axios는 withCredentials: true 설정으로 간편하게 모든 요청에 쿠키 포함 가능

MSA 환경에서 세션 ID 공유 문제

문제

• 상품 서비스, 주문 서비스처럼 여러 서버가 DB 부하를 줄이기 위해 분리됨
• 세션을 서버 메모리에 저장하면 서버 간 공유 불가능 → 세션 ID 동기화 문제 발생

해결책

• JWT 사용 → 중앙 저장소 없이 각 요청에 토큰 포함하여 인증 유지

JWT (JSON Web Token)

두 당사자 간에 정보를 안전하게 전송하기 위한 표준

JWT는 JSON 객체를 기반으로 하며, 정보의 무결성을 보장

• JWT는 기밀성(Confidentiality) 보장 X
  • 토큰 내부에 ID, 권한 정보 등이 들어가지만 암호화되지 않음 (Base64로 인코딩된 것뿐)
  • 따라서 중요한 정보(비밀번호 등)는 JWT에 포함하면 안 됨
• JWT는 무결성(Integrity) 보장 O
  • 토큰이 변조되지 않았음을 검증하는 용도

MSA에서 인증 방식

• 세션 방식 (Switch) 가능하지만 비용 문제
  • MSA 환경에서 Switch(세션 기반 인증)를 사용하려면, 모든 서버가 세션 저장소에 접근해야 함 → 비용 증가
• 차선책: JWT 사용
  • JWT는 각 요청에 포함되어 검증되므로 세션 공유 불필요
  • 그러나 JWT 자체는 보안이 아님 → 추가적인 보안 조치 필요