왜 쿠키를 거기다가 넣었니...
서버에서 kakao 로그인을 개발하는 중 redirect에 쿠키를 전달할 필요가 있었습니다.
이 포스트를 통해 redirect로 클라이언트에게 쿠키를 전달해보는 과정을 정리해보겠습니다.
앞 부분은 redirect와 쿠키를 간단하게 정리하고 있으므로 이미 아시는 내용이라면 다음 post를 보시면 됩니다.
0-1. HTTP Redirect..?
HTTP Rediect를 알아보기 위해 MDN 문서를 열심히 복붙 찾아보았습니다.
URL 리다이렉션 혹은 URL 포워딩은 페이지 단위의 실제 리소스, 폼 혹은 전체 웹 애플리케이션이 다른 URL에 위치하고 있는 상태에서 링크를 존속시키는 기술입니다. HTTP는 많은 목표를 위해 사용되는 이런 동작을 수행하기 위해 특별한 종류의 응답인 HTTP 리다이렉트를 제공합니다: 사이트 유지관리가 진행 중인 상태에서의 일시적인 리다이렉션, 사이트 아키텍쳐의 변경 이후에도 외부 링크를 동작하는 상태로 유지시키기 위한 영구적인 리다이렉션, 파일 업로드 시 진행 상태 페이지 그리고 그 외의 수많은 리다이렉션들 ...
무슨 말인지는 아직 모르겠으나 URL 포워딩이라고도 불리며, 리다이렉션이 여러 가지가 있다는 것을 알 수 있습니다.
다음은 Redirect 과정입니다.
서버가 리다이렉트라는 3xx status code를 지닌 특별한 응답을 주고, 클라이언트는 제공된 URL을 가지고 즉시 로드를 합니다. 이 과정에서 사용되는 오버헤드는 미미하다고 합니다.
위 이미지처럼 총 4번의 요청과 응답을 거치며, 클라이언트가 새로운 location에 대한 자원을 요구하는 것을 보실 수 있습니다.
다음은 간단한 리다이렉션 종류들입니다.
- 영속적인 리다이렉션
- 일시적인 리다이렉션 : Express는 default로 302로 redirect시킵니다.
- 특수한 리다이렉션
0-2. HTTP Cookie..?
쿠키 또한 MDN Cookie에서 자세한 내용을 찾아보실 수 있습니다.
HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각입니다. 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송합니다. 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용합니다. 이를 이용하면 사용자의 로그인 상태를 유지할 수 있습니다. 상태가 없는(stateless) HTTP 프로토콜에서 상태 정보를 기억시켜주기 때문입니다.
요약하자면 stateless한 HTTP를 stateful하게 만들어주는 것이 이 HTTP 쿠키입니다.
추가로 보안적으로 안전하지 않기 때문에 쿠키에는 중요한 정보를 담아서는 안된다고 합니다.
쿠키 스코프
쿠키가 보내져야 할 URL이 어디인지 Domain과 Path를 통해 정의합니다.
- Domain : 전송하게 될 도메인을 명시. 명시하지 않으면 서브 도메인은 포함하지 않는 현재 문서 도메인으로 설정
- Path : 전송하게 될 도메인의 경로를 명시.
쿠키를 위한 보안
- Secure : HTTPS 프로토콜 상의 encrypted 요청만 쿠키가 전송
- HttpOnly : XSS 공격을 막기 위해 JS Document API의 접근을 제한
- SameSite : CSRF 공격을 막기 위해 cross-site의 요청을 제어
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly특히 이 SameSite를 다시 보아야 합니다. SameSite 속성값은 다음과 같이 있습니다.
- Strict : same-site에서만 cookie가 전송. 다른 도메인의 요청은 전송되지 않음
- Lax(default) : 이미지 요청같은 cross-site는 안되고, external-site에서 origin site로 이동하는 요청은 허용.
- None : cross-site와 same-site를 허용. 단, 이 설정을 사용하려면 Secure 속성을 설정해야 함
0-3. CORS..?
CORS(Cross-Origin Resource Sharing)는 브라우저가 리소스를 로드해야 하는지 Origin을 가지고 판단하는 HTTP 헤더 기반 메커니즘을 말합니다.
또한 CORS는 ption 메서드를 통한 "preflight" 요청을 통해 자원에 접근이 가능한 지 확인을 합니다.
기본적으로 Fetch API나 XMLHttpRequest는 Same-origin policy를 따르기에 cross-origin 상태에서는 추가적인 CORS를 이용한 제어가 필요합니다.
Request
클라이언트에서는 읽기 전용의 credentials 속성을 통해 쿠키와 인증 헤더에 대해 다음과 같이 동작을 합니다.
- omit : 절대로 cookie들을 전송받거나 하지 않음
- same-origin(default) : same origin일 때만 전송
- include : cross-origin이라도 전송
Response
서버에서는 HTTP 헤더의 Access-Control-Allow-Origin으로 CORS를 설정하고
Access-Control-Allow-Credentials으로 요청의 credentials 값이 "include"일 때 브라우저에서 응답을 처리할 수 있게 합니다.
Access-Control-Allow-Origin: https://mozilla.org or *
Access-Control-Allow-Credentials: true // credential=true일 때 응답 처리 가능다음 포스트에서 현재 상황과 redirect 상황에서 여러 가지 테스트를 진행해 보겠습니다.
출처 : MDN
