A persisted account link. Schema-aligned with better-auth’s account
table (verified against https://www.better-auth.com/docs/concepts/database
at the time of writing) so users migrating from better-auth see the
same field names + meanings:
In-memory account backend (default). Lost on restart — production
deployments should swap in a persistent backend so refresh tokens
survive a redeploy.
A magic-code store. Wraps a MagicCodeBackend (in-memory by default)
and applies the verify/cooldown semantics. Hydrates the in-memory
cache from the backend on construction so durable backends survive
restart without losing in-flight codes.
Token bundle returned by OAuthConfig::exchange_code_full. Stored
on the matching Account row so refresh_token is available for
silent re-auth and expires_at is checked before each provider call.
Resolved identity returned by OAuthConfig::fetch_userinfo_full.
provider_account_id is the provider-stable subject id (Google sub,
GitHub numeric id) — what the account store keys on so a renamed
email doesn’t orphan the pylon account.
Pluggable storage for magic-code records. In-memory is the default
(fine for dev); persistent backends (SQLite, Postgres) live in
pylon-runtime so a server restart between “send code” and “verify
code” doesn’t invalidate the user’s pending login.
Backing store for OAuth state tokens. Default impl keeps them in memory
(fine for tests + dev); the runtime swaps in a SQLite-backed impl so a
restart in the middle of an OAuth handshake doesn’t leave the user with
“invalid state” on the callback. Same pattern as SessionBackend.
Pluggable storage backend for sessions. The default is in-memory; apps
deploying for real should supply a persistent backend (e.g. SQLite or
Redis) so users don’t log out on server restart.