🛠️ 소셜 로그인 후 access token? 알고 보니 SSE 전용 토큰이었다

최근 프로젝트에서 소셜 로그인 후 access token 저장 및 인증 처리를 하던 중,
localStorage에 저장된 access token이 이상하게 **[object Object]**로 저장되고,
API 요청에 인증이 제대로 되지 않는 현상이 발생했다.

처음엔 단순한 버그라고 생각했지만, 이 문제를 추적하면서
나는 "access token", "SSE token", "응답 헤더 vs 바디" 개념을 제대로 이해하고 있지 않았다는 걸 깨달았다.

🔍 문제의 시작: access token이 [object Object]로 저장됨

처음엔 다음과 같은 코드로 access token을 저장하고 있었다.

const response = await axiosInstance.get('/api/jwt/access-token');
localStorage.setItem('access_token', response.data.data);

이때 response.data.data는 아래와 같은 형태였다:

{
  tokenType: 'SSE',
  value: 'eyJhbGciOiJIUzI1NiJ9.eyJlbWFpbCI6...'
}

즉, 나는 토큰 객체 전체를 문자열 없이 저장해서 [object Object]가 들어간 거였다.

🧠 그리고 더 중요한 걸 놓치고 있었다: 이건 SSE 전용 토큰이었다

문제는 단순히 stringify를 안 했다는 데 있지 않았다.
백엔드 팀원에게 물어본 결과, 내가 저장하고 있는 value는
일반 access token이 아니라 실시간 알림(SSE) 연결을 위한 전용 토큰이었다.

백엔드 구조는 이렇게 되어 있었다:

• 헤더 (Authorization): 일반 access token
• 쿠키 (Set-Cookie): refresh token
• 바디 (data.value): SSE 알림 전용 토큰

나는 바디에 담긴 토큰을 일반 인증용으로 착각하고 모든 API에 써버리고 있었던 것.

✅ 올바른 구조로 수정

수정된 코드는 다음과 같다:

const response = await axiosInstance.get('/api/jwt/access-token');

// 헤더에서 일반 access token 추출
const authAccessToken = response.headers['authorization']?.replace('Bearer ', '');
if (authAccessToken) {
  localStorage.setItem('access_token', authAccessToken);
}

// 바디에서 SSE token 추출
const sseToken = response.data.data?.value;
if (sseToken) {
  localStorage.setItem('sse_token', sseToken);
}

이제 access_token은 일반 API 호출에 사용하고,
sse_token은 알림 구독 시 아래처럼 사용한다:

const eventSource = new EventSource(`/api/notification/subscribe?token=${sseToken}`);

✍️ 내가 몰랐던 것들

1. 응답 바디와 응답 헤더의 역할 차이

   • 바디는 데이터
   • 헤더는 인증 같은 메타정보

2. access token은 무조건 바디에만 있는 게 아니다
   → 오히려 보안상의 이유로 헤더로 내려오는 경우가 많다

3. refresh token은 HttpOnly 쿠키로 오기 때문에 JS에서 접근 못 한다

4. SSE 연결용 토큰은 따로 관리해야 하며, 일반 인증과 별도로 분리되어야 한다

📌 마무리

이 경험을 통해 나는 인증 구조의 기본기를 많이 배웠다.
앞으론 단순히 "토큰이 있다"고 해서 무조건 access token으로 쓰지 않고,
용도에 따라 구분하고 저장 위치도 구분해서 관리할 것이다.