JWT Token의 로그인을 구현해야하는 상황
첫 로그인 구현으로 JWT 토큰에 대한 이해도 부족했으며 Access Token과 Refresh Token을 어디에 저장해야하는지를 알지 못해서 구현에 어려움을 겪었다.
JWT Token은 유효 기간이 정해져 있어 이 기간이 지나면 Token은 만료되어 로그인이 중단되어 사용자의 잦은 로그인이 필요해 사용성이 저하된다.
Refresh Token을 함께 발급하여 Access Token이 만료되었을 때 Refresh Token을 사용하여 새로운 Access Token을 발급받는다.
Token 탈취 및 악용으로 인한 보안 문제
모든 Token을 Cookie에 저장
쿠키는 CSRF(Cross-Site Request Forgery) 공격에 취약하지만 HTTP Only, secure 등의 옵션으로 방지할 수 있다.
모든 Token을 Web Storage에 저장
쿠키는 4KB까지 밖에 저장공간을 가지지 못하지만 웹 스토리지는 약 5MB정도의 저장공간을 가질 수 있다.
웹 스토리지는 자바스크립트로 제어 가능하여 XSS공격에 대한 위험이 있다.
Local Storage
로컬 스토리지(local storage)는 데이터를 브라우저에 반영구적으로 저장하며, 브라우저를 종료 후 재시작해도 데이터가 남아있습니다. 또한 다른 창과 브라우저를 통해서도 접근이 가능하다.
자바스크립트를 통해 localstorage에 데이터를 저장 할 수 있다.
Session Storage
세션 스토리지(session storage)는 로컬 스토리지와 유사한 기능을 하고 있으나 브라우저가 닫히면 데이터는 사라지게 되며 다른 창과 브라우저로의 데이터 공유또한 불가능하다.
결정: 백엔드 개발자와 의논을 통해 API 응답에 Access Token과 ****Refresh Token을 보내주고 프론트엔드가 2-a번의 해결방안인
Local Storage에 저장하는 방식으로 로그인을 구현하기로 결정했다.
결정 이유: Session Storage에 저장하게되면 브라우저가 닫히면 데이터는 사라지게 되어 결국 사용자는 브라우저를 닫게되면 재로그인 해야한다는 점은 잦은 로그인이 필요하다는 점이 적절한 해결 방안이 아니라고 생각되었고 첫 로그인 구현으로 쿠키 방식보다는 비교적 쉽다고 판단되는 Local Storage에 저장하는 방식을 채택했다.
Local Storage에 저장하면 첫 로그인 구현인 나에게 구현이 비교적 쉽다는 장점이 있어서 이번 구현에서 채택을 했지만 XSS 공격에 취약하는 단점이 있다.