A service issues JWT access tokens signed with `secret-A`, each valid for 15 minutes, with no server-side record of issued tokens. At 10:00 the team deploys `secret-B` and updates the verifier to accept both secrets. What is the earliest moment it's safe to make the verifier stop accepting `secret-A`, and why is that moment forced rather than a judgment call?
10:15 — a full token lifetime after the deploy, not the moment secret-B goes live. The instant secret-B is deployed, tokens signed under the old secret-A are still out in the world — in browsers, in mobile clients, wherever they were issued before the rotation — and they stay valid until their own 15-minute expiry, completely independent of when the server-side rotation happened. If the verifier drops secret-A acceptance the moment secret-B goes live, every caller still holding an unexpired secret-A token gets rejected mid-session, turning a rotation that should be invisible into a self-inflicted mass sign-out. The last secret-A token could have been minted right up until 10:00, and it expires at 10:15 — only after that moment has every possible secret-A token actually expired, and only then is dropping secret-A acceptance harmless rather than disruptive.