Rotation, Revocation, Safe Logging and Incident Tests

Design the recovery path before launch

A production identity system needs rotation, revocation, audit and containment. These are part of the security model, not later operational polish.

Rotation and revocation

• Rotate signing keys with safe overlap and bounded metadata caches.
• Keep access-token lifetimes short enough for the threat model.
• Rotate refresh tokens on use and detect replay; revoke the token family when reuse is detected.
• Revoke server-side sessions after password reset, account disable or high-risk role changes.
• Prefer workload identity or managed secret stores; do not copy long-lived secrets into source control or client bundles.

Safe observability

Log correlation ID, issuer, client identifier, a safe subject pseudonym, policy name and outcome. Do not log raw access tokens, authorization codes, refresh tokens, passwords or signing keys.

Distinguish authentication failure, authorization denial, metadata refresh failure and provider outage. A single 401 counter hides the failure mode responders need.

Incident scenario

A refresh token is replayed from a new location. The service should reject reuse, revoke the token family, mark the session for investigation, require reauthentication when appropriate and preserve safe audit evidence. Rotating every signing key may be unnecessary unless key compromise is suspected.

Production test set

1. Wrong issuer and audience are rejected.
2. Expired and not-yet-valid tokens are rejected.
3. Unknown signing key triggers bounded metadata refresh and then fails closed.
4. Cross-tenant resource IDs are denied without leaking existence.
5. Replayed refresh token revokes the family.
6. Logs contain correlation and decision data but no secrets.
7. Identity-provider metadata outage follows a documented resilience policy.

The senior-level answer connects prevention, detection, containment and recovery, then explains the trade-off between rapid revocation and distributed-system availability.