1. 쿠키와 세션의 차이에 대해 설명해주세요
쿠키와 세션의 가장 큰 차이는 사용자 정보가 저장되는 위치입니다.
쿠키는 클라이언트 쪽에 데이터를 저장합니다. 예를 들어, 브라우저에 <이름, 값> 형태로 저장되기 때문에 서버 자원을 사용하지 않습니다. 반면, 세션은 서버에서 데이터를 관리합니다. 서버가 클라이언트를 구분하기 위해 세션 ID를 생성해 쿠키에 담아 클라이언트에게 보내고, 이후 요청 시 세션 ID를 통해 서버에서 필요한 정보를 처리합니다.
보안 측면에서도 차이가 있습니다. 쿠키는 클라이언트에 저장되기 때문에 변조되거나 스니핑 당할 위험이 있지만, 세션은 서버에서 중요한 데이터를 관리하므로 보안성이 더 높습니다.
라이프 사이클의 경우, 쿠키는 만료 시간을 설정하면 브라우저를 종료해도 유지될 수 있지만, 세션은 브라우저를 닫으면 기본적으로 삭제됩니다. 물론 세션도 만료 시간을 설정할 수 있습니다.
속도 면에서는 쿠키가 더 빠릅니다. 쿠키는 클라이언트에서 모든 데이터를 처리하기 때문에 처리 속도가 빠르고, 세션은 서버 처리가 필요해서 상대적으로 느릴 수 있습니다.
결론적으로, 쿠키는 클라이언트에 저장되며 속도가 빠르고, 세션은 서버에 저장되어 보안성이 더 높다고 정리할 수 있습니다.
2. jwt토큰에 대해 설명해주세요
JWT 토큰은 JSON Web Token의 약자로, 인증(Authentication)과 인가(Authorization)를 위한 인터넷 표준 방식입니다. 쉽게 말해, 사용자 인증에 필요한 정보를 JSON 객체로 담고, 비밀키로 서명한 토큰입니다.
JWT의 동작 방식을 간단히 설명드리면, 사용자가 로그인하면 서버가 비밀키를 이용해 JSON 객체를 암호화한 JWT 토큰을 생성합니다. 이후 이 토큰을 클라이언트에 전달하고, 클라이언트는 이를 로컬에 저장한 뒤 API 호출 시 헤더에 포함시켜 서버로 전송합니다. 서버는 이 토큰을 확인해 사용자가 신뢰할 수 있는지 인증하고 요청을 처리합니다.
JWT는 Header, Payload, Signature로 구성됩니다.
Header에는 알고리즘과 토큰 타입 정보가,
Payload에는 사용자 정보인 클레임(claim)이 담깁니다.
Signature는 Header와 Payload를 결합해 비밀키로 암호화한 값으로, 보안성을 책임지는 부분입니다.
JWT는 Header와 Payload가 Base64로 인코딩되어 누구나 내용을 볼 수 있지만, Signature는 key가 없으면 복호화할 수 없어서 보안이 유지됩니다.
장점으로는
토큰을 로컬에 저장하기 때문에 서버 자원을 소모하지 않습니다.
비밀키나 공개키-개인키로 서명해 보안성이 높습니다.
모바일 앱 등 다양한 플랫폼에서 독립적으로 인증 처리가 가능합니다.
네트워크 부하가 적습니다.
단점으로는
토큰 크기가 커질수록 트래픽에 영향을 줄 수 있고,
토큰이 발급된 후 만료 기간을 변경할 수 없어서 별도로 만료 처리 로직을 구현해야 합니다.
결론적으로, JWT는 서버 자원을 절약하고 보안성을 높이며, 다양한 플랫폼에서 인증 처리를 간단하게 할 수 있는 효율적인 인증 방식입니다.
3. sop과 cors에 대해 설명해주세요
SOP(Same-Origin Policy)와 CORS(Cross-Origin Resource Sharing)는 웹 보안과 리소스 공유를 관리하기 위한 정책입니다.
- SOP(Same-Origin Policy):
SOP는 동일 출처 정책으로, 웹 브라우저가 하나의 출처(origin)에서 로드된 자원이 다른 출처의 자원과 상호작용하지 못하도록 제한하는 보안 규칙입니다.
동일 출처란 프로토콜, 호스트, 포트가 모두 같은 경우를 말합니다.
예: http://example.com:80과 https://example.com은 출처가 다릅니다.
SOP는 자바스크립트의 교차 출처 요청을 제한하며, 이를 통해 잠재적인 보안 위험을 막습니다.
SOP 영향이 없는 예외:
다른 도메인의 리소스를 삽입하는 경우, SOP가 적용되지 않습니다.
예:
- CORS(Cross-Origin Resource Sharing):
CORS는 교차 출처 리소스 공유로, 서로 다른 출처 간의 리소스 요청을 허용하기 위한 HTTP 헤더 기반 정책입니다.
기본적으로 브라우저는 SOP 때문에 교차 출처 요청을 차단하지만, CORS를 통해 특정 조건에서 이를 허용할 수 있습니다.
예를 들어, React 서버(3000번 포트)와 Spring Boot 서버(8080번 포트) 간의 요청은 포트가 다르므로 교차 출처로 간주됩니다.
CORS 작동 방식:
클라이언트가 서버에 요청할 때, 브라우저는 먼저 Preflight 요청(OPTIONS 메서드)을 보냅니다.
서버는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등의 헤더로 허용 여부를 응답합니다.
결론적으로, SOP는 교차 출처 요청을 제한해 보안을 강화하는 정책이며, CORS는 필요에 따라 서버 설정을 통해 교차 출처 요청을 허용할 수 있는 방식입니다. SOP는 브라우저의 기본 동작이고, CORS는 이를 완화해 다른 출처 간 리소스 공유를 가능하게 합니다."
