Module api_key 

API keys — long-lived bearer tokens for service-to-service or mobile clients that don’t fit the cookie-session model.

Wire format: pk_<32-char-base64url> so they’re trivially distinguishable from session tokens (pylon_…) at a glance and in log greps. Verification stores the hash of the secret — the plaintext is shown to the user exactly once at create time and never again, same pattern as Stripe / GitHub PATs.

Key trust model:

• Each key belongs to one user (user_id).
• Optional name for the user to identify it (“CI”, “iOS app”).
• Optional scopes — comma-separated strings the application layer interprets. Pylon doesn’t enforce them; the host app’s policies do.
• Optional expires_at — when set, requests with the key are rejected after this Unix timestamp. None means no expiry (set + forget for trusted CI machines).
• Optional last_used_at — refreshed on every successful auth so the user can prune stale keys from a “remove unused for 90 days” sweep.

Storage is pluggable via ApiKeyBackend — the runtime swaps in SQLite/Postgres backends behind the scenes; the in-memory default is fine for tests + ephemeral dev servers.

Structs

ApiKey

One stored API key. The secret_hash is what’s persisted; the plaintext secret is returned to the caller exactly once at create time (see ApiKeyStore::create).

ApiKeyStore

InMemoryApiKeyBackend

Enums

ApiKeyVerifyError

Verification result — carries the matched key so the caller can inspect scopes / expiry without a second backend round-trip.

Traits

ApiKeyBackend

Storage backend for API keys. Same pluggable pattern as sessions