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>
B-6 — key 회전 증거
2026-09-04 15:50–16:00 KST
해설: docs/experiment-b6-key-rotation.md
| 파일 | 무엇을 보여주는가 |
|---|---|
01-before-rotation.txt |
회전 전 — 토큰 kid=OY-caYDN..., JWKS RS256 1개, /api/me 200 |
02-rotation.txt |
우선순위 200 공급자 추가 → JWKS RS256 2개, 새 토큰은 새 kid, 옛 토큰도 새 토큰도 200 (무중단) |
03-old-key-removed.txt |
옛 공급자 제거 → JWKS 1개, 옛 토큰 즉시 401. 리소스 서버 재시작 후에도 동일 |
핵심 세 줄
- Keycloak 의 키 회전은 "바꾸기"가 아니라 "더 높은 우선순위로 추가하기" 다. 추가만으로는 아무것도 안 깨진다.
- 위험한 것은 옛 키를 버리는 시점이다. 제거 즉시 그 키로 서명된 토큰이 401 이 된다.
- 캐시는 유예가 아니다. 모르는
kid를 만나면 JWKS 를 다시 받으므로 제거가 곧바로 반영된다. 유예는 옛 키를 남겨두는 기간으로 만들어야 한다.