🥬 상추

로그인 상태 유지 프로세스 공유

• 클라이언트는 id와 비밀번호를 작성하여 서버로 로그인 요청을 보내고 서버는 DB에 저장된 사용자와 대조하여 검증을 진행한 뒤 유저 id, 프로필 사진 등의 유저 정보와 함께 액세스 토큰 , 리프레시 토큰을 바디에 담아 클라이언트에 전달한다.
• 클라이언트는 인가가 필요한 api 요청을 할 때마다 액세스 토큰을 Authorization 헤더에 담아 보내줘야함.
• 서버는 액세스 토큰을 검증하고 만약 토큰이 유효하지 않다면 (만료되거나 위변조) 클라이언트에 401 응답을 내보낸다.
• 클라이언트는 401 응답을 받으면 리프레시 토큰을 헤더에 담아 /api/login/refresh 로 POST 요청을 보낸다.
• 서버는 리프레시 토큰의 유효성을 검증한 뒤 액세스 토큰을 클라이언트에 다시 발급한다.
  • 리프레시 토큰 검증시 서버는 db 혹은 redis에 저장되어 있는 토큰과 정확히 일치하는지 확인한다.
• 토큰을 탈취당했거나 로그아웃을 시도할 경우 /api/logout 으로 refreshToken을 Authorization 헤더에 담아 보낸다.

리프레시 토큰을 서버에서 저장하고 있어야 하는 이유?

<aside> 💡 궁금한게 있어. 리프레시 토큰을 서버의 db나 redis에 저장해야한다고 보통 얘기하잖아? 근데 리프레시 토큰이 실제로 저장되었는지 왜 확인해야해? 일반적으로 클라이언트가 보낸 리프레시 토큰이 유효한지 검증만 하면 되는거 아니야? 혹시 사용자가 리프레시 토큰을 탈취당했다고 하면 서버에서 db에 있는 리프레시 토큰을 삭제함으로써 보안을 강화할수 있기 때문이야?

</aside>

1. 토큰 리볼크(Token Revocation)

• 보안 위반: 리프레시 토큰이 탈취되었거나, 사용자가 기기를 분실한 경우, 서버에 저장된 토큰을 즉시 무효화시켜 추가 피해를 방지할 수 있습니다.
• 사용자 로그아웃: 사용자가 명시적으로 로그아웃할 때, 리프레시 토큰을 데이터베이스에서 삭제하거나 무효화함으로써, 해당 사용자의 세션을 완전히 종료할 수 있습니다.

2. 유효성 검증 및 관리

• 토큰 유효성 검증: 클라이언트가 제공한 리프레시 토큰이 서버에 저장된 토큰과 일치하는지 확인함으로써, 토큰이 서버에서 발급된 것이 맞는지 검증할 수 있습니다.
• 중복 사용 방지: 저장된 토큰을 통해 리프레시 토큰의 재사용을 감지하고 이를 방지할 수 있습니다. 이는 토큰이 복제되어 사용되는 것을 막는 데 도움이 됩니다.

3. 보안 강화

• 조건부 접근 제어: 서버에서는 리프레시 토큰의 저장 여부를 통해 사용자의 접근을 조건부로 제어할 수 있습니다. 예를 들어, 특정 조건 하에서 사용자의 접근을 제한하거나 추가 검증을 요구할 수 있습니다.

4. 사용자 활동 모니터링