Auth in two KV lookups

Most auth systems involve a database, session tokens, JWT validation, or an OAuth dance. InboxKit does it with a SHA-256 hash and a single KV read.

The pattern

On signup, generate a random API key (ik_live_ + 32 hex chars). Store its SHA-256 hash in KV, pointing to the user's Durable Object ID. The raw key goes to the user and is never stored.

On every request, the auth middleware does three things:

const apiKey = header.slice(7);          // strip "Bearer "
const hash = await hashApiKey(apiKey);   // SHA-256 → hex
const doId = await env.API_KEYS.get(hash); // KV lookup

That's it. The middleware attaches the DO stub to the request context. Every downstream handler already has the authenticated user's inbox. No extra query.

Why SHA-256 is fine here

Passwords need bcrypt because humans pick weak ones. API keys are 128 bits of crypto.getRandomValues(). You can't brute-force that, even with SHA-256. High entropy in means fast hashing is safe.

Why this works on Workers

KV is globally replicated and eventually consistent. Reads are fast everywhere. Auth checks are read-heavy (every request) and write-rare (only signup). That's the exact workload KV is built for.

And because the KV value is a Durable Object ID, the auth lookup also resolves the user's data store. One read does two jobs: authenticate and route.