TILLAUTH · BUILD

Workers + edge runtimes.

Your API runs on workerd, not Node? Nothing changes. The verifier in @tillstack/auth-node is built on jose — Web Crypto and fetch, no Node APIs — so it runs on Cloudflare Workers, Deno and Bun unchanged. The “node” names the packaging default, not the runtime.

01Verify

Gate a Worker route

import { createVerifier, TillAuthVerifyError } from '@tillstack/auth-node'

const verifier = createVerifier({
  appId: 'tau_your_app_id',        // your app's public id
  // requireMfa: true,             // optional gates, enforced per request
  // requireVerifiedEmail: true,
})

export default {
  async fetch(req: Request): Promise<Response> {
    try {
      const user = await verifier.verifyHeader(req.headers.get('authorization'))
      // user.sub, user.email, user.mfa — cryptographically verified claims
      return new Response(JSON.stringify({ hello: user.email }))
    } catch (e) {
      if (e instanceof TillAuthVerifyError) {
        const status = e.code === 'no_token' || e.code === 'invalid_token' ? 401 : 403
        return new Response(JSON.stringify({ error: e.message, code: e.code }), { status })
      }
      throw e
    }
  },
}

Signing keys arrive over the standard JWKS documents (fetched with fetch, cached by jose) and tokens verify offline — no per-request call to TillAuth. Realm isolation is structural: the verifier only ever loads the canonical key set and your app's realm set, so a token minted for another realm cannot even reach a key, let alone verify.

02Sessions

Cookie-mode proxy, fetch-native

Prefer HttpOnly cookies over browser-held tokens? The same package ships a fetch-native proxy — mount it at /api/auth/* on your Worker and the browser never sees a token (XSS can't exfiltrate what localStorage never held):

import { createFetchHandler } from '@tillstack/auth-node'

const auth = createFetchHandler({ appId: 'tau_your_app_id' })

export default {
  async fetch(req: Request): Promise<Response> {
    const url = new URL(req.url)
    if (url.pathname.startsWith('/api/auth/')) return auth(req)
    // …your routes
    return new Response('ok')
  },
}

It forwards JSON bodies to the /v1 API and translates the token pair into cookies on your domain. The same handler works in Next.js Route Handlers, Deno and Bun.

03Hardening

Air-gapped verification

For zero-egress verification (or to keep cold starts free of a JWKS fetch), pin the public keys inline — e.g. fed from TillSecrets at deploy time:

const verifier = createVerifier({
  appId: 'tau_your_app_id',
  publicJwks: JSON.parse(env.TILLAUTH_PUBLIC_JWKS), // JWK array — public keys only
})

Config, not secrets

Everything this page configures is public material: the app id and public JWKs. Keep them in vars for hygiene, but nothing here is a credential — the private keys never leave TillAuth.

04Scope

What actually is Node-only

expressMiddleware and fastifyHook — thin adapters over the same verifier. On a Worker you simply don't import them; bundlers tree-shake them out.
expressCookieProxy — the Express twin of createFetchHandler above.

The verification core — createVerifier, verify, verifyHeader, TillAuthVerifyError — is runtime-neutral.

Next: embedded account settings for the frontend half · OIDC SSO if you'd rather integrate as a standard relying party · API reference.