Two SDKs. Same auth.
The browser SDK runs in your customer's UI — provider, hooks, OAuth redirect catching. The server SDK runs in your backend — verifies the JWTs the browser SDK hands you. They share types from @tilldev/auth-types so the user object is identical on both sides.
React SDK
@tilldev/auth-react
Provider + hooks for SPAs and Next.js apps. Auto-refreshes tokens, catches OAuth fragments, exposes a session object that's identical to what the server verifier returns.
TillAuthProvider— root wrapper, manages the session.useSignIn·useSignUp·useSession·useSignOutuseMfa·usePasskey·useOAuth— opt-in, one hook each.- Built for React 18+, works in React 19. Zero dependencies beyond React itself.
pnpm add @tilldev/auth-reactNode SDK
@tilldev/auth-node
JWT verifier, Express middleware, cookie-proxy helper. Pulls the public key from your app's JWKS endpoint and caches it; no shared secrets in your backend.
verify(token)— returns the typed user or throws.tillauth.express()— middleware that putsreq.useron the request.cookieProxy()— same-origin cookie bridge for custom domains.- Pure-Node, no native deps. Works in Node 18+, Bun, Workers, Deno.
pnpm add @tilldev/auth-nodePick the one closest to where the user lives
If your frontend is React, install @tilldev/auth-react. If you have a Node backend that needs to know who a request belongs to, install @tilldev/auth-node. Most real apps end up with both.
Frontend in something other than React? The browser SDK is a thin wrapper around a documented REST API — anything that can fetch can drive TillAuth. See the quickstart for the raw HTTP shape, and ping us if you want a first-party Vue / Svelte / Solid SDK on the roadmap.
Versioning
Both SDKs are at 0.x during the public beta. Minor versions can change types; the underlying REST API stays stable across minor bumps. We hit 1.0 when the type surface freezes — see the changelog.