[React] JWT 토큰🔐

로그인 시 사용자의 로그인 정보를 JWT을 통해서 클라이언트에서 관리하기로 하였다.

로그인 시 서버로부터 응답 바디를 통해 액세스 토큰을 전달받고, 응답 헤더(Set-Cookie) 를 통해 쿠키에 리프레쉬 토큰을 담아 전달받았다.

그 이유는 JWT는 기본적으로 Stateless한 특성을 가지기 때문에 서버가 별도의 상태를 유지하지 않는데 이는 토큰이 탈취될 경우 이를 무효화하거나 변경 상태를 반영하기 어렵다는 문제점이 있습니다. 이런 문제점을 보안하기 위해 적절하게 trade-off하여 일부분을 Stateful하게 관리하여 보안성을 높였습니다.

JWT를 Stateful하게 관리하면 서버가 토큰의 유효성을 주기적으로 검증하고, 필요 시 토큰을 무효화 할 수 있습니다. 예를 들면, 사용자가 로그아웃하거나 비밀번호를 변경할 때 해당 토큰을 즉시 폐기할 수 있습니다.

JWT 토큰

JWT(Json Web Token) 웹토큰이라 부르며, 전자 서명된 URL-safe의 JSON입니다.

JWT 토큰 인증방식은 비밀키(개인키 or 대칭키)로 암호화하며 이는 JWT 토큰을 사용해서 클라이언트와 서버 간에 통신을 안전하게 해줍니다.

JWT는 .을 기준으로 header, payload, signature로 세 파트로 나뉩니다.

1. 헤더(Header)에는 JWT를 어떻게 검증(서명 생성)하는지에 대한 내용인 토큰의 타입, 암호화 알고리즘이 어떤 알고리즘인지에 대한 정보가 들어있습니다.

2. 페이로드(Payload)에는 토큰이 전달하는 클레임 or 데이터가 포함됩니다. 이는 key - value의 한 쌍으로 구성되어 있으며 여러 개의 클레임을 담을 수 있고, 클레임을 public 혹은 private할건지 등록할 것인지 결정할 수 있습니다.

3. 서명(Signature)은 헤더(header)와 페이로드(Paylaod)를 합친 문자열을 서명한 값이며 전송 중에 토큰이 변조되지 않았는지 확인하는 데 사용됩니다.

JWT 토큰의 구조적인 문제점

JWT 토큰은 큰 문제점은 탈취 당했을 때 서버가 탈취한 사람을 신뢰할만한 사람인지 구별을 못해서 탈취자가 신뢰 가능한 사람인 것처럼 인증할 수 있기 때문에 주요 문제점으로 손 꼽힙니다.

그래서 유효기간을 짧게 두면 사용자가 로그인을 자주해야하는 문제점이 생겨서 사용자 경험적인 측면에서 좋지 않고, 기간을 길게 두면 보안상 탈취 위험이 높아집니다.

JWT 토큰 구현 설계 시나리오

그래서 구조적인 문제점을 해결하기 위해 Access Token과 Refresh Token로 JWT 토큰을 2개로 둡니다.

보통 Access Token의 유효기간은 짧게, Refresh Token의 유효기간은 길게 설정해주어서 평소에 API 통신할 때는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되어 갱신될 때만 사용하게 해줍니다.

브라우저는 액세스 토큰은 로컬 스토리지에 저장하고, 리프레시 토큰은 쿠키에 저장하는 이유는 액세스는 짧게, 리프레시는 길게 저장하여 보안 효율을 올려주기 때문입니다.(또한 로컬스토리지에 저장하는 것보다 쿠키에 저장하는것이 상대적으로 보안성이 뛰어나고 http-only를 리프레시에 걸어주면 http 통신을 시도할 때 서버에 리프레시 토큰을 전송해주기 때문에 클라이언트상에서 js 접근을 방지할 수 있습니다.)

이때 액세스 토큰은 API호출이나 새고고침, 페이지 이동 시 토큰 만료 여부를 체크해서 유효하다면 실행되도록하고 리프레시 토큰은 액세스 토큰을 재발급해주는 용도로 사용한다.

구현 간에 JWT 토큰 잘못된 이해와 사용

리프레시 토큰이 유효하다면 액세스 토큰을 재발급해주는 역할이기 때문에 서버에서 정해둔 시간이 다되면 쿠키에서 사라지기 때문에 그걸 가지고 로그아웃 시켰다.

이때 이렇게 이해한 이유는 리프레시 토큰이 만료되면 액세스 토큰을 재발급 못해주기 때문에 리프레시를 기준으로 로그인, 로그아웃 상태를 구현하면 되겠구나라고 생각을 했고 또 다른 이유로는 리프레시 토큰을 쿠키에 저장했을 때 리프레시 토큰이 서버에서 제공한 리프레시 토큰이 시간이 만료되면 쿠키에서 삭제되기 때문에 아! 리프레시 토큰이 만료되서 쿠키에서 삭제되면 자동 로그아웃 기능을 쉽게 구현하면 되겠구나! 이렇게 이해했다. 하지만 리프레시 토큰은 오로지 액세스 토큰을 재발급 해주는 용도이기 때문에 그렇게 하면 안된다고 한다.

또한 쿠키에 리프레시 토큰을 저장하게 되면 생기는 문제점으로
1. 로컬 환경에서 쿠키의 데이터를 서버로 크롬 보안 정책 때문에 전송이 안된다.
2. Cross Site Scripting(XSS) 공격에 취약하다.

그래서 서버에서는 쿠키에 js로 접근하지 못하게하는 http-only를 걸어줘서 클라이언트에서 http 요청이 발생하면 자동으로 서버로 쿠키 값을 전달하도록하여 로컬 환경에서 쿠키 값을 전송할 수 있고, 또한 XSS 공격에 대비할 수 있는 장점이 있다.

이로써 브라우저에서는 쿠키에 접근이 불가능해졌기 때문에 더욱 더 로그인 상태 관리를 리프레시 토큰을 가지고 구현하면 안되게 되었습니다.

그런데 로컬 환경의 한계 때문에 쿠키를 유지하지 못하는 에러들은 발생되었으며 다음과 같습니다.

• SameStie = None, secure = true를 사용했는데 https 환경이 아니라서 발생한 에러입니다. 이때 https 환경으로 바꿔줘야하지만 로컬 환경의 기본값은 http이기 때문에 쿠키를 클라이언트 상에서 보관하지 못하고 사라지는 현상이 발생(그래서 도메인 구매하여 배포 과정을 통해 해당 문제 해결)

• 도메인이 일치하지 않아 발생한 에러

• 해당 에러는 위의 에러들을 해결하기 위해 배포를 하여 배포 도메인과 서버 도메인을 일치시켜서 발생한 로컬 환경에서의 에러

SameSite를 설정하는 이유

CSRF 공격
Cross Site Request Forgery (이하 CSRF) 공격은 웹사이트 상에서의 요청을 위조하는 것을 의미합니다.

이것을 막는 옵션으로 SameSite라는 옵션이 총 3가지가 존재합니다.

Lax : 크로스 사이트 요청을 허용 하지만 get 요청만 사용가능하는 디폴트 값입니다.(post는 사용 불가능) - 기본값
(다른 도메인에서 요청할 때 쿠키가 자동 전송되지 않습니다.)
None : 도메인 검증 X 어디서든 사용 가능하고 secure = ture 필수(해당 오류를 해결하는 과정에서 https 필요)
Strict : 같은 도메인에서만 쿠키 전송 가능

결론

액세스 토큰을 기준으로 로그인 상태를 관리해서 만료 시간 1분 전에 재발급을 받고 리프레시 토큰이 만료되면 액세스 토큰을 재발급 못 받기 때문에 로그아웃이 되는 형식으로 구현할려고 했지만... 액세스 토큰 재발급 api를 호출 할 때 액세스 토큰의 만료시간이 남아 있다면 토큰 중복과 보안상에 이유로 서버에서 막아놨기 때문에 재발급이 안되고 401에러가 발생했습니다. 또한 만료가 된 후 재발급 api를 호출할려고 하니 로그아웃 기능 로직 때문에 로그아웃이 발생하는 단점이 발생했다.

결국 돌고 돌아서 로그인 상태 관리는 리프레시 토큰으로 해줘야 깔끔한거 같습니다..(http-only를 사용하면 js로 접근이 불가능하다고 해서 쿠키에서 사라지는 줄 알았는데 이는 sameSite=none, secure=false 설정으로 인해 쿠키 차단이 발생해서 쿠키에서 사라지는 오류가 발생했던 것이다. 그래서 hyyp-only를 사용한 리프레시 토큰으로 로그인 상태 관리를 못하는 줄로 착각을 했습니다...)

결국 많은 시행착오를 겪어서 해결했을 때 깨달은 점으로는 일단 이론상으로 액세스 토큰 재발급을 api를 호출 할 때마다 만료되었는지 확인 후 만료가 안되었다면 호출한 api 수행 or 만료가 되었다면 재발급 api를 호출하여 새로운 액세스 토큰을 발급하는 식으로 생각했습니다. 그렇게한다면 기존에 있던 액세스 토큰이 만료되고 api를 호출하는 작업이 이루어지는 사이 시간이 붕 떠서 로그아웃이 될거라고 생각을 했습니다.

하지만 액세스 토큰 만료시간과 현재시간을 비교해서 만료가 되면 즉시 액세스 토큰을 재발급하도록 구현해보니 생각보다 빠르게 새로운 액세스 토큰과 만료시간을 제공해주었습니다.

완성 코드

import { useEffect, useCallback } from "react";
import { useRecoilState } from "recoil";
import { userState, isLoggedInState } from "@/recoil/userState";
import { useLogout } from "@/hooks/useLogout";
import { basicAxios } from "@/api/axios";
import axios from "axios";

const useAuth = () => {
  const [user] = useRecoilState(userState);
  const [isLoggedIn] = useRecoilState(isLoggedInState);
  const { logout } = useLogout();

  const refreshAccessToken = useCallback(async () => {
    try {
      console.log("Starting token refresh...");
      const response = await basicAxios.post("/users/refresh");
      console.log("Refresh response:", response);

      const { accessToken } = response.data.result;
      const { value, expiration } = accessToken;

      console.log("Access Token: ", { value, expiration });
      localStorage.setItem("AccessToken", value);
      localStorage.setItem(
        "AccessTokenExpiration",
        new Date(expiration).getTime().toString()
      );

      return value;
    } catch (error) {
      console.error("액세스 토큰 갱신 실패:", error);

      if (axios.isAxiosError(error)) {
        const response = error.response;
        console.log("Axios 오류 응답:", response);

        if (response?.status === 401) {
          console.log("Unauthorized 오류 응답:", response.data);
        }
      }

      return null;
    }
  }, []);

  const checkAndRefreshToken = useCallback(async () => {
    const accessToken = localStorage.getItem("AccessToken");
    const accessTokenExpiration = localStorage.getItem("AccessTokenExpiration");

    if (accessToken && accessTokenExpiration) {
      const now = new Date().getTime();
      const expirationTime = Number(accessTokenExpiration);

      if (now >= expirationTime) {
        // 액세스 토큰이 만료되었습니다. 새로고침하세요.
        const newAccessToken = await refreshAccessToken();
        if (newAccessToken) {
          // 새로운 액세스 토큰 및 만료 시간으로 localStorage 업데이트
          localStorage.setItem("AccessToken", newAccessToken);
          // axios 인스턴스가 Authorization 헤더를 사용하는 경우 헤더 업데이트 -> 새로운 액세스 토큰 헤더에 저장
          basicAxios.defaults.headers.common[
            "Authorization"
          ] = `Bearer ${newAccessToken}`;
        } else {
          // 토큰 새로 고침 실패 처리, 사용자 로그아웃 가능
          logout(); // 이 부분에서 토큰 갱신 실패 시 로그아웃을 호출합니다
        }
      } else {
        // 액세스 토큰은 여전히 유효합니다. 필요한 경우 axios 헤더를 업데이트하세요.
        basicAxios.defaults.headers.common[
          "Authorization"
        ] = `Bearer ${accessToken}`;
      }
    } else {
      // 액세스 토큰을 찾을 수 없습니다. 사용자가 로그아웃될 수 있습니다.
      logout();
    }
  }, [refreshAccessToken, logout]);

  useEffect(() => {
    checkAndRefreshToken();
  }, [checkAndRefreshToken]);

  return { user, isLoggedIn, checkAndRefreshToken };
};

export default useAuth;

현재 로직은 리프레시 토큰 15분안에 5분 짜리 액세스 토큰 3번 재발급 받고 4번 째 액세스 토큰 재발급 api 요청할 때 리프레시 토큰이 없기 때문에 로컬에서 액세스 토큰이 만료되면서 로그아웃이 되고 있습니다.

JWT 토큰 구현 간에 고려한 보안 문제들

제일 안전한 방법
: Refresh Token은 http only, secure Cookie에 저장 & Access Token은 로컬 변수에 저장

=> CSRF 공격 : Cookie에 Access Token이 없기에 인증 불가 상태. http only secure 쿠키 특성상 refresh token 자체를 털 방법이 없음

=> XSS 공격 : Access Token은 로컬 변수에 저장되어 있기에 탈취 불가

=> Access Token을 만료시간을 짧게 가져감으로써 그나마 취약한 XSS를 좀 더 방어할 수 있음

마무리

추가적으로 프로젝트 진행 간에 백엔드와 프론트 사이의 쿠키 전송 문제들을 다뤄볼려고 한다.

JWT 리프레시 토큰 쿠키 전송 과정에서 겪은 이슈

문제 발생 1

SameSite 기본 속성 값은 Lax이다. 그래서 동일 사이트에서만 쿠키를 전송하도록 제한하여 CSRF 공격을 방지하기 때문에 프론트로 쿠키 전송 불가능한 상황이 발생하였다. 그 이유는 프론트 서버와 API 백엔드 서버의 도메인이 다르기 때문이다.

문제 발생 2

하지만 SameSite=None일 경우 Secure 속성을 true로 지정해야 한다.

이 설정은 해당 쿠키가 HTTPS 프로토콜을 통해서만 전송되도록 한다. 따라서 HTTP를 사용하는 연결에서는 이 쿠키가 전송되지 않는다.

문제 발생 3

SameSite=None, Secure; 설정을 위해 가비아에서 도메인을 구매하고 SSL 인증서를 발급하여 HTTPS 프로토콜을 적용하였다. 하지만 그럼에도 API를 통해 쿠키를 받아오면 거부되고 있었다.

"refresh_token" 쿠키는 외부 쿠키이고 "Partitioned" 속성이 없기 때문에 곧 거부됩니다.

SameSite=None; Secure 설정을 가진 쿠키들이 크로스 사이트(다른 도메인 간) 컨텍스트에서 작동하는 경우, 이들을 써드파티 쿠키로 취급하고, 크롬에서 이러한 쿠키의 사용을 차단한다고 한다. 이는 사용자의 개인정보 보호를 강화하고, 크로스 사이트 추적을 방지하기 위한 조치라고 한다.

프론트 엔드 서버의 주소는 www.fordogs.store이고 백엔드 API 서버의 주소는 api.fordogs.store 이다. 같은 도메인임에도 외부 쿠키로 취급되는 이유를 확인해보니 domain 속성 문제였다.

domain 속성에 아무 값도 넣지 않았다면, 쿠키를 설정한 도메인에서만 쿠키에 접근할 수 있다. 서브 도메인에서도 쿠키에 접근할 수 없다. 때문에 domain 속성에 루트 도메인인 domain=fordogs.store를 명시적으로 설정하여 접근할 수 있도록 하였다.

추가로 같은 도메인을 사용하고 있기 때문에 굳이 SameSite=None를 할 필요가 없었기 때문에 SameSite=Strict로 속성을 변경하였다.

한 줄 요약

JWT 리프레시 토큰을 XSS 공격과 js 접근을 차단하여 보안성을 올리기 위해 httpOnly 쿠키에 넣어서 전달을 받았는데, same-site 기본값이 Lax로 설정 되어있기 때문에 동일 도메인이 아닌 로컬 개발환경과 서버 간의 쿠키 전달이 이루어지지 않았습니다.

이를 해결하기 위해 same-site를 none으로 설정하기를 요청하였고 이 과정에서 백엔드 측은 secure : true 속성을 추가해줘야했는데 secure : ture는 https 프로토콜에서만 적용이 가능하기 때문에 이를 설정하기 위해서는 SSL 인증서가 필요했습니다. 그런데 SSL 인증서는 특정 도메인에서만 발급 받을 수 있기 때문에 도메인을 구입하여 서버에서 SSL 인증서를 발급 받은 후 https 를 적용하였고 프론트 로컬 환경에서도 https 와 송수신하기 위해 https 설정을 해주었습니다.

이후 브라우저에서 Partitioned 쿠키로 분류되는 문제가 있었는데, 서버와 프론트의 도메인을 동일하게 맞추고 SameSite=Strict로 변경해서 문제를 해결할 수 있었습니다.