Cookie란? 🍪

서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각

• 브라우저는 그 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재요청 시 저장된 데이터를 함께 전송한다.
• 쿠키는 두 요청이 동일한 브러우저에서 들어왔는지 아닌지를 판단할 때 주로 사용한다.
  • 이를 이용하면 사용자의 로그인 상태를 유지할 수 있다.
  • 상태가 없는 http 프로토콜에서 상태 정보를 기억시켜 주기 때문

쿠키의 목적

1. 세션 관리
   • 서버에 저장해야 할 로그인, 장바구니 등의 정보 관리
2. 개인화
   • 사용자 선호, 테마 등의 세팅
3. 트래킹
   • 사용자의 행동을 기록하고 분석하는 용도

특징

• http 통신을 한다면 쿠키를 주고 받을 수 있다.
• 서버에서도, 클라이언트에서도 생성할 수 있다.
• 클라이언트에서도 쿠키에 접근하고 관리할 수 있다.
• http와 https 사이에도 쿠키를 교환할 수 있다.
• 같은 도메인이라면 서로 다른 scheme일지라도 쿠키를 공유할 수 있다.

쿠키 만들기

http 요청을 수신할 때, 서버는 응답과 함께 Set-Cookie 헤더를 전송할 수 있다.

• 쿠키는 보통 브라우저에 의해 저장된다.
• 쿠키는 같은 서버에 의해 만들어진 요청들의 cookie http header 안에 포함되어 전송된다.
• 만료일과 지속시간을 명시할 수 있다.
  • 만료된 쿠키는 더 이상 보내지지 않는다.
• 특정 도메인 혹은 경로를 제한할 수 있다.

Set-Cookie: <cookie-name>=<cookie-value>

# 서버 헤더
HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

# 브라우저
GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

세션 쿠키

• 현재 세션이 끝날 때 삭제
• 브라우저는 현재 세션이 끝나는 시점을 정의
  • 재시작할 때 세션을 복원해 세션 쿠키가 무기한 존재할 수 있도록 하기도 함

영속적인 쿠키

• Expires 속성에 명시된 날짜에 삭제되거나
• Max-Age 속성에 명시도니 기간 이후에 삭제

Secure Cookie와 HttpOnly

• HTTP Only Cookie를 사용하면 client에서 javascript를 통한 쿠키 탈취문제(cross-site scripting XSS)를 예방할 수 있다.

  Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; **HttpOnly**

  • 서버 쪽에서 지속되고 있는 세션의 쿠키는 Javascript를 사용할 필요가 없기 때문에 httpOnly플래그가 설정될 것이다.
  • javascript가 아닌 네트워크를 직접 모니터링하여 쿠키를 가로챌 수 도 있다.
• 이런 정보유출을 막기 위해 HTTPS 프로토콜을 사용하여 데이터를 암호화하는 방법이 주로 사용되고 있다.
  • 브라우저는 http://로 시작되는 코드를 만나면 암호화되지 않은 상태로 쿠키를 서버로 전달한다.

    <img src="http://www.example.com/images/logo.png" />

• 쿠키를 생성할 때 secure 접미사를 사용

  • https가 아닌 통신에서는 쿠키를 전송하지 않는다.

    Set-Cookie: 쿠키명=쿠키값; path=/; **secure**

JWT

JWT 토큰(JSON Web Token)은 header, payload, signature 3가지가 .(dot)를 구분자로 하여 이룬다.

암호화나 시그니처 추가가 가능한 데이터패키지(jwt).

로그인 구현하기

https://velog.io/@yaytomato/프론트에서-안전하게-로그인-처리하기

로그인 인증 방식

1. 세션 id를 이용하는 방식
   1. 클라이어언트 로그인 ⇒ 서버 세션 생성, 세션의 id 전송 ⇒ 클라이언트에 저장 ⇒ 인증이 필요한 데이터를 가져올 때 서버에 id 전송 ⇒ 서버는 세션이 유효한지 확인
2. JWT를 이용하는 방식
   1. accessToken, refreshToken을 사용
   2. 클라이언트 로그인 ⇒ 서버가 인증정보(JWT안에 인증 정보를 담아서)를 전송 ⇒ 인증 정보 중 accessToken 과 refreshToken을 클라이언트에 저장 ⇒ accessToken 을 로그인한 유저에게만 보여줄 수 있는 정보에 접근할 때 서버에 전송 ⇒ 토큰이 유효한지 확인
      1. 실질적인 인증정보는 accessToken 인데 일정시간이 지나면 만료
         • 로컬 변수에 저장 ⇒ api 요청할 때 authorization header에 넣어서 보내준다.
      2. 이때 refreshToken을 이용해 로그인을 지속적으로 유지
         • refreshToken을 서버에 전송 ⇒ 서버는 새로운 accessToken 을 발급

보안

• XSS
  • 클라이언트 브라우저에 js를 삽압해 실행하는 공격
    • 공격자의 코드가 내 사이트의 로직인 척 행동할 수 있다.
• CSRF
  • 다른 사이트에서 우리 사이트의 api 콜을 요청해 실행하는 공격
    • 로그인한 척 계좌 비밀번호를 바꾸거가 송금을 보낸다.
• 인증정보를 localStorage나 cookie에 저장하는 방식은 보안에 취약하다.

리액트에 적용하기

1. secure 쿠키 전달을 위해서 프론트와 로그인 api를 제공할 백엔드는 같은 도메인을 공유해야한다.
2. 백엔드는 http 응답 Set-Cookie헤더에 refreshToken 값을 설정하고 accessToken을 JSON payload에 담아 보내준다.
3. root에서 axios에 withCredentials true 로 설정한다.

    axios.defaults.baseURL = "https://www.abc.com";
    axios.defaults.withCredentials = true;

4. 로그인 api 요청

   onLogin = (email, password) => {
   	const data = {
   		email,
   		password,
   	};
   	axios.post('/login', data).then(response => {
   		const { accessToken } = response.data;
   
   		// API 요청하는 콜마다 헤더에 accessToken 담아 보내도록 설정
   		axios.defaults.headers.common['Authorization'] = `Bearer ${accessToken}`;
   
   		// accessToken을 localStorage, cookie 등에 저장하지 않는다!
   
   	}).catch(error => {
   		// ... 에러 처리
   	});
   }

5. 로그인 만료, 로그인 연장 처리

   유저가 모르게 서버에서 새로운 accessToken을 받아와서 조용히 자동으로 로그인이 연장되도록 할 수 있다. (Silent Refresh)

  1. 일반적인 로그인 처리
  2. accssToken이 만료됐을 때 로그인 연장 처리
      - 401 error
  3. 페이지 reload 될 때 로그인 연장 처리

---

Reference

• https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies
• https://nsinc.tistory.com/121
• https://velog.io/@yaytomato/프론트에서-안전하게-로그인-처리하기