Garu's

[프로젝트 회고] RefreshToken 저장과 삭제 구조 리팩토링

들어가며

로그인 기능을 처음 구현한 뒤, 프론트엔드와 맞춰보면서 RefreshToken 처리 방식을 다시 손봤다.

문제는 단순했다.

1

프론트에서 RefreshToken이 제대로 백엔드 요청에 포함되지 않는다.

하지만 원인을 찾는 과정은 단순하지 않았다. Cookie 옵션, axios 설정, 서버 응답, CORS, 로그아웃 처리까지 함께 확인해야 했다.

문제 상황

로그인 후 RefreshToken을 Cookie에 담아 내려주었지만, 이후 요청에서 기대한 대로 동작하지 않았다.

처음에는 백엔드 로직 문제라고 생각했다.
하지만 확인해보니 브라우저가 Cookie를 요청에 포함시키려면 여러 조건이 맞아야 했다.

  • Cookie의 domain과 path
  • SameSite 옵션
  • Secure 옵션
  • HttpOnly 설정
  • 프론트 axios의 credentials 설정
  • 서버 CORS 설정

인증 기능은 백엔드만 보고 판단할 수 없다는 것을 다시 느꼈다.

RefreshToken 발급 후 Cookie를 적재하는 방식을 수정했다.

목표는 프론트엔드 요청에서 RefreshToken이 안정적으로 전달되도록 하는 것이었다.

특히 로컬 개발 환경과 배포 환경의 차이를 고려해야 했다.

HTTPS가 아닌 환경에서 Secure 옵션을 켜면 Cookie가 붙지 않을 수 있다.
반대로 운영 환경에서는 보안을 위해 Secure 옵션을 신경 써야 한다.

이 작업을 하면서 환경별 설정을 분리하는 것이 중요하다는 생각이 들었다.

로그아웃 시 삭제 처리

이후 RefreshToken 삭제 구조도 정리했다.

로그아웃할 때 서버에 저장된 RefreshToken을 삭제하고, 클라이언트 Cookie도 만료시키는 흐름이 필요했다.

JwtTokenizer에 트랜잭션을 추가하고, 로그아웃 시 RefreshToken 삭제가 하나의 작업으로 처리되도록 정리했다.

이때 느낀 점은 로그아웃도 데이터 변경 작업이라는 것이다.

단순히 응답으로 만료 Cookie를 내려주는 것뿐 아니라, 서버 저장소에 남아 있는 RefreshToken 상태도 함께 정리해야 한다.

테스트와 직접 확인

이 작업에서는 자동 테스트뿐 아니라 직접 브라우저에서 확인하는 과정도 중요했다.

Cookie는 코드만 봐서는 실제 동작을 완전히 알기 어렵다.
브라우저 개발자 도구에서 Cookie가 저장되는지, 요청 헤더에 포함되는지, 로그아웃 후 사라지는지 직접 확인해야 했다.

특히 프론트엔드와 백엔드가 다른 포트나 도메인에서 동작하는 상황에서는 브라우저 정책의 영향을 많이 받았다.

배운 점

RefreshToken 리팩토링을 통해 다음을 배웠다.

  • Cookie 기반 인증은 브라우저 정책을 반드시 이해해야 한다.
  • RefreshToken은 발급보다 저장, 전달, 삭제 흐름이 중요하다.
  • 로그아웃은 서버와 클라이언트 상태를 모두 정리해야 한다.
  • 로컬 환경과 운영 환경의 Cookie 옵션은 다르게 볼 필요가 있다.
  • 인증 문제는 프론트엔드와 함께 확인해야 빠르게 해결된다.

마무리

RefreshToken 처리 방식은 처음부터 깔끔하게 잡기 어려웠다.

하지만 프론트엔드와 직접 맞춰보며 문제를 확인한 덕분에, Cookie 기반 인증 흐름을 더 현실적으로 이해할 수 있었다.

앞으로 인증 기능을 만들 때는 로그인 성공만 확인하지 않고, 재발급, 로그아웃, Cookie 삭제까지 전체 흐름을 체크리스트로 관리해야겠다.

Leave a comment

You may also enjoy