[CS 스터디] 3주차

쿠키 vs 세션 vs JWT 토큰

HTTP 프로토콜의 특징 중 하나는 무상태성입니다. 무상태성은 상태를 가지고 있지 않음을 의미합니다. 

따라서 이전 요청과의 상태 공유를 할 수 없습니다. 

내가 이전에 한 요청을 기억하지 못한다면 요청간에 문맥이 전혀 없는 작업을 수행할 수 밖에 없는 단점이 있습니다.

이를 해결하기 위한 도구들이 바로 쿠키, 세션, 토큰 입니다. 이 3개 모두 상태를 저장하는 역할을 합니다.

 

쿠키

쿠키는 웹 브라우저에 저장되는 작은 데이터 단위 입니다. 

웹 서버에서는 HTTP 응답 헤더를 통해 쿠키에 데이터를 넣어서 브라우저로 전송할 수 있습니다. 

그리고 다시 브라우저에서 서버에 어떤 요청을 할때 이 쿠키를 같이 보낼 수 있습니다.

쿠키에는 주로 사용자의 인증 정보, 세션 식별자, 사용자의 설정 등을 저장하는데 사용됩니다.

세션

세션은 클라이언트와 서버 사이에 연결을 유지하는 방법 중 하나입니다.

각 클라이언트에 대해서 서버는 고유한 세션 ID를 생성하고 이를 클라이언트가 받아서 가지고 있다가

서버에 요청을 할때 같이 보낼 수있습니다. 서버측에서는 세션 ID를 관리하기 위한 db를 따로 생성합니다.

보통은 db에 세션 ID와 클라이언트(사용자)를 특정할 수 있는 값을 함께 저장합니다. 

세션은 주로 사용자 로그인 정보, 장바구니 내용, 임시 데이터 등을 저장하는데 사용됩니다. 여기서 보면 알수 있듯이 세션은 로그인을 한 상태에만 해당하는 것이 아닙니다. 로그인 상태를 관리할 때도 사용되지만 , 익명 사용자(로그아웃 상태)일때도 사용되는 개념입니다.

로그인을 하지 않았을 경우에는 보통 세션 쿠키라는것을 발급하게 되고 이것은 브라우저 창을 닫으면 삭제됩니다.

 

 

 

 

네이버에서 로그인을 하지 않았을때 웹 브라우저 쿠키에 저장된 값을 보면, JSESSIONID 라는 key 값이 저장된 것을 볼 수 있는데, 이 키는 톰캣 컨테이너에서 세션을 유지하기 위해 발급하는 키 입니다.

로그인을 하지 않고도 장바구니에 물건을 담을 수 있는 것도 다 이런식으로 세션을 유지하기 때문이라고 볼 수 있습니다. 

토큰

토큰은 인증/인가 작업을 하기 위해 사용되는 수단입니다. 일반적으로 토큰은 클라이언트와 서버 통신에 사용되고, 클라이언트가 서버에 대한 자격 증명을 제공하면 (ex. 로그인) 서버가 그에 따른 권한을 부여하는 데 사용됩니다.

 

JWT(토큰)은 JSON Web Token의 약자로, 웹에서 안전하게 정보를 주고받기 위해 사용됩니다. 

JWT는 Header, Payload, Signature 세 부분으로 구성되어 있으며 각 부분은 Base64로 인코딩되어 하나의 문자열이 됩니다.

 

JWT 토큰을 주고받는 방법

1. 사용자(클라이언트)가 로그인 요청

2. 서버에서 JWT 생성후 클라이언트에게 전달

3. 클라이언트는 권한이 필요한 작업을 요청할때 마다 JWT 토큰을 같이 보냄

4. 서버에서 JWT를 통해 클라이언트 식별 후 요청에 대한 응답

 

---

SOP , CORS

SOP(Same-Origin-Policy) 는 웹 보안의 중요한 개념 중 하나로, 웹 브라우저에서 실행되는 스크립트 언어(주로 JavaScript)가 동일한 출처(Origin)에만 접근 할 수 있도록 하는 보안 메커니즘입니다. 

즉, 웹 페이지 내에서 실행되는 스크립트는 다른 출처의 리소스에 직접 접근할 수 없습니다.

따라서 XSS(사이트간 스크립팅), CSRF(사이트 간 요청 위조) 와 같은 공격을 방지합니다.

 

CORS(Cross-Origin Resource Sharing)는 SOP를 우회하기 위한 메커니즘으로, 서버가 다른 출처의 리소스 접근을 허용할 수 있도록 하는 표준입니다. CORS는 HTTP헤더를 사용하여 브라우저와 서버 간의 통신을 제어합니다.

브라우저는 실제 요청을 보내기 전에 먼저 서버에게 OPTIONS 메서드를 사용하여 프리플라이트 요청을 보냅니다. 이는 실제 요청 전에 서버가 요청을 수락하는지를 확인하기 위함입니다.

서버는 응답 메세지로 특정 CORS헤더를 포함하여 요청한 브라우저에게 리소스 접근 허용 여부를 알려줍니다.

CORS 헤더는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있습니다.

 

---

REST, Restful API

REST(Representational State Transfer) 는 웹 기반 시스템으로 클라이언트와 서버 간의 통신을 위한 아키텍처 디자인 원칙의 모음입니다.

REST 의 주요 특징은 다음과 같습니다.

1. 자원(Resource): REST는 모든 것을 자원으로 보는데, 각 자원은 고유한 식별자(URI)를 가지며, 클라이언트는 이를 통해 자원에 접근합니다. 예를 들어, 사용자, 제품, 주문과 같은 것들이 될 수 있습니다.

2. 행위(Verb): 클라이언트가 자원에 대해 수행하는 행위를 HTTP 메서드로 정의합니다. 각 메서드는 약속된 의미를 갖습니다.

3. 표현(Presentation): 클라이언트와 서버 간의 상태 전달은 표준화된 데이터 포맷을 사용합니다. 

4. 상태(Stateless): REST는 상태 관리를하지 않는 상태 프로토콜입니다. 각 요청은 독립적으로 수행되며 상태를 공유하지 않습니다.

 

Restful API

Restful API 는 이런 REST 원칙을 따르는 API를 말합니다.

자원은 URI로 표현하고, HTTP 메서드를 사용하여 자원에 대한 행위를 정의합니다. 또한, 표준화된 데이터 포맷(JSON 또는 XML)을 이용하여 자원을 표현합니다.

 

 

---

프록시

프록시(Proxy)는 한국말로 '대리' 라는 뜻입니다. 즉 대신해서 무언가를 하는것 이라고 유추해 볼 수 있습니다. 

실제로 프록시 서버는 클라이언트가 자신을 통해서 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 말합니다. 

프록시 서버는 어떤 방식으로 데이터를 제공하는지에 따라 Foward Proxy 와 Reverse Proxy로 나뉩니다. 

 

포워드 프록시

포워드 프록시(Forward Proxy)는 클라이언트와 서버 사이에서 중계 역할을 하는 서버입니다. 클라이언트가 웹 서버에 직접 연결하는 대신 포워드 프록시 서버를 통해 요청을 전달하고, 포워드 프록시 서버가 대신 웹 서버와 통신을 하여 응답을 받아 클라이언트에게 전달합니다.

 

리버스 프록시

리버스 프록시는 클라이언트와 여러 서버 간의 통신을 관리하는 중간 서버입니다. 클라이언트가 요청을 보내면 리버스 포록시는 해당 요청을 여러 서버 중 하나로 전달하고, 해당 서버로부터 받은 응답을 클라이언트에게 반환합니다. 이 과정에서 클라이언트는 서버의 존재를 알지 못하며, 서버는 클라이언트로 부터 직접적인 요청을 받지 않습니다.