JWT

토큰 사용 목적

1. 단일 토큰
   1. 로그인 성공 JWT 발급 서버 측 → 클라이언트로 JWT 발급
   2. 권한이 필요한 모든 요청 : 클라이언트 → 서버 측 JWT 전송
      권한이 필요한 요청은 서비스에서 많이 발생
      클라이언트 측 xxs나 http통신을 가로채서 토큰을 훔침 → 대비하기 위한 로직 필요
2. 다중 토큰 : refresh 토큰
   1. access/Refresh 토큰
   2. 생명주기를 짧게 발급 (약10분) , 토큰이 만료 되었을때 함께 받은 Refresh 토큰 (24시간) 토큰 재발급
      1. 로그인 성공시 2개 토큰
      - Access 토큰 : 권한이 필요한 모든 헤더에 사용될 JWT 생명주기를 짧게 함
      - Refresh 토큰 : 재발급을 위한 토큰으로 24시간 생명주기
      2. 권한이 필요한 모든요청은 Access 토큰을 사용
      3. Access 토큰이 만료될경우 Refresh 토큰을 검증 후 Access 토큰을 재발급

포인트

1. 로그인이 완료되면 successHandler에서 Access/Refresh 토큰 2개 발급해 응답
2. Access 토큰을 요청을 검증하는 JWTFilter에서 Access 토큰이 만료된 경우 상태 코드와 메시지를 응답
3. 프론트 측 API 요청 시 Access 토큰 만료 요청이 오면 예외문을 통해 Refresh 토큰을 서버 측으로 전송 → Acccess 토큰을 새로 받는 로직 수행
4. 서버측에서는 토큰을 받을 엔드 포인트 구성 Refresh 검증 후 Access를 응답
   • 단일 → 다중으로 전환되면 Access 토큰이 탈취되더라도 생명 주기가 짧아 피해가 줄어듬 ⇒ Refresh 토큰에 대한 보호 방법이 필요
   • Refresh 토큰 Rotate 에 대한 부분 ( Access 토큰 갱신 시 Refresh 토큰도 재발급 )
     • Access/Refrsh 토큰 저장 위치
       • 기존 저장 로직
         • 로컬 스토리지 : xss 공격에 취약 : Access 토큰 저장
         • httpOnly 쿠키 : CSRF 공격에 취약 : Refresh 토큰 저장

고려 사항

1. JWT의 탈취는 XSS 공격으로 로컬스토리지에 저장된 JWT를 가져감
   쿠키방식은 CSRF공격에 취약하기 대문에 저장소가 중요
2. Access 토큰
   보통 로컬 스토리지에 저장되고 짧은 생명주기
3. Refresh 토큰
   주로 쿠키에 저장 httpOnly를 설정하면 방어 가능
4. Refresh 토큰은 Rotate를 통해서 Access 토큰 발급 시 Refresh토큰도 갱신하여 방어 조치를 함

가장 강력한 보안

• 로그아웃을 할 때 Access/Refresh 토큰을 초기화하고 제거함
• Refresh 토큰 블랙리스팅