Skip to lesson
Exit
Deep Dive: Authentication Architecture1 / 2

2 min lesson

Secrets and the breach plan

Take this situation. "A signing key leaked. Do you run the normal add / cut over / drain / retire rotation?" Lead with your decision, then add the reason.

Step 1 of 2

Secrets and the breach planthe operational half

  • Signing keys never ship to clients. A public client verifies nothing with a private key; it only holds short-lived tokens. Private keys live in a KMS or secrets manager, scoped to the issuing service.
  • SCM provider credentials rotate too. The GitHub/GitLab app secrets and webhook signing secrets your integrations depend on are secrets like any other. Put them on a rotation schedule and store them in the same vault.
  • Know your blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. before the breach. Have an answer to "how fast can we invalidate everything and what breaks when we do." Emergency rotation (retire the old key with no drain) fails every access token at once. Clients with live refresh tokens recover silently; bumping every token_version forces everyone to log in again. Practice it so the answer in the incident is muscle memory, not a debate.
Interview move

If asked "a signing key leaked at 2am, what now," walk the emergency runbook. Publish a new key and remove the leaked one from JWKS immediately, with no drain step, because an overlap window would keep verifying tokens the attacker can forge. Every access token signed with the leaked key fails at once, and clients holding a valid refresh token recover by refreshing into new-key tokens. Revoke the token families you suspect, force re-auth for that blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition., and only then run the post-mortem on how the key escaped. Showing you've thought about the recovery, not just the prevention, is the senior signal.

Verify your design

A sound rotation design answers all four: tokens stay verifiable mid-rollover (JWKS + kid overlap), a stolen refresh token self-destructs (reuse detection), an individual can be revoked fast (short TTL + version or deny-list) and a full invalidation is a known, rehearsed operation. If any one is missing, name it as a gap rather than hoping nobody asks.