Q. 질문
accessToken reissue 자동 갱신을 현재는 (토큰 만료 인증 실패 에러)이 뜨는 순간이라고 적었는데 보니까 로 변경되어있네요.. instance.interceptors를 사용해서 reissue api가 호출되도록 작업을 해두었습니다.
401
404
404
(refreshToken이 없는 경우 뜨는 에러)로 변경한 이유는 인증이 없어도 되는 경우 (rank, profile 리스트 조회)를, 즉 access 토큰이 필요한 곳에서 토큰이 없어도 페이지 접근을 가능하게 하고 싶어서 404
로 현재는 바꿔두었습니다.. 🥲instance.interceptors.response.use( async response => { return response; }, async error => { const { status, config } = error.response; // TODO: 백엔드에서 가져온 cookie를 브라우저에서 get 하는지 확인하기 const refreshToken = await getCookie("refreshToken", ""); // TODO: accessToken을 쿠키에 저장하여 1시간 이후가 되면 자동 갱신하도록 수정? if (status === 404) { const newAccessToken = await reIssueAccessToken(refreshToken); if (newAccessToken) { localStorage.setItem("accessToken", newAccessToken); config.headers.Authorization = `Bearer ${newAccessToken}`; return instance(config); } return Promise.reject(error); } return Promise.reject(error); }, );
그런데 이 방법을 사용하면, 비회원인 경우를 제어하려고 할때 비용이 너무 많이 들 것 같아 고민입니다..
(accessToken 만료 시간이 1시간인데, 프론트에서도 cookie에 1시간 기한을 두고, 1시간 되면 갱신되는 방식으로 변경하면 비용 걱정을 덜할 수 있을까요)
백엔드에서는 비회원 설정을 따로 하지 않은 상황인데, 이런 경우 프론트에서도 그냥 회원인 경우만 고려해서 서비스를 배포하는게 맞을까요?
이런 고민을 하는 이유가.. 일단 취업 준비를 하는 프론트엔드 입장에서 포트폴리오를 고려한다면 사용자가 회원가입 하지 않고도 view를 볼 수 있고, 둘러볼 수 있는 서비스가 접근성이 좋아서 좋지 않을까 생각도 들고.. (배포 중단 기한이 있는) 서버에 완전 의존적이지 않게 만들 수 있을 것 같아서 자꾸 욕심이 납니다…
A. 멘토님 답변
좋은 고민입니다.
우선, 토큰의 갱신을 프론트엔드에서 제어할지 서버에서 제어할지도 고민해볼수 있겠네요.
각각의 방식이 어떤 장단점이 있는지 고민도해보고 리서치도해보면 좋겠습니다.
클라이언트에서 직접 reissue api를 호출한다면 분명 복잡성이 올라갈것입니다.
두번째로 회원,비회원이 접근가능한 리소스가 무엇인지 명확하게 구분할 필요가 있습니다.
백엔드에서 비회원이 접근가능한 리소스에서도 401응답을 반환한다면 프론트엔드에서는 하드코딩으로 구분해야할텐데 이는 너무 비효율적이고 유지보수하기 어려운 방식입니다.
401하나뿐 아니라 에러코드를 추가하여 회원/비회원을 구분할수도 있을것같습니다.
그런데 이 방법을 사용하면, 비회원인 경우를 제어하려고 할때 비용이 너무 많이 들 것 같아 고민입니다.. → 어떤 비용이 발생할것같은지 더 자세히 들어보고싶습니다
accessToken 만료 시간이 1시간인데, 프론트에서도 cookie에 1시간 기한을 두고, 1시간 되면 갱신되는 방식으로 변경하면 비용 걱정을 덜할 수 있을까요 → 쿠키 만료직전 보낸요청의경우 요청이 실패할수도 있을것같습니다