Published on

access token refresh token 차이

backendauthenticationsecurityjwttoken

Access Token과 Refresh Token 구조를 백엔드 관점에서 정리

최근 인증 구조를 설계하면서 Access Token과 Refresh Token을 어떻게 나누어 사용할지 고민하게 되었다. 특히 Access Token을 쿠키로 전달할지, Refresh 시 토큰을 어떻게 재발급할지, 그리고 장기 연결(SSE) 환경에서 인증 만료를 어떻게 처리해야 하는지에 대한 고민이 있었다. 이러한 설계 경험을 바탕으로 두 토큰의 역할과 구조를 백엔드 관점에서 다시 정리해보았다.

1. 왜 Access Token과 Refresh Token을 나눠서 사용할까?

백엔드에서 인증 구조를 설계할 때 가장 많이 고민하는 것 중 하나가 "Access Token과 Refresh Token을 왜 분리해야 하는가?"이다.

단순히 토큰 하나만 사용하면 안 될까?

결론부터 말하면, 토큰을 분리하는 이유는 보안성과 세션 관리의 균형 때문이다.

2. 단일 토큰 구조의 문제점

처음에는 이렇게 생각하기 쉽다.

로그인 시 하나의 토큰만 발급하고, 그 토큰이 유효한 동안 계속 인증에 사용하면 되지 않을까?

하지만 이 구조에는 치명적인 문제가 있다.

2.1 토큰 탈취 시 장기 세션 위험

Access Token 하나만 사용하고 만료 시간을 길게 잡으면, 토큰이 탈취되었을 때 사용자는 로그아웃하기 전까지 이를 제어할 수 없다.

즉,

  • 토큰 탈취 = 장기간 계정 노출

이라는 문제가 발생한다.

2.2 만료 시간을 짧게 하면 UX가 나빠진다

반대로 만료 시간을 매우 짧게 설정하면, 사용자는 자주 로그인해야 하는 불편함이 생긴다.

결국 우리는 이런 딜레마에 빠진다.

토큰을 길게 유지하면 보안이 약해지고 짧게 유지하면 사용자 경험이 나빠진다

이 문제를 해결하기 위해 등장한 구조가 바로 Access Token + Refresh Token 구조다.

3. Access Token과 Refresh Token의 역할

3.1 Access Token의 역할

Access Token은 실제 API 인증에 사용되는 토큰이다.

특징:

  • 유효 기간이 짧다 (예: 15분 ~ 1시간)
  • 매 요청마다 Authorization 헤더 또는 쿠키로 전달
  • 탈취되더라도 짧은 시간 내 만료됨

즉,

"짧게 쓰고 자주 교체되는 인증 토큰"

이라고 이해하면 된다.

3.2 Refresh Token의 역할

Refresh Token은 새로운 Access Token을 발급받기 위한 토큰이다.

특징:

  • 유효 기간이 길다 (예: 7일 ~ 30일)
  • 일반 API 호출에는 사용되지 않음
  • 오직 토큰 재발급 시에만 사용

즉,

"세션을 유지하기 위한 토큰"

이다.

4. 전체 인증 흐름 (백엔드 기준)

일반적인 로그인 흐름은 다음과 같다.

4.1 로그인 시

  1. 사용자 로그인 성공
  2. Access Token 발급
  3. Refresh Token 발급
  4. Access Token은 응답으로 전달
  5. Refresh Token은 보통 HttpOnly 쿠키에 저장
Client → Login 요청
Server → Access Token + Refresh Token 발급

4.2 API 요청 시

클라이언트는 Access Token을 이용해 API를 호출한다.

Client → API 요청 (Access Token 포함)
Server → 토큰 검증 후 응답

Access Token이 유효하면 정상적으로 응답한다.

4.3 Access Token 만료 시

Access Token이 만료되면, 클라이언트는 Refresh Token을 이용해 재발급을 요청한다.

Client → /refresh 요청 (Refresh Token 포함)
Server → 새로운 Access Token 발급

이 과정을 통해 사용자는 다시 로그인하지 않고도 세션을 유지할 수 있다.

5. 왜 Refresh Token은 쿠키에 저장하는가?

백엔드에서 중요한 보안 설계 포인트는 Refresh Token의 저장 위치다.

일반적으로 다음과 같이 설계한다.

  • Access Token: 메모리 또는 헤더
  • Refresh Token: HttpOnly 쿠키

이유는 명확하다.

5.1 XSS 공격 대응

Refresh Token을 LocalStorage에 저장하면, XSS 공격에 의해 토큰이 탈취될 위험이 있다.

반면 HttpOnly 쿠키는 JavaScript에서 접근할 수 없기 때문에 상대적으로 안전하다.

6. 백엔드 설계 시 고려해야 할 포인트

6.1 Refresh Token 재사용 방지

보안 강화를 위해 Refresh Token을 재사용 불가능하게 만들 수도 있다.

즉,

  • 토큰 재발급 시 기존 Refresh Token 폐기
  • 새로운 Refresh Token 발급

이 방식은 보안은 강화되지만 구현 난이도가 올라간다.

6.2 로그아웃 처리

로그아웃 시에는 다음 중 하나를 선택할 수 있다.

  1. Refresh Token을 서버 블랙리스트에 등록
  2. Refresh Token 자체를 폐기

백엔드 구조에 따라 선택이 달라진다.

6.3 토큰 저장 전략

실무에서는 보통 이렇게 나눈다.

  • Access Token: stateless (서버 저장 안 함)
  • Refresh Token: DB 또는 Redis에 저장 (선택)

이렇게 하면 세션 제어와 보안 관리가 수월해진다.

7. 언제 이 구조가 특히 중요한가?

Access Token / Refresh Token 구조는 다음 상황에서 특히 중요하다.

  • SPA(React, Vue) 기반 서비스
  • 모바일 앱 인증
  • 장기 로그인 세션이 필요한 서비스
  • 보안이 중요한 API 서버

즉,

"로그인 상태를 오래 유지하면서도 보안을 지키고 싶을 때" 필수적인 구조라고 볼 수 있다.

8. 정리

Access Token과 Refresh Token을 나누는 이유는 단순한 기술적 유행이 아니라, 다음 문제를 해결하기 위함이다.

  • 토큰 탈취 시 장기 세션 노출 방지
  • 짧은 만료 시간과 사용자 경험의 균형
  • 안전한 세션 유지 구조 설계

백엔드 관점에서 보면, 이 구조는 단순 인증 로직이 아니라 보안과 세션 관리 전략의 핵심 설계 요소라고 할 수 있다.

9. 결론

단일 토큰 구조는 구현은 단순하지만 보안과 세션 관리에 한계가 있다. 반면 Access Token과 Refresh Token을 분리하면,

  • 보안성 확보
  • 세션 유지 UX 개선
  • 토큰 만료 관리 유연성

이라는 장점을 얻을 수 있다.

따라서 현대 백엔드 인증 설계에서는 이 구조가 사실상 표준 패턴으로 자리 잡고 있다.