🎶 최종 프로젝트 11일차
오늘은 미루고 미루던 리프레시 토큰 기능을 구현했다.
리프레시 토큰 갱신방식
- 액세스토큰을 새로고침 할 때마다 갱신한다?
- 액세스토큰이 만료될 때 혹은 만료되기 몇분전에 갱신한다?
추가 고려 사항
- 액세스토큰을 갱신할 때 리프레시 토큰도 갱신한다(리프레시 토큰 재사용 불가하도록, 로그인 유지 시간 계속 증가?)
- 리프레시 토큰을 DB에 저장한다(리프레시 토큰이 갱신될 때 이전 리프레시 토큰을 무효화)
- 액세스 토큰 또한 DB에 저장한다(액세스 토큰이 갱신될 때 이전 액세스 토큰을 무효화)
- 혹은 갱신 전 토큰을 DB에 저장(블랙 리스트 같이)
- 리프레시 토큰 유효시간 얼마나?
여러가지로 고려할 사항들이 있어서 팀원분들께 의견을 구했더니 내가 원하는대로 하라고 하셨다🤣
▶ 리프레시 토큰 갱신방식 → 새로고침 할 때마다 갱신
로컬스토리지에 저장된 액세스 토큰의 만료 시간을 따라가기 불편할 것 같고 구현하기 편하기도 해서 이 방식으로 결정했다. 시간이 남은 액세스 토큰을 폐기하니까 경제성은 좀 떨어지지만 안정성이 더 높은 것 같다.
▶ 토큰 한꺼번에 갱신
똑같은 리프레시 토큰으로 계속 액세스 토큰을 발급받는 건 조금 위험하다는 생각이 들었다. 그리고 사용자의 접속 유지에 더 편리하다고 생각했다.
▶ 토큰 모두 DB에 저장
만료되지 않은 토큰을 무효화하기 위해 저장한다.
jwt를 쓰면 블랙 리스트 형식을 쓰는 걸 추천한다고 봤다. 그러면 액세스 토큰을 받을 때마다 풀어볼 필요 없이 그냥 DB에 존재하는지만 확인해도 될 것 같았다. 그런데 우리 경우에는 인메모리DB를 쓰지 않으니까 화이트 리스트로 정해서 jwt를 풀고 허용 토큰값을 확인하도록 했다.
▶ 리프레시 토큰 유효 시간
액세스 토큰은 튜터님이 권해주신 30분으로 생각하고 있다.
리프레시 토큰은 일주일 정도로 생각하고 있는데 추후 변경될 수 있다.
새삼 디데이를 보고서 꽤 많은 TIL이 쌓였다는 생각이 들었다. 지난 날 동안 혹은 이번 프로젝트 기간 동안 나는 시간을 잘 썼다고 말할 수 있을까? 그렇지 않았더라도, 효율적인 과정을 거치지 않았더라도 괜찮다고 말해주고 싶다. 배우지 않았던, 강의 외의 자료를 참고해서 코드를 따라 작성해보고 프로젝트에 맞게 변형시키는 과정이 내게는 정말 의미있는 구현 과정이었다.
내가 짜놓은 코드를 다른 사람에게 이해시키기 위해 로직을 풀어써보려고 한다. 시큐리티에 대한 이해도 더 할 수 있고 정리도 될 것 같다.
주말에는 이것과 더불어 주석과 리팩토링에 중점을 두어야겠다.
✅ 기본 프로필
✅ 프로필 업데이트 (파일 처리, 버킷 저장)
✅ 프로필 다운로드
⬜ front 수정
✅ 버킷 수정
✅ 리프레쉬 토큰
⬜ 댓글 도메인 sub
