HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📯
부스트캠프 7기 BE 멤버쉽 설계
/
Access, Refresh 토큰을 모두 사용하는 jwt 인증 방식에서는 Refresh 토큰을 디비단에서 저장해두고 있는게 합리적 인증방식일까요? 실제 서비스에서는 어떤 방식으로 할까요?

Access, Refresh 토큰을 모두 사용하는 jwt 인증 방식에서는 Refresh 토큰을 디비단에서 저장해두고 있는게 합리적 인증방식일까요? 실제 서비스에서는 어떤 방식으로 할까요?

요약
- 리프레시를 저장를 하는데, 굳이 똑같은 DB에다 저장할 필요는 없다. ( redis, nosql )
확인
확인
레이블
5주차
access token → 휘발성 ( stateless )
refresh token → 휘발성 ( stateless )
 
서버에서만 refresh token 을 관리한다 ( 클라이언트에 노출 시키지 말자 ) → DB든 or Redis or 파일 등으로 저장하자
 
DB에 부하가 가지 않을까?
 
 
디비에 쌓이면서 토큰에 대해 CRUD가 이뤄지는게 괜찮은지 궁금했습니다.(사용자가 많아지면?)
 
사용자가 많아지만 굳이 refresh token 이 아니더라도
 
“그냥 DB에 부하가 많이 생김” → 서로다른 DB를 쓰기
 
MySQL ⇒
MongoDB ⇒
Redis ⇒
 
감사합니닷
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
조금 궁금한 점은 서버에만 리프레시만 있다면 엑세스가 만료되더라도 확인없이 그냥 새로 발급해주는 느낌이라 공격자가 만료된 액세스를 가지더라도 새로 발급해주는 경우에요
→ 클라이언트에도 refresh가 있다면? 어떤 차이가 있을까요?
→ refresh도 탈취되면?
→ access탈취할 수 있는 사람이 refresh를 탈취를 못할까?
 
일반 요청에만 엑세스 토큰을 사용하고, 토큰 갱신시에만 리프레시토큰을 전달하기 때문에 노출될 가능성이 적어 비교적 안전하다라고 공부했던 것 같아요.