API key lifecycle for Service Accounts

Phase 5 — API keys.

Today
No key mechanism exists. The legacy api-keys table is unrelated and is no longer honoured by the proxy.

Do

• Issue a key: shown once, bound to exactly one service account.
• Store expires_at (nullable) on the key record, not in the token. Default to a bounded expiry; allow "never expires" as an explicit choice with a visible warning.
• List, revoke, rotate, and record last-used.
• Allow expiry to be changed after issuance — extended for a workload that needs longer, shortened during an incident.

Done when
A key can be issued, used to obtain credentials, and revoked — with revocation taking effect within the stated cache TTL.

Watch

• Rotation has no overlap window, so renewal is issue-new → deploy → revoke-old.
• Expired and revoked must return the same client-visible outcome. Distinguishing them turns the endpoint into a key-validity oracle.
• Non-expiring keys depend on the proxy retaining every signing key it has ever used for verification (see ADR-013, "Signing Key and Rotation"). If verification keys are ever pruned on a current-plus-previous schedule, keys older than two rotations break silently regardless of their record.
• Auth failures should return one client-visible outcome plus a request id — distinguishing expired from revoked from unknown turns this into a key-validity oracle. That defence needs a matching latency floor, since rejecting locally is measurably faster than a lookup.

See ADR-013.

Depends on source-cooperative/source.coop#546.

Part of source-cooperative/source.coop#491.

Start by reading ADR-013, the dependency on source-cooperative/source.coop#546, and the related work in source-cooperative/source.coop#491. Define the lifecycle around issuance, use, listing, revocation, rotation, expiry changes, and last-used tracking. Done means a key can obtain credentials and revocation takes effect within the stated cache TTL, with uniform client-visible failures and a request id.