[P2] [서버 연동] refresh 로 받은 새 토큰을 앱이 쓰지 못해 몇 시간 뒤 옛 토큰으로 갱신하다 강제 로그아웃된다 (SEC-05) #659

증상

#642(동시 refresh) 를 고친 뒤에도 prod 에서 강제 로그아웃이 하루 3~5건씩 계속됐습니다(서버 경보 SEC-05). 이번 모양은 동시 호출 경합이 아닙니다.

앱이 refresh 로 받은 새 토큰을 쓰지 못한 채, 몇 분~몇 시간 뒤 옛 refreshToken 으로 다시 refresh 합니다.

prod 에서 확인한 것 (10/29 ~ 11/02, 23건 · 20명)

서버 DB(refresh_tokens)와 요청 로그로 확인한 사실입니다.

다섯 건은 요청 순서를 직접 따라가 봤습니다.

1. 만료된 AT 로 GET /api/v1/challenges?filter=IN_PROGRESS 와 POST /api/v1/verifications/intro 가 거의 동시에 나가고 둘 다 401 입니다. 매번 이 두 호출입니다.
2. POST /api/v1/auth/refresh 를 한 번 보내고 서버는 200 으로 새 페어를 내려줍니다(서버에서는 회전 완료).
3. 그 뒤 앱의 동작은 경우마다 달랐습니다.
   • 3건은 새 AT 로 나간 요청이 하나도 없습니다. 새 토큰을 받지 못했거나 버린 것으로 보입니다.
   • 1건은 새 AT 로 요청을 계속 보냈습니다. 그런데 몇 시간 뒤 refresh 에는 옛 RT 를 냈습니다. 새 RT 가 저장되지 않은 것으로 보입니다.
4. 몇 분~몇 시간 뒤 1과 같은 두 호출이 다시 401 을 받고, 옛 RT 로 refresh 를 보냅니다. 서버는 이미 회전된 토큰의 재사용으로 보고 세션을 폐기했고(지금은 아래 「서버 쪽」 참고), 앱은 로그인 화면으로 갑니다.

앱에서 확인해 주실 것

원인은 서버에서 볼 수 없어서 아래는 의심 지점입니다.

• 1·4 의 두 호출(challenges?filter=IN_PROGRESS + verifications/intro)을 누가 부르는지 — 앱 진입인지 백그라운드 작업(WorkManager 등)인지. 백그라운드라면 refresh 응답을 받기 전에 작업이나 프로세스가 끝나는지 확인이 필요합니다.
• refresh 200 응답을 받고도 저장하지 못하는 경로
  • TokenRepositoryImpl.write() 는 IOException 을 로그만 남기고 삼킵니다. saveTokens 는 cachedAccess 를 먼저 바꾼 뒤 쓰기 때문에, 쓰기가 실패하면 「메모리엔 새 AT, 디스크엔 옛 RT」가 됩니다(위 3의 두 번째 경우와 같은 모양).
  • refresh 경로(saveTokensIfRefreshTokenMatches)가 false 를 돌려주는 경우에 새 페어가 버려지는지 확인 부탁드립니다.
• refresh 응답을 받지 못하거나 해석하지 못하는 경로
  • TokenAuthenticator 는 refresh 의 예외를 「일시 실패」로 보고 옛 토큰을 그대로 둡니다. 응답 파싱 예외(1.0.2 이후 R8 관련 [P1] [서버 연동] 1.0.2(10/24) 이후 FCM 기기 등록(POST /v1/devices)이 서버에 한 건도 오지 않아 푸시가 가지 않는다 #655 와 같은 계열인지), 타임아웃·취소도 여기로 옵니다.
• 위 분기마다 앱 로그(Observability)를 남겨 주시면 서버 로그와 맞춰 볼 수 있습니다.
  • refresh 시도 / 200 수신 / 저장 성공·실패 / 예외 종류
  • 앱 버전

서버 쪽 (확정된 내용)

• 11/02 19:32 KST prod 반영(Backend test(verification): 장소 검색·인트로 정책 매핑 #396): 회전 유예를 30초 → 12시간으로 늘렸습니다. 회전된 RT 가 12시간 안에 다시 오고, 그 회전으로 내려준 새 RT 가 아직 refresh 에 쓰이지 않았으면 세션을 끊지 않고 새 페어를 한 번 더 줍니다. 응답 형식은 같습니다.
• 그래서 위 사례는 지금 로그아웃되지 않습니다. 다만 이건 완충일 뿐입니다. 12시간을 넘기거나 새 RT 로 이미 refresh 한 뒤의 옛 RT 는 지금처럼 세션이 폐기됩니다. 이 창은 보안상 넓은 편이라 앱이 고쳐지면 다시 줄일 예정입니다.

완료 기준

• refresh 200 을 받은 뒤 다음 refresh 에 항상 그 응답의 새 RT 를 쓴다.
• 서버 지표 RefreshGraceReissueCount(유예로 재발급한 횟수)가 새 버전 보급 뒤 0 에 가까워진다. 서버가 이 지표를 보고 유예를 줄입니다.