[RhythMeet] 로그인 - JWT 토큰 인증 구조 개선

서론

JWT 토큰.. 막 프로젝트를 접하던 1-2학년 학부생 시절에 로그인 기능을 이걸로 구현하고 싶어서 낑낑댔던적이 있다.

그때는 이게 무슨말이지 도저히 이해를 못하고 구현을 포기했었는데,

지금은 이걸 이해하고 프로젝트에 적용 시켰다니 신기한 일이다. 많이 성장했음을 느낀다.

---

부끄럽지만 RhythMeet 기존의 로그인 인증 방식은 문제가 좀 많았다.

발표 시간에 맞춰서 한달이라는 짧은 시간 안에 최대한 기능을 구현했어야 하는 문제때문도 있을것이다.

 

어쨌든, 이번 로그인 인증 방식을 내가 리팩토링하기로 했다.

제대로 로그인 기능을 구현해보고 싶었는데 나야 럭키비키다🍀

그러면 어떻게 해결했는지 포스팅해보도록 하겠다.

---

로그인 인증 구조

우선 기본적으로 액세스 토큰 / 리프레시 토큰 한 세트가 있고

리프레시 토큰을 이용해 액세스 토큰을 갱신한다는 것이 기본적인 이론이다.

그리고 JWT 토큰을 쿠키에 저장해야 보안성이 좋다는것도,

(이정도는 알고있었다)

 

그러면 기존의 코드는 어떻게 구현되었을까? 어떤 문제가 있었을까?

---

문제 상황

기존의 서비스 로그인 인증 구조에는 다음과 같은 문제가 있었다.

1. Access 토큰과 Refresh 토큰을 모두 응답 Body로 전달받고 있었다.

2. 그리고 이렇게 전달받은 토큰을 프론트에서 로컬스토리지에 저장하고 있었다.

3. RefreshToken의 유효기간이 지나면 무한 로딩 및 로그아웃이 불가한 문제가 발생했다.

4. 물론 보안상의 이슈도 있었다.

 

이러한 문제가 있어 서비스 자체 사용에도 문제가 있던 상황이었다.

(무한로딩..)

 

문제 해결 과정

1. 멘토님께 질문드리기

토큰을 쿠키에 저장하고 싶었다. 이럴 경우 백엔드의 구조도 바꿔야 하는것으로 알고 있기에,

어떻게 변경하면 좋을지 부트캠프 시절 멘토님께 연락을 드렸다.

 

header에 담아서 보내도록 수정을 해줘야 한다고 한다.

그리고 리프레시토큰은 프론트로 전달을 해주지 않고, 백엔드 쪽에서만 가지고 있어야 한다고 답변주셨다.

두개 다 주는것은 관리자 권한을 주는것과 동일하다고..

https://olrlobt.tistory.com/98

참고자료도 주셨다

 

그렇다. 둘다 body로 전달하면 안되는것이었다.

그래서 로그인 리팩토링 담당 백엔드 팀원에게 이 얘기를 전달하고 논의를하였다.

2. 서버 로직 개선

하여 백엔드 팀원이 로그인 로직 구조를 개선해서 오셨다.

 

로그인시 Access 토큰과 Refresh 토큰 모두 Body 로 응답

->  로그인시 Refresh 토큰은 쿠키, Access 토큰은 헤더로 넣어서 응답

 

이제 프론트를 개선하면 된다.

---

3. 기존 (변경전) 구조

내가 분석한 기존의 구조를 요약하면 이렇다.

RefreshToken을 로컬스토리지에 저장하고,

// callback.tsx
localStorage.setItem("accessToken", accessToken);
localStorage.setItem("refreshToken", refreshToken);

 

AccessToken 만료시 로컬 스토리지에 저장되었던 RefreshToken을 이용해서 재요청을 보낸다.

// utill.ts
const refreshToken = localStorage.getItem("refreshToken");
      if (!refreshToken) return Promise.reject(error);
      try {
        const response = await api.post<
          AxiosResponse<ApiResponse<RefreshTokenResponse>>
        >(ApiEndpotins.REFRESH_TOKEN, {
          refreshToken,
        });

 

그 후 다시 받아온 토큰 응답들을 다시 로컬 스토리지에 저장하는 방식이었다.

const { accessToken: newAccessToken, refreshToken: newRefreshToken } =
          response.data.data;
        localStorage.setItem("accessToken", newAccessToken);
        localStorage.setItem("refreshToken", newRefreshToken);

 

그러나 RefreshToken의 유효기간이 지나도 RefreshToken을 갱신할 방법이 없다.

계속 죽은 토큰을 이용해 엑세스 토큰 요청을 보내는거다.

 

로컬스토리지는 브라우저를 닫거나 장치를 재부팅해도 데이터가 유지되기에

캐시를 지우지 않는 한 업데이트가 되지 않았다.

 

그렇기에 로그아웃도 불가한 무한로딩이 발생했다. 

 

4. 변경한 코드 구조

물론 이 분기를 재정비해서 로컬스토리지에서 관리할 수 있는 방법이 있겠으나, 

유저가 있는 서비스에 로컬스토리지에 두 토큰이 노출되는 방식이 보안적으로 만족스럽지 않았다.

(그래서 처음에는 리프레시 토큰을 세션으로 옮겨서 아예 브라우저 닫을때마다 날릴까.. 하는 방식도 생각을했다)

보완이 필요하다고 느껴 아예 쿠키 관리 방식을 적용해보기로 하였다.

백엔드 팀원도 흔쾌히 ㅇㅋ를 외쳐주셔서 더욱 감사했다.

 

// utill.ts
const axiosInstance = axios.create({
  baseURL: domain,
  timeout: 8000, // 응답 8초 넘으면 오류
  withCredentials: true, // RefreshToken 쿠키 자동 전송
  headers: {
  },
});

 

우선 기본 응답 인스턴스를 수정했다.

withCredentials: true 를 추가해서 쿠키를 사용하도록 했다.

 

+) withCredentials: true란?

Axios 요청에서 인증 관련 쿠키, 자격 정보를 함께 전송하도록 하는 옵션.

HttpOnly는 서버에서 쿠키를발급할때 따로 설정해주어야한다.

// 예시
res.cookie("refreshToken", token, {
  httpOnly: true,   // 자바스크립트에서 접근 불가
  secure: true,     // HTTPS 환경에서만 전송
  sameSite: "none", 
});
res.send({ success: true });

그래서 서버에서 HttpOnly를 설정해주고,

클라이언트에서 withCredentials를 설정해주어야 안전한 쿠키 전송이 가능하다.

 

 

그 후, 헤더로 받은 액세스 토큰만 로컬스토리지에 저장하도록 하였다.

// utill.ts
    const newAccessToken = response.headers["accesstoken"];
    if (newAccessToken) {
      localStorage.setItem("accessToken", newAccessToken);
    }

 

그리고 액세스 토큰이 만료되었을 경우 ㅡ

쿠키에 있는 리프레시 토큰으로 액세스 토큰을 재요청했다.

 // utill.ts - AccessToken 만료시 refresh 요청
    if (
      errorMessage === "유효하지 않은 토큰입니다." &&
      error.config.url !== ApiEndpotins.REFRESH_TOKEN
    ) {
      try {
        const refreshRes = await axiosInstance.post(
          ApiEndpotins.REFRESH_TOKEN,
          { withCredentials: true }
        );

 

그후 이 재발급 받은 액세스 토큰을 다시 저장하여

다시 실패한 API 요청을 재시도한다.

 

그리고 만약 리프레시 토큰 마저 만료된다면

 catch (err) {
        localStorage.removeItem("accessToken");
        toast.showToast(
          "error",
          "세션이 만료되었습니다. 다시 로그인해주세요.",
          "auth"
        );
        return Promise.reject(error);
      }

 

액세스 토큰을 지우고, 토스트 메세지를 띄운다.

그리고 로그인 페이지로 리다이렉트한다.

 

+)

구현을 하는 과정에서 찾아보니 리프레시 토큰도 연장하는 개념이 있는듯 했다.

하지만 우리가 구현한건 리프레시 토큰이 만료되면 새로 재발급하는 방식이기에

그냥 만료시 다시 로그인을 함으로써 재발급 할 수 있도록 클라이언트에서 구현을했다.

 

5. 또 다른 문제

그런데 로그인을 하면 바로 세션이 만료되었다면서 로그인창으로 넘어가는 문제가 발생했다.

 

이유가 뭐인고, 하니

로그인을 하고 성공할 경우 -> 토큰을 각각 쿠키와 스토리지에 저장하는데

그 실행 작업과

로그인 성공후 유저 정보를 불러오는 요청을 동시에 보내다보니

 

유저 정보의 요청에서 토큰이 없어서 거부(!) 401 당하면서 다시 로그인 화면으로 돌아오는것이었다.

 

if (
      errorMessage === "유효하지 않은 토큰입니다." &&
      error.config.url !== ApiEndpotins.REFRESH_TOKEN &&
      !error.config.url.includes("/auth/login") // ✅ 로그인 요청은 refresh 시도 금지
    ) {

그래서 utill.ts에 이러한 코드를 한 줄 추가해주고,

if (isRegistered) {
     getMe();
}

이렇게 유저 정보를 바로 불러오던 기존의 코드를

// Callback.tsx
if (isRegistered) {
      setTimeout(() => {
        getMe();
      }, 150);
    }

이렇게 약간의 대기 후 불러올 수 있도록 수정했다.

 

그래서 지금은 잘 작동되는 로그인 기능!^_^

세션 만료 자동 로그아웃도 잘 작동한다.

이렇게 저장된 쿠키에 보안 체크도 잘 된다.

 

---

갱신 로직 흐름

1. AccessToken 만료 시
Axios 인터셉터, 401 응답(유효하지 않은 토큰입니다.) 감지

 

2. /auth/refresh 요청 전송

(쿠키에 담긴 RefreshToken이 서버로 자동 전송)

3. 서버, RefreshToken 검증

유효하면 새 AccessToken을 응답 헤더(accesstoken)로 전송

 

4. 프론트, 새 AccessToken을 localStorage에 저장
실패했던 API 요청을 자동으로 재시도

5. if RefreshToken이 만료된 경우

/auth/refresh 요청 자체가 401 / 403으로 거부

프론트, 토큰 삭제 및 로그아웃 처리로 전환