Cookie란? 🍪

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

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

쿠키를 언제 사용하면 좋을까

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

쿠키는 어떤 특징이 있을까?

1. http 통신을 한다면 쿠키를 주고 받을 수 있다.
2. 같은 도메인이라면 header 에 자동으로 쿠키가 담겨서 보내진다.
   • 같은 도메인이라면 서로 다른 scheme일지라도 쿠키를 공유할 수 있다.
3. 서버에서도, 클라이언트에서도 생성/접근/관리할 수 있다.
4. http와 https 사이에도 쿠키를 교환할 수 있다.
   • secure 접미사를 사용하면 https 에서만 쿠키를 전송하도록 설정할 수 있다.

쿠키를 만들어보자!

• HTTP 요청을 수신할 때, 서버는 응답과 함께 Set-Cookie header 를 전송할 수 있다.
• 쿠키는 보통 브라우저에 의해 저장된다.
• 쿠키는 같은 서버에 의해 만들어진 요청들의 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

이제 서버로 전송되는 모든 요청과 함께, 브라우저는 Cookie header 를 사용하여 서버로 이전에 저장했던 모든 쿠키들을 회신한다.

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

쿠키의 라이프타임 😇

쿠키의 라이프타임은 두 가지 방법으로 정의할 수 있다.

세션 쿠키 (session cookie)

• Expires(유효 일자)나 Max-Age(만료 기간) 옵션이 지정되어있지 않아서 브라우저가 닫힐 때 함께 삭제된다.
• 재시작할 때 세션을 복원해 세션 쿠키가 무기한 존재할 수 있도록 하기도 한다.

영속적인 쿠키

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

• Expires 속성에 명시된 날짜에 삭제되거나,Max-Age 속성에 명시된 기간 이후에 삭제된다.
• 브라우저를 닫아도 쿠키가 삭제되지 않는다.

이제 로그인을 구현하기 전에 보안에 대해 알아보자.

보안이 중요한 이유

1. XSS
   • 클라이언트 브라우저에 JavaScript 를 삽입해 실행하는 공격
     • 공격자의 코드가 내 사이트의 로직인 척 행동할 수 있다.
2. CSRF
   • 다른 사이트에서 우리 사이트의 api 콜을 요청해 실행하는 공격
     • 로그인한 척 계좌 비밀번호를 바꾸거가 송금을 보낸다.

위 처럼 쿠키는 Client에서 JavaScript 로 조회할 수 있기 때문에 보안 설정을 하지 않은 채로 통신을 해버리면 쿠키를 가로챌 수 있다는 문제가 있다.
그렇기 때문에 클라이언트와 서버에서 여러가지 방법을 이용해서 이런 공격들은 방어해야 한다.
그 방법들에 대해서 알아보자.

HttpOnly 와 Secure Cookie

HttpOnly

HttpOnly 쿠키 속성을 사용하면 JavaScript를 통해 쿠키에 접근할 수 없게 되어, 악성 스크립트를 통해 쿠키 값에 접근하는 것을 막아준다.
HTTP Only Cookie 를 활성화 하기 위해서는 쿠키를 생성할 때, 가장 마지막에 HttpOnly 라는 접미사를 추가하면 된다.

Secure Cookie

HTTP Only Cookie를 사용하면 Client에서 Javascript를 통한 쿠키 탈취문제를 예방할 수 있다.
하지만 Javascript가 아닌 네트워크를 직접 감청하여 쿠키를 가로챌 수도 있다.
그렇기 때문에 이러한 정보 유출들을 막기 위해, HTTPS 프로토콜을 사용하여 데이터를 암호화하여 서버에 넘겨주게 되면, 해커들이 쿠키를 탈취해도 암호화가 되어있어 정보를 알아낼 수 없다.

이를 위해 Secure 접미사를 사용해서 쿠키를 생성하게 되면 브라우저는 HTTPS 가 아닌 통신에서는 쿠키를 전송하지 않는다.

HttpOnly 속성과 Secure 속성을 사용해 생성한 쿠키의 예시이다.

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

로그인 🔐

인증 방식

로그인 인증 방식에는 두 가지 방법이 있다.

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

우리는 이중에서 토큰(JWT) 를 이용한 방식으로 로그인을 구현하기로 해서 JWT 에 대해서 알아봤다.

JWT (JSON Web Token) 📦

JSON Web Token 이란?

JSON Web Token 이란 JSON 객체를 사용하여 정보를 안전하게 전달하기 위한 컴팩트하고 자체적인 방법을 JSON 객체로 정의하는 개방형 표준이다.

암호화나 시그니처 추가가 가능한 데이터패키지라고도 할 수 있다.

이러한 JWT 를 언제 사용할 수 있을까?

1. Authorization
   • 사용자가 로그인하면, 이후 API 요청들은 JWT를 포함하고, 사용자는 해당 토큰으로 허용된 경로, 서비스 및 리소스에 액세스할 수 있다.
2. 정보 교환
   • JWT는 공개 키와 개인 키 쌍을 사용하여 서명할 수 있기 때문에 보낸 사람이 자신이 누구인지 확인할 수 있다.
   • 헤더와 페이로드를 사용하여 서명을 계산하므로 내용이 조작되지 않았는지 확인할 수도 있다.

JSON Web Token 구조가 어떻게 될까?

JSON Web Token 은 점(.)으로 구분된 세 부분으로 구성되어 있다.

- Header
- Payload
- Signature

이것들을 하나로 합치면 하나의 JWT 가 되는데, 이는 점으로 구분된 3개의 Base64-URL 문자열로, 일반적으로 다음처럼 생기게 된다.

	xxxxx.yyyyy.zzzzz

이렇게 생성된 JWT는
jwt.io Debugger 를 사용해서 아래처럼 decode, verify, 및 생성 할 수 있다.

이제 이 JWT 를 사용해서 리액트에서 로그인 기능을 구현해보자.

리액트에서 로그인 구현하기

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

위 블로그를 참고해서 로그인 기능을 구현했다.
백엔드와 맞춰본 로그인 기능 스펙은 다음과 같다.

1. refreshToken 은 사용하지 않는다.
2. Cookie 를 이용해서 accessToken 을 관리한다.
   • local일 경우에만 개발 편의성을 위해서 localStorage 를 이용하여 token 을 관리한다.
3. Secure Cookie 와 HTTP Only Cookie 를 이용하여 보안을 높인다.
4. Secure Cookie 전달을 위해서 프론트와 로그인 API를 제공할 백엔드는 같은 도메인을 공유한다.
5. 백엔드는 HTTP 응답 Set-Cookie 헤더에 accessToken 값을 담아서 보내준다.

이제 프론트에서 해줘야 하는 일들을 살펴보자.

1. 다른 도메인들끼리 자격 인증 정보를 공유할 수 있도록 옵션을 설정한다. (withCredentials = true)

   만약 클라이언트 서버와 API 서버가 Host 는 같지만, Port 가 다르다고 가정해보자.

    - 클라이언트 서버 : http://localhost:3000
     - API 서버 : http://localhost:8080

   아무 설정도 하지 않은 채 axios 로 로그인 요청을 서버에 보낸다면 CORS(Cross-origin-resource-sharing 교차 출처 리소스 공유) 에러와 함께 브라우저의 Cookie 에는 아무것도 담겨있지 않을 것이다.

   왜 이런일이 일어나는 걸까?

   여기서 우선 credential 이란, 쿠키나 Authorization 인증 헤더 등을 내포하는 자격 인증 정보를 말한다.

   그런데 브라우저는 기본적으로 쿠키와 같은 인증과 관련된 데이터를 함부로 request/response header 에 담지 않도록 되어있다.
   그래서 만약 다른 도메인(Cross Origin)끼리 쿠키와 같은 자격 인증정보를 공유(resource sharing) 하고 싶다면, 클라이언트와 서버에서 수동으로 이를 허용한다는 옵션을 각각 추가해야 한다.

   클라이언트에서도 withCredentials 옵션을 설정해줘야 하고,
   서버에서도 Access-Control-Allow-Credentials 헤더를 설정해주면 된다.

   우리는 axios 를 사용하고 있으므로, aixos 공식 docs 를 통해 withCredentials 옵션을 설정해보자.
   withCredentials 의 주석을 보면 자격 증명(credential)을 사용하여 사이트 간 접근 제어를 해야 하는지 여부를 나타낸다는 것을 알 수 있다.
   이제 전역 Axios Config 에 이 withCredentials 옵션을 true 로 설정해주면 된다.

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

2. 로그인 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}`;
        // local 이 아닌 환경에서는 프론트와 백엔드가 같은 도메인을 사용하고 있다면 
        // token 이 Cookie 에 담겨 보내지기 때문에 
        // token 이 만료되기 전까지는 추가적인 설정없이 다른 API를 사용할 수 있다.
        
        // local 일 경우에만 storage 에 token 을 저장해서 
        // API 통신마다 헤더에 token 을 담아 보내도록 설정한다.
      }).catch(error => {
        // ... 에러 처리
        // ex) 401 unauthorized 일 경우 로그인 페이지로 이동한다.
      });
    }

   위에 적어놓은 바와 같이
   local 이 아닌 환경에서는 프론트와 백엔드가 같은 도메인을 사용하고 있다면
   token 이 Cookie 에 담겨 보내지기 때문에 token 이 만료되기 전까지는 추가적인 설정없이 다른 API를 사용할 수 있다.
   만약 token 이 만료된 후의 처리를 하고 싶다면 catch 절에서 401 unauthorized 일 경우 로그인 페이지로 이동하도록 처리할 수 있을 것이다.

   또한 local 일 경우에만 개발 편의성을 위해 storage 에 token 을 저장해서 API 통신마다 헤더에 token 을 담아 보내도록 설정하였다.
   이렇게 처리하면 새로고침이 되어도 token 이 날아가는 일은 없을 것이다...!

3. 로그인 만료 및 로그인 연장 처리를 해준다.

   로그인 정보를 담고있는 token 이 만료되었을 경우 처리할 수 있는 방법은 여러가지가 있을 것이다.
   우리는 API 통신 시 401 unauthorized 일 경우 로그인 페이지로 이동하도록 처리하였다.

   우리가 사용한 방법 대신
   유저가 모르게 서버에서 새로운 token 을 받아와서 조용히 자동으로 로그인이 연장되도록 하는 방법을 많은 웹사이트에서 사용하곤 하는데,
   이를 Silent Refresh 라고 한다.

---

참고

• HTTP 쿠키 - HTTP | MDN
• [Web] HTTP Only와 Secure Cookie 이해하기
• 🍪 프론트에서 안전하게 로그인 처리하기 (ft. React)
• 01. 시큐리티 - HTTP Only 와 Secure Cookie
• jwt.io
• Axios
• 🍪 CORS 쿠키 전송하기 (withCredentials 옵션)