mirror of
https://github.com/nestriness/nestri.git
synced 2026-09-19 17:25:19 +03:00
The issuer kept everything behind one get/set/remove/scan interface, which is what a library that must run on any provider's cache can offer. Three of the things kept there could not actually be served by it. An authorization code must be redeemable once and a refresh token spendable once, and through get and set the check and the write are separate steps — so two requests arriving together both read an unspent record, and both mint a session. In the refresh case that also means the reuse which reveals a stolen token is never recorded, because recording it is the write that the second caller overwrites. Each now has a table and an interface of its own: redeeming is one `delete ... returning`, spending is one `update ... where time_used is null returning *`, so exactly one caller is ever told it went first. This is the same argument the device grant already made, applied to the two records that had it too. Signing keys move for a different reason. Nothing races for them; they are the one record whose loss ends every session at once, and a cache is a place things may be evicted from. They are retired by setting a column rather than deleted, so the tokens they signed stay verifiable until they expire. Both credential tables store a hash and never the credential, as the device grant does. An authorization code travels in a query string and so passes through history, referrer headers and any log along the redirect; a refresh token resumes a session outright. What is left in the generic store is the rate-limit counters — written far more often than read, meaningless within the hour, and allowed to be approximate, since a lost increment costs one guess out of ten. Those move to Postgres too, so the only key-value binding this deploys with is gone and the control plane's state is one database. That was the point: nothing here now depends on a primitive a self-hoster cannot run. The generic scan also gained the separator on its prefix, so scanning `a` cannot return what is under `ab` — subjects and email addresses are both prefixes of longer subjects and email addresses. Deploying this signs everyone out. The signing keys and refresh tokens are in a store that is being left behind, so the issuer starts with a fresh key set and every existing token stops verifying.
packages/auth (@nestri/auth)
Framework-agnostic OpenAuth implementation for Nestri — the OAuth/OIDC issuer, client, subjects, and the login UI. A vendored/forked build of OpenAuth.
What it does
Everything needed to run your own authentication provider:
issuer.ts— the authorization server: routes for/authorize,/callback,/token,/userinfo,.well-known/*, plus the login UI (React renderer).client.ts—createClientto verify JWTs against the issuer ("who is this token?").subject.ts— typed JWT subjects (zodschemas for the token payload).provider/*— drop-in OAuth/OIDC providers (steam, discord, github, google, apple, microsoft, slack, spotify, twitch, x, yahoo, facebook, linkedin, cognito, keycloak, jumpcloud, oauth2, oidc, password, ssh, code, arctic).storage/*— persistence adapters for keys/sessions/codes:memory,cloudflare(KV),aws,dynamo.ui/*— the login page components (forms, password, code, theme, CSS).jwt.ts,keys.ts,pkce.ts,random.ts— signing, keypair management, PKCE, randomness.
Usage
Consumed by the apps/auth worker, e.g.:
import { issuer } from '@nestri/auth/index';
import { CloudflareStorage } from '@nestri/auth/storage/cloudflare';
import { SteamProvider } from '@nestri/auth/provider/steam';
The API uses createClient (from @openauth/openauth/client) or the bundled client.ts to verify
tokens against the issuer URL.
Scripts
bun test # run tests
bun run build # build (see script/build.ts)
Note
@openauthjs is the upstream project; this package's exports are meant to be API-compatible with a
pinned preference toward tree-shaking-friendly imports. Prefer importing subpaths over the barrel
(@nestri/auth/index).