리프레쉬 토큰 관리법

[ShimFFF]

Refresh Token 관리 전략

현재 프로젝트는 토큰 기반 인증(JWT)을 사용해 사용자 인증을 처리하고 있다. 이때, Access Token과 Refresh Token을 발급해 인증을 유지한다. Access Token은 짧은 만료 시간을 가지며, Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 발급받는 데 사용된다.

Access Token이 탈취되더라도 짧은 만료 시간으로 인해 큰 문제가 발생하지 않지만, Refresh Token은 이를 대체할 수 있으므로 철저히 관리해야 한다.

Refresh Token 관리 전략

Refresh Token은 클라이언트에서 직접 다룰 수 없도록 HTTP-Only 쿠키에 저장할 예정이다. 추가적으로, 보안성을 강화하기 위해 Redis를 활용한 중앙 관리 방식도 고려해 비교 검토한 결과, 현재 프로젝트의 상황에 맞게 HTTP-Only 쿠키만 사용하는 방식으로 구현하기로 결정했다.

Refresh Token 관리 방식

1. HTTP-Only 쿠키만 사용하는 방식

특징

• Refresh Token은 HTTP-Only 쿠키에 저장되며, 클라이언트 스크립트로 접근할 수 없다.
• 서버는 별도의 상태를 저장하지 않고, Stateless 인증 방식을 유지한다.
• 브라우저에서 요청 시 쿠키가 자동으로 포함되어 서버와 통신한다.

장점

1. 단순성
   • Redis 같은 추가적인 저장소 없이 간단히 구현할 수 있다.
   • 서버 상태를 유지하지 않아 관리가 쉬운 구조다.
2. 보안성
   • HTTP-Only 및 Secure 속성을 통해 클라이언트에서 Refresh Token이 노출되지 않는다.
   • CSRF 공격을 방지하기 위해 SameSite=Strict 옵션을 사용할 수 있다.
3. 확장성
   • Stateless 방식이므로 멀티 서버 환경에서도 추가적인 동기화 작업 없이 작동 가능하다.

단점

1. 로그아웃/토큰 무효화 처리 한계
   • 클라이언트의 쿠키를 무효화하는 것 외에는 중앙 관리가 불가능하다.
   • Redis와 같은 중앙 저장소를 사용하지 않으므로 서버가 Refresh Token 상태를 추적하지 못한다.
2. 보안 위협
   • 쿠키가 탈취되면 해당 Refresh Token을 악용할 수 있는 위험이 있다.

적합한 상황

• 초기 개발 단계의 소규모 프로젝트.
• 간단한 인증 요구 사항이 있는 SPA(Single Page Application) 또는 웹 애플리케이션.

2. Redis와 HTTP-Only 쿠키를 함께 사용하는 방식

특징

• Refresh Token은 Redis와 HTTP-Only 쿠키에 모두 저장된다.
• 서버는 Redis를 통해 Refresh Token의 상태를 중앙에서 관리하며, 요청이 들어올 때 쿠키에서 전달받은 토큰과 Redis에 저장된 토큰을 비교한다.

장점

1. 보안성
   • Redis에서 Refresh Token의 유효성을 확인하므로, 쿠키가 탈취되어도 Redis에서 해당 토큰을 무효화할 수 있다.
   • 로그아웃 시 Redis에서 해당 Refresh Token 삭제가 가능하다.
2. 중앙 관리
   • 특정 사용자나 디바이스에서만 Refresh Token을 무효화할 수 있다.
   • 여러 디바이스에서 동일 계정을 사용하는 경우, 한 디바이스에서 로그아웃하면 다른 디바이스도 로그아웃할 수 있다.
3. 확장성
   • Redis를 중앙 저장소로 사용해 멀티 서버 환경에서 상태 동기화가 용이하다.
   • Redis TTL(Time-To-Live) 기능을 활용해 자동 만료 처리할 수 있다.

단점

1. 복잡성 증가
   • Redis와 관련된 설정 및 관리가 필요하다.
   • 상태 기반 인증을 추가 구현해야 하므로 Stateless의 단순성이 감소한다.
2. 추가 비용
   • Redis 인프라를 운영하기 위한 비용이 발생한다.

적합한 상황

• 보안이 중요한 시스템(금융, 의료 등).
• 로그아웃/토큰 무효화 처리 요구가 있는 대규모 프로젝트.
• 멀티 서버 환경에서 인증 상태를 중앙에서 동기화해야 하는 경우.

HTTP-Only 쿠키 vs Redis + HTTP-Only 쿠키 비교

항목	HTTP-Only 쿠키만 사용	Redis + HTTP-Only 쿠키 조합
구현 복잡성	간단	상대적으로 복잡
보안성	HTTP-Only 및 Secure 속성 활용 가능	중앙 관리로 추가적인 보안 제공
로그아웃/토큰 무효화	클라이언트 쿠키 삭제만 가능	Redis에서 상태 삭제로 즉시 무효화 가능
확장성	Stateless 방식, 간단한 확장 가능	Redis를 통해 멀티 서버 상태 동기화 가능
운영 비용	추가 비용 없음	Redis 인프라 비용 발생

현재 선택한 방식 및 이유

HTTP-Only 쿠키만 사용하는 방식

현재 프로젝트는 초기 단계로, 간단한 인증 요구 사항과 빠른 개발 속도가 중요하다. Redis를 사용하는 방식은 높은 보안성과 유연성을 제공하지만, 현재 프로젝트에는 다음과 같은 이유로 HTTP-Only 쿠키만 사용하는 방식이 적합하다.

1. 구현의 단순성
   • Redis 없이 Stateless 방식으로 간단히 구현 가능하다.
   • MVP 단계에서는 빠른 개발과 유지보수가 중요하다.
2. 보안성
   • HTTP-Only, Secure, SameSite 설정으로 쿠키 보안을 강화했다.
   • Refresh Token 탈취 방지를 위한 기본적인 보안 조치로 충분하다.
3. 비용 절감
   • Redis 인프라 비용 및 관리 부담을 줄인다.
4. 향후 확장 가능성
   • 추후 보안 요구가 높아지거나 시스템 규모가 커질 경우 Redis와 조합하는 방식으로 전환할 수 있다.

향후 고려 사항

1. Redis 도입 시 전환 전략
   • 서비스 규모가 확장되거나 보안 요구가 증가하면 Redis를 활용해 Refresh Token 상태를 중앙 관리할 계획이다.
   • 이를 통해 강제 로그아웃, 디바이스 간 동기화 등의 기능을 구현할 수 있다.
2. 보안 모니터링
   • HTTP-Only 쿠키 방식에서도 Refresh Token 탈취 가능성을 지속적으로 모니터링해야 한다.

결론

현재 프로젝트는 초기 단계로, HTTP-Only 쿠키를 사용해 Refresh Token을 관리하는 방식으로 충분하다.

향후 필요에 따라 Redis를 도입해 보안을 강화하고 시스템을 확장할 예정이다. 이러한 방식으로 초기 개발의 단순성을 유지하면서도 장기적인 확장 가능성을 고려하면 될 것 같다.

---

Copyright © 2024 Saewon Shim All rights reserved.