JWT의 Access Token과 Refresh Token

👉 JWT의 Access Token

---

• 사용자가 로그인한 후, 인증된 사용자인지를 확인하는 데 사용
• 서버는 이 토큰을 통해 사용자의 신원을 확인하고, 요청한 자원에 접근할 수 있는 권한이 있는지를 검증함
• 일반적으로 짧은 유효기간(몇 분에서 몇 시간 정도)을 가짐
  • ⇒ 탈취되어도 유효기간이 짧으면 공격자가 사용할 수 있는 시간이 제한되어 있기 때문
• 사용자가 로그인하여 특정 API 엔드 포인트에 데이터를 요청할 때, 클라이언트에서 Access Token을 헤더에 포함시켜 서버로 보냄 → 서버는 해당 토근을 검증하여 사용자의 요청 처리
  
  
  
  

👉 JWT의 Refresh Token

---

• Access Token의 유효기간이 만료되었을 때, 새로운 Access Token을 발급받기 위해 사용
  • ⇒ 이를 통해 사용자는 다시 로그인 할 필요 없이 지속적으로 서비스를 사용할 수 있음
• 일반적으로 긴 유효기간(며칠에서 몇 주, 심지어 몇 달) 또는 무기한 유효기간을 가질 수 있음
• Access Token이 만료되면 클라이언트는 Refresh Token을 이용해 서버에 새로운 Access Token을 요청 → 서버는 Refresh Token을 검증하고, 유효하다면 새로운 Access Token을 발급
  • ⇒ Access Token이 만료되기 전에는 Refresh Token을 주고 받는 경우가 거의 없어 탈취 위험에 비교적 안전
    
    
    
    

👉 Refresh Token의 유효기간이 만료되는 경우

---

• 사용자 세션이 종료된 것으로 간주해, 로그아웃 처리 되거나 인증이 필요한 자원에 접근 불가
• 재로그인을 진행하면, 새 Refresh Token과 Access Token이 발급됨
  
  
  
  

👉 Access Token과 Refresh Token 통신 과정

---

👉 Refresh Token 저장소 비교

---

저장 방식	장점	단점
Redis	빠른 읽기/쓰기 성능, 중앙 집중 관리, 세션 만료 기능	별도의 인프라 필요, 관리 복잡성 증가, 데이터 영속성 문제
RDBMS	쿼리 사용 가능, 기존 데이터와 통합 관리 가능	접근이 빈번한 경우 성능 이슈 발생 가능성, 확장성에 한계가 있을 수 있음, 보안 기능 부족
NoSQL	대량 데이터 처리 가능, 높은 확장성	일관성 관리 복잡, 제한된 쿼리 기능
서버 메모리	빠른 접근 속도, 구현 용이	데이터 소실 위험, 확장성에 한계가 있을 수 있음, 보안성 낮음
로컬 파일 시스템	구현 간단	확장성 부족, 접근 속도가 느릴 수 있음, 여러 서버 간 동기화가 어려움, 물리적 보안 위협에 취약할 수 있음
쿠키(HTTP-only)	자동 전송, XSS 공격 방어	CSRF 공격에 취약, 쿠키 크기 제한, 쿠키 만료 시 추가 처리 필요, 도메인 및 경로 제한 관리의 어려움

👉 Refresh Token을 Redis에 저장하는 이유

---

• Refresh Token은 소실되어도 사용자 경험 측면 외에는 크게 문제가 없음
  • ⇒ 인메모리 DB여도 문제 없음
• Redis는 인메모리 기반 데이터 저장소로, 매우 빠른 읽기 및 쓰기 성능을 갖고 있음
  • 빠르게 토큰을 검증하고 갱신할 수 있음
• Redis는 세션 데이터를 효과적으로 관리할 수 있음
  • 특히 여러 서버 인스턴스가 있는 분산 시스템에서 유용
  • 모든 서버 인스턴스가 동일한 Redis 인스턴스를 참조함으로써 세션 관리를 중앙집중식으로 처리할 수 있음
• Redis는 키에 대한 TTL(Time-To-Live) 설정을 지원
  • ⇒ Refresh Token의 유효기간을 쉽게 관리할 수 있음
• Redis는 분산 시스템에서 확장성이 좋음
  
  
  
  

👉 Refresh Token 탈취 위험 및 예방 방법

---

• 탈취 위험
  • Refresh Token이 탈취되면 공격자는 해당 토큰을 사용하여 새로운 Access Token을 지속적으로 발급받을 수 있음
    
    
• 예방 방법
  • 클라이언트 측에서 Refresh Token을 안전하게 저장
    • 예를 들어, LocalStorage나 SessionStorage가 아닌, HttpOnly 쿠키에 저장
    • HttpOnly 쿠키는 클라이언트 스크립트에서 접근할 수 없으므로 XSS 공격으로부터 보호
    • 하지만 LocalStorage나 SessionStorage에 비해 안전한 거지, HttpOnly 쿠키도 CSRF 공격에 취약
  • 모든 통신을 HTTPS로 암호화하여 네트워크 상에서 토큰이 탈취되지 않도록 함
  • Refresh Token의 유효기간을 적절히 짧게 설정
    • ⇒ 토큰이 탈취되더라도 오랜 기간 사용할 수 없도록
  • Refresh Token 요청 시 사용자의 IP 주소나 기기를 확인하여 이상 활동을 감지하면 토큰을 무효화
  • 의심스러운 활동이 감지되면 해당 Refresh Token을 블랙리스트에 추가하여 더 이상 사용할 수 없도록 함