Firebase Auth Best Practices: 모든 Fetch 또는 Cookie에 getIdToken 적용
Next.js (React) 프로젝트에서는 일반적으로 인증에 Firebase Auth를 사용합니다. 이 인증 과정은 Firebase의 getIdToken() 함수에서 ID 토큰을 가져오고 이를 REST API 백엔드로 전송하는 것을 포함합니다. 하지만, 이러한 요청마다 최신 ID 토큰을 가져와야 할까요 아니면 쿠키로 설정해야 할까요? 이 블로그 글에서는 클라이언트측 데이터 가져오기 시나리오에서 ID 토큰 처리의 최적 사례를 탐색해보겠습니다.
IdToken 갱신과 캐싱
Firebase 인증 SDK는 토큰 갱신을 자동으로 처리합니다. 토큰은 매 시간마다 업데이트되며, 개발자의 개입이 필요하지 않습니다. 또한 SDK는 이미 토큰을 로컬 스토리지에 캐싱하므로 다른 곳에 따로 캐시할 필요가 없습니다. 토큰을 직접 캐싱하면 오래된 또는 잘못된 토큰을 사용할 수 있습니다. 따라서 ID 토큰이 필요할 때마다 항상 getIdToken()을 호출하는 것이 권장됩니다.
서버 측 렌더링 (SSR) 요청에 쿠키 사용하기
서버 측 렌더링 (SSR) 요청을 처리할 때는 일반적으로 쿠키를 사용하여 ID 토큰을 서버로 전달합니다. 이는 getIdToken()을 서버 측 렌더링 중에 호출할 수 없는 경우에 특히 유용합니다. 애플리케이션이 SSR에 크게 의존하는 경우, 토큰을 저장하고 각 요청과 함께 전송하는 쿠키를 사용하는 것이 적절한 접근 방식일 수 있습니다.
클라이언트측 데이터 가져오기 고려사항
애플리케이션이 클라이언트측 데이터 가져오기에만 의존하고 SSR을 사용하지 않는 경우, ID 토큰을 저장하기 위해 쿠키를 사용하는 것은 필요하지 않을 수 있습니다. 현재 사용 중인 접근 방식인 각 요청 전에 ID 토큰을 가져와 Authorization 헤더에 추가하는 것은 효율적이고 최선의 사례에 부합하는 방식입니다. 이 접근 방식은 항상 최신 토큰을 사용하여 백엔드와의 보안 통신을 보장합니다.
결론
요약하면, 클라이언트측 데이터 가져오기 시나리오에서 Firebase Auth를 사용할 때, ID 토큰이 필요할 때마다 getIdToken()을 호출하는 것이 권장됩니다. Firebase 인증 SDK가 토큰 갱신과 캐싱을 자동으로 처리합니다. 그러나 애플리케이션에 서버 측 렌더링도 포함된다면, ID 토큰을 쿠키에 저장하고 각 요청과 함께 전송하는 것이 유효한 대안이 될 수 있습니다. 프로젝트의 특정 요구 사항을 고려하고 필요에 가장 적합한 접근 방식을 선택하십시오.
참고 자료 :
https://stackoverflow.com/questions/62573086/firebase-auth-getidtoken-on-every-fetch-or-set-cookie
같은 카테고리의 다른 글 보기 :
