Week ending 2026-05-12. Owner: platform team.
Refresh failures climbed from ~320/day to 412/day this week (+27%). Early signal: about 60% of failures share a small set of UA strings consistent with one mobile build that's caching tokens past expiry.
Plan: reach out to the mobile lead, gather build numbers, and decide whether to ship a server-side mitigation or wait for the next mobile release.
Production rotation is scheduled for 2026-05-21 03:00 UTC. JWKS cache TTL is 5 min; we expect a ≤5min window where some clients still trust the old key. Mitigation: pre-warm the new key at JWKS for 24h ahead.
Cutover is dual-write for 48h then primary switch. Rollback path: flip a single DSN and replay the WAL.
We picked opaque refresh tokens stored server-side. Reasoning: refresh tokens get reused, replayed, and revoked far more than access tokens; the size and signature cost of JWT buys us nothing for that role.
Access tokens remain JWT (EdDSA) so service-to-service paths stay stateless.
One first-party client requested device flow for a CLI tool. We deferred — the use case is satisfied by a long-lived API token with scope restrictions, which is simpler and already supported. Revisit in Q3 if a second client asks.