[Supabase][인증] signing key rotation 중 긴급 revoke가 필요할 때 cache purge와 session invalidation을 어떤 순서로 같이 실행하나

IT 리서치 노트

[Supabase][인증] signing key rotation 중 긴급 revoke가 필요할 때 cache purge와 session invalidation을 어떤 순서로 같이 실행하나

Supabase signing key rotation을 운영하다 보면 정상 대기 시간을 지키는 것보다 더 어려운 순간이 있다. 바로 previous key를 빨리 끊어야 하는 긴급 revoke 상황이다. 2026년 8월 16일 기준 Supabase 공식 문서를 다시 보면 old JWT는 previous key를 수동 revoke하기 전까지 유효할 수 있고, JWKS는 edge와 client 경로에서 캐시되며, getClaims 같은 빠른 검증 경로도 캐시 특성을 전제로 한다. 이 글은 긴급 revoke가 필요할 때 cache purge와 session invalidation을 어떤 순서로 같이 실행해야 혼선을 줄일 수 있는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 Supabase 긴급 revoke는 verifier inventory, cache purge, session invalidation, previous key revoke 네 줄을 같은 시간축으로 움직여야 한다. previous key만 빨리 끊으면 stale verifier가 valid token을 거절할 수 있고, 반대로 revoke를 미루면 old JWT가 계속 통과할 수 있다.

정상 rotation은 기다리는 작업이지만 긴급 revoke는 기다릴 수 없는 작업이다. 그래서 purge와 세션 차단 절차를 아예 별도 runbook으로 가져가야 한다.

2. 어디서 실제로 막히는가

현장에서 자주 꼬이는 지점은 네 가지다. 첫째, previous key revoke만 먼저 실행하고 어떤 서비스가 JWKS를 캐시하는지 모른다. 둘째, cache purge 없이 session invalidation만 돌린다. 셋째, getClaims 경로와 custom jose verifier 경로를 같은 것으로 취급한다. 넷째, 긴급 사고인데도 정상 rotation의 20분 대기 runbook을 그대로 쓴다.

Supabase 문서는 old key가 수동 revoke 전까지 유효할 수 있다고 설명하고, JWT guide는 key 변경 시 최소 20분 대기와 과도한 앱 캐시 금지를 강조한다. 동시에 getClaims reference는 빠른 검증이 JWKS endpoint를 활용한다고 설명한다. 이 셋을 같이 읽으면 긴급 사고에서는 기다릴 수 없으므로, 어떤 verifier를 먼저 purge하고 어떤 세션을 먼저 끊을지 별도로 정리해야 한다는 결론이 나온다.

이미 old JWT 유예와 JWKS 캐시 글이 안전한 정상 rotation을 다뤘다면, 이번 글은 그 반대편이다. 정상 절차에서 안전장치였던 old key grace window가 긴급 사고에서는 리스크가 된다.

• 증상: previous key revoke 뒤에도 old JWT가 통과하거나, 반대로 일부 서비스가 valid token을 거절한다.
• 실패: verifier inventory 없이 revoke만 먼저 실행한다.
• 막힘: app cache purge와 session invalidation 시각을 같이 기록하지 않는다.
• 누락: 긴급 revoke와 정상 rotation을 다른 runbook으로 분리하지 않는다.

보이는 현상	먼저 볼 곳	판단 기준
old JWT가 계속 통과한다	revoke 시각과 purge 시각	stale cache가 남았는지 본다
valid token이 일부 서비스에서 거절된다	custom verifier inventory	새 key를 아직 못 본 verifier가 있는지 본다
사용자 세션이 오래 살아 있다	session invalidation 범위	세션 차단과 key revoke를 같이 계획했는지 본다

3. 실무에서 적용하는 순서

긴급 revoke 실무 순서는 다섯 단계가 가장 짧다. 먼저 모든 verifier 경로를 inventory로 적는다. 두 번째로 custom app cache purge와 edge-facing cache purge를 가능한 범위에서 먼저 실행한다. 세 번째로 세션 invalidation을 시작한다. 네 번째로 previous key revoke를 실행한다. 마지막으로 401 증가와 old JWT acceptance 감소를 각 verifier별로 다시 확인한다.

1. getClaims, custom JWKS verifier, direct Auth check 경로를 inventory로 적는다.
2. 앱 cache purge 시각을 먼저 남긴다.
3. 세션 invalidation 또는 강제 로그아웃 범위를 시작한다.
4. 그 뒤 previous key revoke를 실행한다.
5. 각 verifier의 401과 성공 비율을 따로 재확인한다.

운영자는 사고가 시작되면 verifier 목록을 먼저 조회하고, purge 가능한 캐시를 선택하고, cache purge를 실행하고, 세션 차단 범위를 메모에 입력하고, previous key revoke 시각을 별도 파일에 저장하고, 이후 각 서비스의 401 로그를 다시 확인해야 한다.

이 순서가 필요한 이유는 purge와 revoke의 역할이 다르기 때문이다. purge는 stale public key 신뢰를 줄이고, session invalidation은 이미 발급된 세션 사용을 줄이며, revoke는 old key 자체를 끊는다. 셋을 한 번에 적지 않으면 '왜 old JWT가 아직 통과하지'와 '왜 valid token이 갑자기 죽지'가 동시에 발생한다.

정상 rotation에서는 previous key revoke를 마지막 단계로 두지만, 긴급 사고에서는 그 순서를 앞당길 수 있다. 대신 그만큼 stale verifier 리스크가 커지므로 purge와 verifier inventory를 먼저 두는 편이 낫다. 이미 Verify JWT와 getClaims cutover 글을 정리해 두었다면, 그 inventory를 그대로 비상 절차의 첫 단계로 가져오면 된다.

긴급 revoke 체크 메모

verifier_inventory_done=true
cache_purge_started_at=2026-08-16T14:12:00+09:00
session_invalidation_started_at=2026-08-16T14:13:00+09:00
previous_key_revoked_at=2026-08-16T14:15:00+09:00
post_revoke_check_1=getClaims path
post_revoke_check_2=custom backend path

이 정도 메모만 남겨도 사고 후반에 어떤 경로가 stale cache를 들고 있었는지, 세션 차단이 충분했는지, revoke를 너무 빨리 했는지 재검증이 훨씬 쉬워진다.

4. 공식 문서와 예시 화면으로 확인하기

첫 공식 자료는 Signing keys 문서의 old key 전제다. Supabase는 old key로 서명된 JWT가 previous key를 수동 revoke하기 전까지는 계속 유효할 수 있다고 적고 있다.

Supabase는 previous key를 수동 revoke하기 전까지 old JWT가 계속 유효할 수 있다고 설명한다.

정상 rotation에서는 이 성질이 안전장치가 되지만, 긴급 사고에서는 바로 문제가 된다. 그래서 urgent revoke는 normal rotation runbook과 분리해야 한다.

두 번째 자료는 JWT guide의 cache 경고다. Supabase는 standby key 생성이나 previous key revoke 때 최소 20분을 기다리라고 권장하고, 애플리케이션이 JWKS 데이터를 더 오래 캐시하지 말라고 적는다.

Supabase JWT guide는 key 변경 시 최소 20분 대기와 과도한 앱 캐시 금지를 함께 권장한다.

즉 긴급 revoke는 'rotate 버튼을 누르면 끝'이 아니라 cache purge와 verifier inventory를 동반해야 하는 사건이다. 앱 쪽 캐시가 더 길면 Supabase edge cache보다 더 오래 남는다.

세 번째 자료는 getClaims reference다. Supabase client 쪽 빠른 검증도 결국 JWKS endpoint 캐시 특성에 기대기 때문에 긴급 revoke 사고에서 검증 경로 inventory가 중요해진다.

getClaims는 JWKS endpoint를 활용한 빠른 검증 경로이며, 이 역시 캐시 특성을 고려해야 한다.

팀 안에서 getClaims, custom jose verifier, Auth server 직접 확인 경로가 섞여 있으면 revoke 직후 동작이 달라진다. verifier inventory가 먼저인 이유가 여기에 있다.

긴급 revoke와 정상 rotation은 순서가 다르다. 정상 rotation은 기다렸다가 revoke하는 흐름이고, 긴급 사고는 purge와 session invalidation을 동반한 비상 절차가 먼저다.

정상 rotation과 긴급 revoke를 verifier, purge, session invalidation 기준으로 나눈 표다.

이 표는 old JWT 유예와 JWKS 캐시 글 다음 단계다. 이전 글이 안전한 대기 시간을 다뤘다면, 이번 글은 기다릴 수 없는 사고에서 무엇을 동시에 움직일지 다룬다.

마지막 자료는 실제 incident 메모 예시다. 키 회전과 세션 차단과 캐시 purge를 같은 시간축에 적지 않으면 어떤 verifier가 old key를 계속 믿는지 다시 재구성하기 어렵다.

긴급 revoke incident에서 verifier inventory와 purge, session invalidation을 함께 적는 최소 메모 예시다.

이미 Verify JWT와 getClaims cutover 글을 읽었다면, 이번 메모는 그 inventory를 비상 절차로 연결하는 버전이다. verifier 경로를 모르면 purge 우선순위도 정할 수 없다.

5. 주의사항과 리스크

첫 번째 리스크는 purge보다 revoke를 먼저 해 버리는 것이다. 두 번째 리스크는 세션 invalidation 없이 key만 끊는 것이다. 세 번째 리스크는 custom verifier를 인벤토리하지 않고 getClaims 경로만 기준으로 판단하는 것이다.

• 긴급 revoke는 verifier inventory가 먼저다.
• cache purge와 session invalidation은 separate task가 아니라 동시 작업이다.
• 정상 rotation runbook을 그대로 쓰면 사고가 길어진다.

6. 결론

Supabase 긴급 revoke에서 중요한 것은 previous key revoke 버튼 자체가 아니라 그 앞뒤에 있는 purge와 세션 차단 순서다. verifier inventory를 먼저 만들고 purge와 session invalidation을 같이 돌린 뒤 revoke를 실행해야 stale cache와 old JWT를 더 짧게 줄일 수 있다.

• verifier inventory를 먼저 적는다.
• cache purge와 session invalidation을 같이 시작한다.
• previous key revoke는 그 다음 시간축에 놓는다.

긴급 purge와 session invalidation 절차를 이미 분리했다면, 정상 운영 쪽에서는 Edge Functions와 custom backend verifier의 JWKS cache window를 별도 시간축으로 적는 follow-up 글로 이어서 verifier별 회복 시각을 따로 남겨 두는 편이 안전하다.

7. 참고 링크

1. https://supabase.com/docs/guides/auth/signing-keys
2. https://supabase.com/docs/guides/auth/jwts
3. https://supabase.com/docs/reference/javascript/auth-getclaims