티스토리 뷰
각 토큰의 역할
- access token
- 실제 유저가 로그인되어 있는지 확인하는 용도
- 마이페이지 > 닉네임 변경처럼 ‘인가’가 필요할 때, 헤더에 포함시켜서 백엔드에 ‘내가 누군지’를 알려주는 용도
- refresh token
- access token을 재발급받아야 하는 상황에서 쓰이는 용도
순서
- [FE] 홈페이지에 유저가 접속 ( 로그인상태가 아닌 경우)
- [FE] 유저가 로그인 페이지로 이동
- [FE] 이메일, 비밀번호 → 로그인 → 백엔드에 로그인 요청
- [BE] 이메일, 비밀번호를 request body에서 찾아서 DB를 검색
- [BE] 처리
- 유저정보 존재 : 정상 return
- 응답값으로 access token을 준다.
- 쿠키에 httponly, secure 세팅을 해서 refresh token을 세팅한다.
- 유저정보 없음 : 오류 return
- [FE] 아이디 또는 비밀번호를 확인해 주세요! alert
- 유저정보 존재 : 정상 return
FE의 상황
- 리턴값으로 access token을 받는다
- 브라우저 쿠키에 refresh token이 세팅되어 있는 상태
- [FE] 응답값에 대한 처리(로그인여부와 상관없이 쿼리는 refresh token을 이용해서 access을 요청한다)
- SAMPLE_KEY 에 해당되는 query를 invalidate 하면
- [FE] 루트 레이아웃 또는 항상 보이는 영역(부모 컴포넌트 영역)에서
- tanstack query로 refresh token을 이용해서 access을 요청
- tanstack query의 stale time을 Infinity로
- query key : SAMPLE_KEY
두 개로 나눠 봅시다 tanstack query에 access token이 담길 수 있는 방법 2가지!!
- 이미 브라우저 쿠키에 refresh token이 있는 경우
- 새로고침 시, tanstack query에 요청 → refresh token을 가지고 at을 요청
- 로그인 시
- at이 비어있다가 → invalidate 처리 → at가 담김
현재 온보딩에서 정상적으로 토큰핸들링이 어려운 이유 우리 환경엔 백엔드 없음
- at : 있음
- rt : 없음
로그아웃은
프론트가 엑세스토큰을 헤더에 담아 요청을 보내면
백엔드가 쿠키에 세팅한 리프레시토큰을 지움으로 로그인정보가 사라진다
원장님은 로그인여부와 상관없이 쿼리로 리프레시토큰에 엑세스토큰을 요청을 보내고 있다
리프레시토큰이 없다면
엑세스토큰을 비워둔상태로 응답을 보내고
리프레시토큰이 있다면
엑세스토큰을 응답받으면 된다
왜 이 방법을 사용했는가
새로고침이 많이 일어나지 않는다는 가정하에 로직을 구상했고, 이런 로직을 많이 사용한다
서비스 접속하면 최상위 컴포넌트에서 쿼리로 리프레시토큰에 계속 엑세스토큰을 요청하는 것
엑세스토큰 여권 같다
구청에서 발급해 주고
주기적으로 새로 갱신해야 하고
여행 갈 때마다 인증용도로 사용해야 하니깐