How should an automated case at a service interface obtain and refresh its access token?

Authentication is infrastructure for a case at a machine interface, and the design goal is that no case ever mentions a token. What a case declares is an identity — "as a gate agent", "as a self-service passenger" — and the harness turns that into a credential on every request. Getting this wrong produces two characteristic disasters: a suite that dies halfway through with a wall of unauthorized failures, and a suite whose green run proves nothing because one over-privileged identity was doing everything. ## Acquire, do not paste A token pasted into a configuration file or a constant is dead on arrival: it expires, it is a secret in version control, and it silently encodes whichever identity the person who pasted it happened to hold. Acquire it by calling the token-issuing endpoint with credentials the runner injects from a secret store or environment. There must be no committed fallback value — a default that quietly works locally is exactly how a real credential ends up in a repository. If the environment does not supply credentials, the suite should fail loudly at setup with a message naming the missing variable, not skip cases or fall back to an anonymous call. ## Cache per identity, not per case Fetching a token per request turns every case into two calls and puts the identity provider on the critical path of the whole run. Fetch once per identity per run and cache it. Keying the cache by identity matters as much as the caching: on an airline seat-map service an 11-person team ran cases for gate agents, ground staff and passengers through a single shared token because it was the one that worked. Half the suite was asserting behaviour the real caller could never reach, and a permission regression stayed invisible for weeks. One token per identity makes the case's caller explicit and makes an accidental privilege change fail somewhere. ## Refresh proactively, with a margin The classic failure is arithmetic: a token that lives 890 seconds against a suite that takes 23 minutes. The last third of the run fails with unauthorized responses, and because the failures cluster, the team reads them as an authorization regression and spends a morning on it. The fix is a proactive refresh — before issuing a request, if the token's remaining lifetime is below a safety margin comfortably larger than the slowest expected request, fetch a new one. The margin exists because a token that is valid when the client checks can expire in flight. A reactive refresh is a useful backstop: on a single unauthorized response, refresh once and retry once. Two rules keep it honest. It must not apply to a forbidden response, because that outcome is about what the identity may do, and a new token for the same identity will not change it — retrying there just hides a real authorization result. And it must be bounded to one attempt, or a genuine authentication defect turns into a slow loop that eventually reports a timeout instead of the actual cause. ## Parallel workers and shared caches When the suite runs in parallel, a shared token cache can stampede: several workers notice the same expiry at the same moment and all call the token endpoint, sometimes tripping the identity provider's own rate limit. Either guard the refresh so one caller performs it while the others wait, or give each worker its own token. Per-worker tokens are simpler and usually cheap; a shared cache is worth the coordination only when issuing a token is expensive or throttled. ## Cases that are about authentication A case asserting that an expired or missing token is rejected is a case the refresh machinery will happily repair into a false pass. Those cases have to opt out of automatic acquisition and refresh, and it is worth making the opt-out explicit in the case name, because a future reader who sees an unauthorized assertion will otherwise assume it is a harness bug. Keep such cases about the authentication mechanism itself — what a given identity is permitted to do, and how that permission grid is captured as an artefact, is a different concern with its own home. ## Hygiene Redact the token everywhere it might surface: request logs, failure artefacts, captured traffic, the report attachment that helpfully includes the headers. Prefer short-lived test identities per environment, created and removed by the environment's own provisioning, over long-lived shared accounts whose password nobody dares rotate. And never point a suite at credentials issued for the production environment, even for a read-only case — the blast radius of a mistaken write is not worth the convenience, and the presence of those credentials in a runner is itself the risk.