Skip to lesson
Exit
Deep Dive - Authentication Architecture1 / 2

2 min lesson

Secrets and the breach plan

Walk through the important items in "Secrets and the breach plan" and give the practical point of each.

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." Rotating the signing key logs out every user; bumping all token versions does the same. 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 runbook: rotate the key via JWKS (overlap so live sessions survive where safe), revoke the family of any tokens you believe compromised, force re-auth for the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. Press Enter for the full definition. and only then post-mortem 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.