액세스토큰을 변수로 저장하면 생기는 문제점

안녕하세요. 강의중에 액세스토큰을 변수로 req.header에 저장하면 아래와 같이 3가지 문제점이 있다는 것을 구글링을 통해서 확인했습니다.

1.보안: 액세스토큰을 req.header에 변수로서의 토큰은 공격자에 의해 가로채기에 취약합니다.

2.확장성: 애플리케이션에 많은 수의 요청이 있는 경우 req.header의 변수는 크기가 커지고 성능 문제가 발생할 수 있습니다.

3.지속성: req.header에 액세스 토큰을 저장하는 것은 영구적이지 않습니다. 사용자가 페이지를 새로 고치거나 브라우저를 닫으면 액세스 토큰이 손실됩니다. 이로 인해 사용자가 보호된 리소스

에 액세스하기 위해 다시 로그인해야 할 수 있습니다.

질문1)

3번 지속성문제의 경우, 브라우저를 새로고침하게 되면, 액세스 토큰이 사라지게 되니 오히려 보안이 좋다고 생각해야 할까요? accessToken이 수업에서는 10분으 로 만료기간을 설정했는데, restoreAccessToken API가 있기 때문에 acessToken을 req.header에 변수로 저장해도 문제가 되지 않을까요?

질문2)

액세스토큰 만료시간을 10분 ~30분 으로 짧게 잡으신 이유가 1번 문제점 보안의 이유라고 생각하면 될까요?

질문3)

선생님, 좋은 강의 해주셔서 진심으로 감사합니다. 저는 선생님의 백엔드와 프론트 강의를 수강후 실제 웹 서비스를 런칭하기위해서 수업을 듣고 있습니다. 현재는 백엔드 강의를 수강중입니다.

실제 웹 서비스런칭시 accessToken을 req.header에 변수로서 저장하고, refreshToken은 쿠키에 저장하는 게 올바른 방법인가요?

refreshToken을 수업에서 가르쳐주신 대로 secure : true, httponly: true와 같이 배포환경으로 바꿔서 배포하게 된다면 보안상 안전할까요?

질문4)

구글링을 해보니, 리프레시 토큰을 Redis에 저장하고, 액세스토큰은 쿠키에 저장하는 방법도 있는 것을 확인했습니다. 액세스토큰의 만료기간을 10분으로 잡고, 리프레시토큰의 만료기간을 2주로 잡을 경우, restoreRefreshToken API 때문에 Redis DB에 자주 접속하게 되어서 DB 사용료가 많이 청구 되지는 않을까요?

서버를 stateless 상태로 웹 서비스를 런칭하기 위해서는 액세스토큰과 리프레시 토큰을 어떻게 저장해야 할까요? 가장 안전한 방법이라고 할 수 있을까요?

감사합니다.