Konvoa Engineering
One-time download tickets for protected software delivery
Designing short-lived release delivery so a copied URL is not a reusable entitlement or an authorization bypass.
Separate authorization from byte delivery
A protected file endpoint has two jobs with different risk profiles. First, decide whether the current user, license, device, subscription, scope, and session may obtain a particular release. Second, move potentially large bytes without repeating sensitive credentials in a URL or holding a long database transaction open.
A short-lived one-time ticket connects those jobs. The authenticated client requests access to a file identifier. After the full authorization decision passes, the service creates an opaque random ticket bound to that decision and returns it to the client.
Bind the ticket to enough context
Store a one-way hash of the ticket rather than the bearer value itself. Associate it with the application, user, license, active session, device-key thumbprint, file identifier, issue request, creation time, and hard expiry. If the download route also receives the current access proof, compare those subjects before consuming the ticket.
Do not accept a caller-provided remote URL as the protected file source. Keep an allowlisted local release store or a tightly controlled object-storage integration. Otherwise an account may turn the service into a server-side request-forgery proxy or cause credentials to be sent to an unintended host.
Consume before returning the file
The ticket transition from unused to consumed must be atomic. Mark it consumed only when the expected subject and unexpired ticket match, and ensure concurrent attempts cannot both succeed. The response can then stream the mapped file. If delivery fails after consumption, issue a new ticket through the authenticated authorization endpoint rather than reviving the old one.
This ordering prefers security over automatic retry. A client can recover by requesting a fresh ticket, while a captured value cannot be replayed repeatedly. Keep the expiry short—often tens of seconds—because the ticket only bridges two adjacent requests.
Protect the bytes and metadata
Always use HTTPS and reject redirects in clients carrying authorization material. Set a specific content type, a safe attachment filename, nosniff, and private no-store caching headers. Enforce server-side file-size limits and stream with backpressure so a large release does not become an easy memory-exhaustion path.
If the protocol encrypts file responses at the application layer, authenticate the encrypted envelope and bind its response signature to the original request identifier. The client should verify the service signature before accepting or decrypting any bytes.
Make revocation reach pending tickets
A ticket represents a recent authorization decision, so its lifetime is intentionally small. Even so, a license revocation or account ban should invalidate unused tickets tied to that entitlement. The same lifecycle operation that closes sessions and refresh families can mark outstanding tickets unusable.
Log ticket issuance and consumption using opaque identifiers and bounded metadata. Avoid logging bearer values, customer passwords, device private keys, full license keys, or complete download contents. Retention should be explicit so hostile traffic cannot grow audit storage without limit.
Test race and recovery behavior
Exercise two simultaneous downloads with the same ticket, use after expiry, use for a different file, use from a different device key, revocation between issue and consume, interrupted streaming, oversized files, and a mapped file that disappears. The API should return stable error codes without revealing whether another account owns a guessed identifier.
A protected URL is not enough. A production delivery path makes the authorization decision explicit, gives it a narrow one-time capability, and keeps the capability bound to the session that earned it.