Axios에서 access token과 refresh token을 함께 다루는 방법

요청을 보내기 전에 access token 붙이기

토큰은 요청 직전에 읽는다. 인스턴스를 만들 때 한 번 읽어 두면 로그인·갱신 뒤에도 이전 값이 남기 때문이다.

api.interceptors.request.use(async (config) => {
  const bearer = tokenStore.getAccessToken();

  if (bearer) {
    config.headers.set('Authorization', `Bearer ${bearer}`);
  }

  return config;
});

동시에 들어온 401은 한 번만 갱신하기

화면을 처음 열 때 API 5개가 동시에 호출될 수 있다. access token이 같은 시점에 만료되어 5개 요청이 모두 401을 받으면, refresh도 5번 보내면 안 된다.

진행 중인 refresh 작업을 refreshPromise 하나로 공유했다. 첫 번째 요청만 실제 갱신을 시작하고, 나머지는 같은 Promise가 끝날 때까지 기다린다.

let refreshPromise: Promise<string> | null = null;

async function refreshAccessToken(): Promise<string> {
  if (!refreshPromise) {
    refreshPromise = (async () => {
      const refreshToken = await tokenStore.getRefreshToken();
      const response = await authApi.post('/auth/refresh', { refreshToken });
      const pair = response.data as TokenPair;

      await tokenStore.save(pair);
      return pair.accessToken;
    })().finally(() => {
      refreshPromise = null;
    });
  }

  return refreshPromise;
}

서버가 refresh token을 매번 새로 발급하는 방식이라면 응답의 새 refreshToken도 함께 저장해야 한다. 이전 값을 유지하면 다음 갱신에서 이미 폐기된 토큰을 보내게 된다.

401 응답을 한 번만 재시도하기

응답 처리기에서는 모든 오류를 refresh 대상으로 보지 않는다. 실제로 access token이 만료된 경우인 401만 처리하고, 로그인·refresh 요청은 제외한다. 원래 요청에도 _retry 표시를 붙여 같은 요청이 계속 반복되지 않게 했다.

api.interceptors.response.use(
  (response) => response,
  async (error) => {
    const original = error.config;
    const status = error.response?.status;
    const isAuthRequest = original?.url?.includes('/auth/');

    if (status !== 401 || !original || original._retry || isAuthRequest) {
      return Promise.reject(error);
    }

    original._retry = true;

    try {
      const accessToken = await refreshAccessToken();
      original.headers.set('Authorization', `Bearer ${accessToken}`);
      return api(original);
    } catch (refreshError) {
      await tokenStore.clear();
      onAuthenticationExpired();
      return Promise.reject(refreshError);
    }
  },
);

실제 TypeScript 프로젝트에서는 Axios의 요청 설정 타입에 _retry를 추가한다.

declare module 'axios' {
  interface InternalAxiosRequestConfig {
    _retry?: boolean;
  }
}

refresh가 실패하면 조용히 원래 요청을 계속 보내지 않는다. refresh token이 만료됐거나 서버에서 폐기된 상태일 수 있으므로 저장된 인증 정보를 지우고 로그인 화면으로 보낸다. 네트워크가 잠깐 끊긴 경우까지 바로 로그아웃할지는 서비스의 재시도 정책에 따라 따로 정한다.

401을 받은 요청마다 refresh를 보냈다

첫 구현에서는 응답 인터셉터 안에서 바로 /auth/refresh를 호출했다. 화면 진입 시 401이 5개 나오자 refresh도 5개가 나갔다. refresh token을 한 번만 사용할 수 있게 만든 서버에서는 일부 요청이 새 토큰을 받기 전에 실패했다.

진행 중인 Promise를 공유하는 방식으로 바꾸고, refresh 응답에 새 refresh token이 있으면 함께 저장하도록 수정했다.

refresh 요청에도 같은 Axios instance를 사용했다

refresh token이 만료된 상황에서 /auth/refresh도 401을 반환했다. 응답 인터셉터가 다시 refresh를 호출하면서 요청이 끝나지 않았다.

refresh에는 별도 Axios 인스턴스를 사용하고, 원래 요청의 _retry와 인증 URL 제외 조건을 함께 적용했다.

React Native에서 AsyncStorage에 refresh token을 넣었다

로그인 상태를 복원하기 쉽다는 이유로 처음에는 모든 토큰을 AsyncStorage에 저장했다. access token과 장기 인증 수단을 같은 곳에 둔 셈이었다.

이후 access token은 메모리에서만 관리하고, refresh token은 운영체제 보안 저장소를 사용하는 구조로 나눴다. 앱을 다시 열 때만 refresh token을 읽어 새 access token을 만들도록 했다.

모든 401을 로그인 만료로 처리했다

401이 항상 access token 만료를 뜻하는 것은 아니다. 서버가 권한 부족을 401로 표현하는 경우도 있고, 로그인·refresh API 자체의 인증 실패도 있다.

API 계약을 확인해 갱신 대상 응답을 정했다. 서버가 구분된 오류 코드를 내려 주면 상태 코드만 보지 않고 그 코드까지 확인하는 편이 안전하다.