Retrieve a sign-in code without sharing its stored seed

A time-based authenticator generates changing codes from a stored seed. The original requirement was a service that would persist those seeds, authenticate callers and return the current code.

The service encrypts seeds in storage. Its code response contains the generated code and its expiry information, while the underlying seed stays out of that response.

Administrators can create account entries and issue access tokens. A reader token is tied to a particular entry; it cannot retrieve another entry's code through the reader route.

The service checks whether a token is active and whether it has expired before accepting it. Administrators can revoke tokens. Administrative operations and ordinary code retrieval use separate authorization checks.

The implementation also provides short-lived retrieval links. An administrator configures an expiry and a maximum use count within the service's allowed limits. Retrieval checks the link token, expiry, active state and recorded use count before returning a code.

Successful retrieval adds an audit event identifying the entry and how it was accessed. Code responses also instruct caches not to store them.

These capabilities extend the storage-and-retrieval requirement with narrower access and a record of use. A person or process can receive permission for a specific entry without receiving an administrative credential.

The service was implemented in March 2026 with database migrations, command-line helpers and container packaging. Validation covered authentication behavior, code generation, persistence and a running container's health.

By August 2026, operational checks recorded the deployed service with passing health and readiness checks. Its interface covers seed storage, controlled code retrieval and administration through an API and command-line tools.