DongHyeonkaandClaude Opus 5
aa2c3907f5
Adding a higher-priority RSA provider leaves both kids in JWKS, so tokens signed before and after the rotation both validate. Deleting the old provider makes its tokens 401 immediately, and the resource server's JWKS cache does not buy a grace period because an unknown kid triggers a refetch. The encryption key Q3 asks about does not exist yet, since B-2 showed the tokens are stored as plaintext JWTs, so the measured signing-key rotation is what its design has to copy: write with one key, read with several, and keep the overlap longer than the lifetime of anything signed with the old one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
17 lines
633 B
Plaintext
17 lines
633 B
Plaintext
=== [7] 옛 RSA 공급자(980ee9b7 = OY-caYDN 키) 제거 ===
|
|
제거 완료
|
|
|
|
=== [8] JWKS 에서 사라졌는가 ===
|
|
RS256 키 수: 1
|
|
{"keys":[{"kid":"1B4AQHoxZvFaQi1tc1byz8ifU-nYFB6engD4YB4Fz84"
|
|
{"kid":"gokjn0zFUok8r7JVqW1cxuyojH1bTT87vzfQG9RrFX4"
|
|
|
|
=== [9] ★ 옛 키로 서명된 토큰은 이제 어떻게 되는가 ===
|
|
옛 토큰 /api/me HTTP 401 (캐시가 살아 있으면 아직 통할 수 있다)
|
|
새 토큰 /api/me HTTP 200
|
|
|
|
=== [10] 리소스 서버를 재시작해 JWKS 캐시를 비우면 ===
|
|
deployment "echo" successfully rolled out
|
|
옛 토큰 /api/me HTTP 401
|
|
새 토큰 /api/me HTTP 200
|