갱신 토큰을 회전시키는 서버가 정상 동시 갱신과 탈취 재사용을 어떻게 구분하고 차단하나요?

갱신 토큰 회전은 한 번 사용한 refresh token을 새 토큰으로 바꾸고 이전 토큰을 다시 사용했는지 기록하는 방식입니다. 정상 사용자의 응답 유실과 여러 탭의 동시 갱신도 오래된 토큰 재사용처럼 보일 수 있으므로, 재사용을 무조건 공격으로 단정하지 않으면서도 오래된 bearer를 무제한 허용해서는 안 됩니다. 서버는 토큰 계열의 원자적 전환, 정상 재시도의 복구 방식, 의심되는 재사용의 회수 범위를 함께 설계해야 합니다.

원문 검증 상태와 재시도 결과를 분리합니다

서버에는 refresh token 원문 대신 검증용 hash, family ID, 현재 버전 또는 predecessor·successor 관계, 기기 세션, 만료·폐기 상태를 저장할 수 있습니다. 클라이언트가 현재 토큰을 보내면 조건부 갱신으로 한 요청만 기존 상태를 소비하고 새 access token과 refresh token을 발급합니다. 두 요청이 같은 토큰으로 동시에 오면 하나만 전환에 성공해야 합니다. 이 hash만으로는 이전 요청에서 발급한 access/refresh 결과 원문을 다시 복원할 수 없으므로, 응답 유실을 정상적으로 재시도시키려면 선택지가 별도로 필요합니다.

첫째, 아주 짧은 시간 동안 요청 ID에 대응하는 결과를 암호화해 보관하고 같은 기기 세션의 재시도에 한해 다시 전달할 수 있습니다. 둘째, 결과 원문을 재전달하지 않고 클라이언트가 안전한 재로그인을 하도록 UX를 설계할 수 있습니다. 결과 캐시를 둔다면 공격자가 bearer token과 request ID를 함께 복제할 수 있으므로 request ID는 인증 수단이 아닙니다. IP 주소나 User-Agent·기기 문자열도 확증 증거가 아니며, 보조 신호일 뿐입니다. 캐시에는 짧은 TTL·세션 바인딩·재전달 횟수 제한을 두고, 토큰 원문이 로그나 일반 DB에 남지 않게 하겠습니다.

탈취 재사용과 정상 동시성을 나눕니다

정상 회전 뒤 이전 토큰이 유예 범위를 벗어나 들어오거나, 서로 다른 세션에서 같은 family를 사용하면 복제 가능성을 높게 봅니다. 동일 요청 ID가 맞더라도 bearer 자체가 복제될 수 있으므로 ‘ID가 같으니 안전하다’고 판단하지 않습니다. 검증된 세션·기기 상태, 시간 간격, 이미 결과를 전달했는지, 비정상적인 재사용 패턴을 조합해 유예를 좁게 정합니다. 멀티 탭은 클라이언트에서 갱신을 한 곳으로 직렬화하고, 서버는 중복 요청을 한 번의 상태 전환으로 처리하는 이중 방어를 둡니다.

확실한 비정상 재사용이면 해당 family 또는 기기 세션을 폐기하고 재인증을 요구할 수 있습니다. 계정 전체 회수는 다른 기기까지 끊는 비용이 있으므로 위험 수준과 관측 근거로 결정합니다. 회전은 이미 발급된 짧은 access token을 되돌리지 않으므로, 즉시 무효화가 필요하면 매 요청의 차단 상태·토큰 버전 검사를 별도로 둡니다. 짧은 access token 수명은 남은 사용 가능 시간을 줄이지만 즉시 무효화는 아닙니다.

로그에는 원문 대신 family·세션 식별자, 회전 버전, 정상·유예·재사용 판정과 회수 결과만 기록합니다. 동시 갱신, 응답 유실, 유예 밖 재사용, 여러 기기의 정상 갱신, 저장소 복제 지연·재시작, family 회수 뒤 access token 사용을 재현하겠습니다. 성공 기준은 이전 토큰을 거절하는 것 하나가 아니라, 정상 사용자의 불필요한 로그아웃을 줄이면서 bearer 탈취의 탐지·회수 지연을 제한하는 것입니다.

재시도 유예의 상태는 서버 여러 인스턴스가 공유해야 하며, 한 인스턴스의 메모리에만 두면 다른 인스턴스로 재전송한 요청이 공격으로 오판되거나 반대로 중복 성공할 수 있습니다. 결과 캐시가 탈취된 응답을 오래 보관하지 않도록 암호화 키의 접근 범위와 폐기 시점도 정합니다. 캐시를 사용하지 않는 재로그인 경로를 두면 사용자에게 결과가 불확실하다는 사실을 설명하고, 이전 요청이 서버에서 성공했는지 조회할 수 있는 세션·회전 상태를 제공하겠습니다.