JWT vs Session & Cookie 인증 인가 방식?! (feat. 브라우저에서의 쿠키)

🍎 배경

현재 사이드 프로젝트로 커뮤니티 앱 개발을 진행 중이다. 기존의 jwt 토큰 기반 인증/인가 방식에서 Session Cookie 기반의 방식으로 변경하게 되었다. 구현해야 할 기능과 각 방식의 장단점을 고려하여 선택을 내렸고, 그 과정 얻은 지식과 결정 과정을 공유하고자 한다.

 

 

🍎 읽기 전 용어 정리

간단하게 짚고 넘어가면 이해에 도움이 될 것 같다. 

인증 == Authentication ≒ 로그인

인가 == Authorization ≒ 로그인된 상태에서 일어나는 일을 허락해 주는 것

 

 

 

🍎 Session Cookie 인증/인가 방식

1. 사용자가 로그인을 시도한다.
2. 사용자의 실제 인증 정보를 서버 측 세션 저장소에 저장한다.
3. 사용자에게 저장된 세션 정보의 식별자인 session id를 발급한다.
4. 발급한 session id를 브라우저에 쿠키 형태로 저장한다.
5. 클라이언트에서 추가로 설정해줄 필요 없이, 브라우저에서 서버로 보내는 요청마다 http cookie 헤더에 session id가 서버로 함께 전송된다.
6. session id가 존재한다면, 인증된 사용자로 판별한다.

 

 

🍎 Session Cookie 방식의 문제점

1억 명의 유저가 메모리 상에 올라와 있다면 전달받은 session id로 유저를 식별하는 과정은 서버에 큰 무리를 줄 수 있다. 서비스의 규모가 생기고, 요청을 분산 처리하기 위해 여러 개의 서버를 두고 로드 밸런싱해야 하는 상황이 온다면? 어떤 로그인 요청은 서버 1번으로, 내 프로필 접속 요청은 서버 3번으로 가게 되면, 서버 1번 요청에서 생성한 쿠키 정보를 서버 3번이 가지고 있어야 세션이 유지되는 문제가 있을 수 있다.

이러한 비용 문제를 해결하기 위해 등장한 인가 방식이 바로 뚜둥 JWT 토큰 방식이다!

(*브라우저에서의 쿠키가 뭔가요? 하단 🍎 (브라우저에서의) 쿠키 섹션을 먼저 읽어주세요!)

 

 

 

🍎 JWT 인증/인가 방식

1. 사용자가 로그인을 시도한다.
2. 사용자에게 다음 정보가 인코딩된 형태의 jwt 토큰을 전달한다. (SECRET KEY는 서버에 감춰놓은 상태)
   1. header > type (토큰 타입), alg (하단 verify signature를 만드는 데 사용될 알고리즘)
   2. payload: 해당 서비스가 토큰으로 공개하기 원하는 내용
   3. verify signature
3. 클라이언트에서 jwt 토큰을 헤더에 담아 요청을 전송한다.
4. 서버에 감춰놓은 SECRET KEY와 함께, header & payload 값을 계산해 verify signature와 일치하는지 확인한다. 불일치하는 경우, 누군가에 의해 토큰이 조작되었다고 본다.

 

 

🍎 JWT 인증/인가 방식의 보완: Access, Refresh 토큰 발급

JWT 방식은 유저가 토큰을 잃어버리면 통제권을 잃고, 만료 기간을 너무 짧게 잡으면 매번 로그인해야 하는 불편함이 있다. 이를 보완하기 위해 등장한 방식이다.

1. 사용자가 로그인을 시도한다.
2. 서버에서 클라이언트로 access 토큰과, refresh 토큰을 전달한다. (*access 토큰: 로그인 후 몇 분 ~시간 동안 유효한 토큰, refresh 토큰: 발급 후 통상 2주간 보존된다. access 토큰을 재발급받는 데 사용된다. )
3. refresh 토큰을 구분할 수 있는 값을 DB에 저장한다.
4. 클라이언트는 access 토큰이 수명을 다하면 refresh 토큰을 전달한다.
5. refresh 토큰을 대조하여 맞다면 새로운 access 토큰을 발급해준다.

중간에 refresh 토큰이 탈취되었다면, 해당 refresh 토큰을 전달받았을 때 access 토큰 발급을 거부한다!

이렇게 서버 측에서 로그인을 통제할 수 있고,

서버에는 큰 무리가 가지 않으면서 매번 로그인해야 하는 불편함을 완화시킬 수 있다.

 

 

 

🍎 그런데 왜 Session Cookie 방식 고르셨나요?!

 

포기해야 하는 장점과 감수해야 하는 단점이 있음에도 불구하고 세션 쿠키 방식을 도입해야만 했던 이유는, 비용적인 트레이드오프만을 고려했다기보다 바로 다음 기능을 구현하기 위함이었다…

 

1. 멀티 로그인 금지
   PC에서 로그인되었다면 모바일에서 로그아웃되도록 멀티 사용을 금지하여야했고, 한 세션이 생성되면 유저 Session ID 정보 일부를 저장하고 있는 또 다른 세션을 삭제하여 해당 기능을 구현할 수 있었다. JWT 토큰은 이미 발급받은 유저가 가지고 있는 상태로 SECRET KEY가 변하지 않는 이상 이미 로그인한 상태를 무력화 시킬 수 없다.
2. remember me 기능
   웹앱 내 사용자가 로그인한 상태를 유지할 수 있도록 해당 옵션 선택 시 쿠키가 만료되는 시점을 미래로 설정하여 stay sign in 기능을 구현할 수 있었다. JWT 인가 방식의 경우 토큰의 수명을 늘려 remember me 기능을 구현은 가능하지만, 인증 여부를 판별하는 토큰은 유저가 갖고 있기에 해당 토큰의 수명 동안 서버 측에서 통제할 수 없게 된다. 이는 보안상의 취약성을 의미한다.

 

 

🍎 [추가] (브라우저에서의) 쿠키

쿠키는 서로 다른 맥락에서 다른 대상을 지칭하는 용어로 해석될 수 있기에… 여기서는 ‘브라우저에서의’ 쿠키만을 다뤄보겠다.

 

쿠키 특징

• 브라우저에 저장되는 작은 문자열
  • 4KB를 넘을 수 없음
  • key: value; 문자열로 저장되는데 약 20여 개로 제한
  • e.g. name=value; name2=value2; name3=value3; 형태로 저장
• 웹 서버에서 만들어짐. 응답 헤더에 set-cookie 내용을 넣어 전달
• 전달받은 브라우저가 자체적으로 저장 후 요청마다 헤더에 넣어 저장한다

사용처

• 클라이언트 식별 용도로 사용함
• 로그인 / 장바구니 / 개인화 (사용자 맞춤 테마, 언어 등) / 트래킹 (사용자 행동 기록 및 분석)

쿠키 추가 및 사용 방법

document.cookie = "<<쿠키 문자열>>" // --- 쿠키 추가
document.cookie // -- 쿠키 읽기 

주의

• 일관된 형식을 유지하기 위해 반드시 encodeURIComponent를 사용한다.

let name = "my name";
let value = "John Smith"

document.cookie = encodeURIComponent(name) + '=' + encodeURIComponent(value); // -- 공백 인코딩 처리 

alert(document.cookie); // ...; my%20name=John%20Smith

쿠키 옵션? 세팅 방법?

• "/posting" 경로 혹은 하위 경로에 있는 페이지만 쿠키에 접근하게 만들고 싶다면? <<path=/하위경로>>
  path=/posting

• 쿠키에 클라이언트 배포 url (example.com)만 접근가능하게 하고 싶다면?
  domain=example.com

• 쿠키의 유효일자 혹은 만료 기간을 지정해주고 싶다면?
  expires | max-age 옵션 확인 (단, 반드시 toUTCString 포맷 사용)

// 지금으로부터 하루 후
let date = new Date(Date.now() + 86400e3);
date = date.toUTCString();
document.cookie = "user=John; expires=" + date;

• https로 통신하는 경우에만 쿠기를 전송하고 싶다면?
  secure

• 사이트 외부에서 쿠키에 접근하려는 시도를 차단하려면? (XSRF 공격을 막기 위해)
  samesite=strict 옵션을 주어 같은 사이트 내부에서만 쿠키에 접근할 수 있도록 제한.

• 클라이언트 측에서 document.cookie로 쿠키를 꺼내 보거나 사용할 수 없게 하고 싶다면?
  httpOnly

 

 

🍎 Session Cookie 방식 - 브라우저 처리 코드

프로젝트 내 사용하는 모든 api 요청의 에러를 처리하는 유틸 함수이다.

사용자가 인가받은 유저인지 판별하는 시점은 서버 측 요청에 대한 응답 상태코드가 401 (인증 인가 코드가 잘못된 경우) 일 때이다. 유틸 함수에 상태 코드 별 처리 로직을 추가하여 일괄 적용시킬 수 있다. 

type Callback<T> = (...args: any[]) => Promise<T>;

export const methodFormat = <T>(callback: Callback<T>) => {
  const method = async (
    ...args: any[]
  ): Promise<{ ok: boolean; data?: T; message?: string }> => {
    try {
      const data = await callback(...args);
      return {
        ok: true,
        data,
      };
    } catch (error: any) {
      if (error.response.status === 401) { // -- 401 에러인 경우 
        window.href = "/login" // -- login 페이지로 redirect
      } 
      return {
        ok: false,
        message: error.message,
      };
    }
  };
  return method;
};

 

 

🍎 한 줄 느낌

나온 지 20년이 지난 세션 쿠키 방식을 아직까지 모든 웹의 90%가 사용하고 있다고 한다. 실서비스 중 JWT만으로 인가를 허용하는 경우도 많지 않다고 한다. JWT가 정말 좋은 방식이면 너도 나도 써야 하지 않을까  하는 생각이 들었다 

끄-읕

 

 

 

 

 

참고자료:

https://ko.javascript.info/cookie

https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

https://www.youtube.com/watch?v=1QiOXWEbqYQ