들어가며
Access Token을 클라이언트의 로컬 스토리지에 저장하는 방식은 구현이 간편하지만, 보안적으로 치명적인 단점이 있습니다. 대표적인 예로 XSS(교차 스크립팅) 공격이 있는데, 악성 스크립트가 로컬 스토리지에 접근해 사용자의 Access Token을 탈취할 수 있습니다.
이처럼 클라이언트 저장소에 민감한 인증 정보를 저장하는 것은 심각한 보안 취약점을 야기할 수 있으며, 이는 사용자 정보 유출로 이어질 수 있습니다. 따라서 보다 안전한 인증 흐름이 필수적입니다.
Access Token이란?
Access Token은 인증을 마친 사용자가 서버의 보호된 리소스 접근을 요청할 때 사용하는 짧은 생명주기의 토큰입니다. 일반적으로 15분에서 1시간 사이의 짧은 유효기간을 가집니다.
이 토큰은 DB 조회 없이 서버에서 빠르게 검증이 가능하다는 장점이 있으며, 간단한 인증 흐름을 구현할 수 있습니다. 하지만 유효기간이 만료되면 다시 로그인을 해야하며, 만약 토큰이 탈취되었을 경우 즉시 악용 가능하다는 점에서 보안적인 취약점을 가집니다.
Access Token만 사용하는 방식의 문제점
Access Token만으로 인증을 구성하면 다음과 같은 문제가 발생합니다.
- 토큰 만료 시마다 사용자가 직접 재로그인해야 하므로 사용자 경험(UX)이 저하됩니다.
- 토큰이 탈취될 경우, 공격자가 원래 사용자보다 먼저 요청을 수행할 수 있으며, 이는 심각한 보안 사고로 이어질 수 있습니다.
이러한 한계를 해결하기 위해 등장한 것이 Refresh Token입니다.
Refresh Token이란?
Access Token은 짧은 유효기간을 가지기 때문에, 일정 시간이 지나면 만료되고, 이로 인해 사용자는 로그인 세션이 강제로 종료됩니다. 이러한 UX 저하 문제를 해결하고, 보안을 강화하기 위해 도입된 것이 Refresh Token입니다.
Refresh Token은 서버가 클라이언트에게 추가로 발급하는 장기 유효 토큰으로, Access Token이 만료되었을 때 새로운 Access Token을 발급받는 데 사용됩니다.
Refresh Token의 특징
- 장기 유효성
보통 수일에서 수개월까지 유효하며, Access Token에 비해 상대적으로 오랜 기간동안 유지됩니다. - 서버 검증 기반
Access Token은 자체 검증(JWT 검증)만으로 충분하지만, Refresh Token은 일반적으로 서버에 저장하고 관리합니다. 이를 통해 탈취나 위·변조 방지를 강화할 수 있습니다. - 로그인 유지 가능
사용자가 서비스를 지속적으로 이용하더라도, 백그라운드에서 Access Token을 재발급받기 때문에 재로그인 없이 세션을 유지할 수 있습니다.
Token 재발급 흐름
위 다이어그램은 JWT 기반 인증 시스템에서 Access Token과 Refresh Token이 어떻게 상호작용하는지 시각적으로 보여줍니다.
현재 구현
현재는 다이어그램과 같은 구조로 JWT 인증을 구성하고 있습니다.
- Access Token: 클라이언트의 LocalStorage에 저장
- Refresh Token: 서버 측 Redis에 저장, 클라이언트는 HTTP 요청 시 직접 포함
이 방식은 구현이 간단하고 stateless 인증 구조에 적합하지만, 클라이언트측 LocalStorage는 여전히 XSS 공격에 취약하다는 단점이 있습니다.
향후 보완
보다 안전하고 신뢰성 높은 인증 구조를 위해 다음과 같은 혼합 전략을 적용할 예정입니다.
- Access Token -> 브라우저 메모리 또는 HttpOnly Cookie에 저장
- Refresh Token -> 서버의 Redis에 저장하고, HttpOnly Cookie를 통해 클라이언트에 전달
(*JavaScript 접근 불가능, 자동 전송 -> XSS 및 탈취 방지)
HttpOnly Cookie는 브라우저의 JavaScript에서 접근할 수 없도록 보호된 쿠키입니다.
즉, document.cookie로 읽을 수 없으며, 오직 HTTP 요청/응답을 통해서만 전달되는 쿠키입니다.
마무리
현재의 구현은 빠른 개발과 테스트에 적합하고, 추후에는 보다 정교한 인증 흐름을 확장해 나갈 계획입니다.
