하나씩 정리하는 중
(내가 이해한) Refresh Token
access token은 탈취 시 위험하니 access token 만료 기간을 짧게 하자!
→ 그런데 access token가 1시간이라 1시간마다 로그아웃 된다면...? 유저가 엄청 불편하다
→ 그럼 refresh token이라는 것을 줘서 access token 의 기간을 짧게 잡되, refresh token이 있으면 access token을 재발급하자! 유저가 필요할 때마다 access token을 알아서 재발급하면 해결.
⭐ access token 탈취 이후 정보 유출을 근본적으로 막을 수 없지만 하나의 방어책+유저 편의성을 위해 refresh token을 사용할 수 있는 것
Refresh Token 어디에 저장할까?
Front
access token을 재발급하기 위한 API 요청을 줄일 수 있다. 그러나 프론트에서 token을 관리하면서 발생할 수 있는 서버 이슈를 모두 감당하기 어려울 수 있다.
Local Storage
local storage 는 자바스크립트로 접근이 너무 쉬워서 XSS 공격에 취약하고 보안상 문제 소지가 많다.
XSS 공격
크로스 사이트 스크립팅(Cross Site Scripting, XSS).
공격자가 상대방의 브라우저에 스크립트가 실행되도록 해 사용자의 세션을 가로채거나, 웹사이트를 변조하거나, 악의적 콘텐츠를 삽입하거나, 피싱 공격을 진행하는 것
Cookie
HTTPOnly 와 Secure 옵션을 사용하고 CSRF 공격에 대비를 하면 어느정도 보안을 할 수 있다.
CSRF 공격
원클릭 공격 또는 세션 라이딩(Cross-Site Request Forgery).
CSRF는 링크 또는 스크립트를 사용하여 사용자가 인증된 대상 사이트로 원하지 않는 HTTP 요청을 전송.
Back(Server Side)
서버 issue를 백엔드에서 관리하기 용이하다. 반대로 access token을 재발급하기 위한 API 요청이 많아질 수 있다.
Session
세션에 저장하고 세션 만료 주기를 늘리는 방식. 사용자가 많은 경우를 고려하면 사용하지 않는 것이 좋다. 또한 JWT 이용 목적에 적합하지 않다.
DB
refresh token 를 데이터베이스에 저장한 후 index 값을 쿠키나 로컬스토리지에 저장하는 방법. 클라이언트 단에서 refresh token 을 노출하지 않는 추세로 바뀌는 중. refresh token을 DB에 저장해야만 탈취 당했을 때 해당 토큰을 폐기할 수 있다.(RTR기법=refresh token을 1회용으로 사용하기??)
진행상황
⭐⭐⭐ 인증인가를 구현하는 로직에 정답은 없으니 충분히 고민해보고 답을 찾으면 된다.
- refresh token은 DB에 저장
- Front(나)는 access token만 받아서 로컬스토리지에 저장
- refresh token을 사용해 로컬에 저장해도 XSS 공격에 어느 정도 대비할 수 있다.
- PWA 도입을 고려하고 있어 브라우저를 닫아도 삭제되지 않도록 로컬에 저장하면 좋지 않을까?
- 필요할 때 Authorization Header에 access token을 담아서 API 요청
- 로그인 이후 받아온 유저 정보는 전역으로 관리한다.(redux toolkit 사용)
- 유저 정보가 필요한 곳이 많아서 전역으로 관리하면 좋을 것 같다
cookie vs local storage
- 로컬스토리지에 저장할 경우 필요한 HTTP 요청에서만 token을 전달할 수 있다.
(자동전송의 위험이 없다) - 로컬스토리지는 최대 5MB의 정보를 저장할 수 있다.(쿠키는 4KB)
- 로컬스토리지는 인터넷이 끊겨도 유지한다.
구글 2023년 쿠키 퇴출 → 구글 로그인 시 로컬스토리지에 저장하는 것으로 통일되나...?
참조
카카오 JavaScript 키를 이용한 API/SDK 사용 시 refresh token 응답 필드 제거 안내
refresh-token 도입기
refresh token 어디에 저장해야 할까?
axios interceptor
