auth-mini

auth-mini interactive companion

A small, self-hosted auth server for apps that just need auth.

An interactive demo for teams exploring auth-mini integration with email OTP, passkeys, JWTs, JWKS, and SQLite.

  • email OTP
  • passkey
  • JWT
  • JWKS
  • SQLite
  • self-hosted

Shortest path

Bring your own auth origin

Point this page at your auth-mini server, store the page origin with origin add, then verify email OTP and passkeys from the same page.

Page origin:
Show SDK runtime target

Quick start

Allowlist this page origin, then start auth-mini

The command below stays aligned with this page and your chosen auth origin. Copy it first, then come back to the playground.

Command

CLI startup

 npx auth-mini origin add ... --value http://127.0.0.1:8080
npx auth-mini start ... --issuer https://auth.zccz14.com
Show browser script snippet 
Runtime snippet target: Task 4 renders the config-derived script tag here.

Playground

Run the real browser flow

Keep the same controls from the original demo, but place them inside a page that also explains how to wire auth-mini in production.

Config

SDK config

Ready

This page loads the singleton SDK from the auth server origin so the script origin stays equal to the API origin.

Show runtime values

Static layout note: runtime-derived values stay centralized in the docs sections above and will be rendered here later if the playground needs a secondary view.

Step 1

Email start

Idle 
No request yet.

Step 2

Email verify

Idle 
No request yet.

Step 3

Register passkey

Idle

Uses window.AuthMini.webauthn.register() to fetch options, complete the browser passkey prompt, and verify the credential. 

No request yet.

Step 4

Authenticate passkey

Idle

Starts a username-less passkey login through window.AuthMini.webauthn.authenticate() and waits until session + /me state are ready. 

No request yet.

How it works

One page, one shared config story

The docs, snippets, and playground should all update from the same derived setup state.

  • The page origin becomes the recommended origin add value.
  • The auth origin becomes the SDK script origin and the API origin.
  • WebAuthn and CORS depend on those values being configured together.

API reference

Minimal calls for the common path

Keep the shortest request path visible first, then expand details per endpoint only when needed.

Example

POST /email/start

Static placeholder for Task 4 runtime-generated API reference entries.

Show request and response 
Placeholder only: request/response examples render here after runtime content wiring.

Backend JWT

Verify access tokens locally

The primary backend path is local JWT verification with JWKS, not a round-trip to the auth server on every request.

jose

Node / TypeScript snippet

Runtime snippet target: Task 4 renders the jose JWT verification example here.
More backend JWT notes
  • Placeholder only: backend JWT notes render here from shared page state.

Deployment notes

Static hosting stays first-class

Use relative local assets for this page, then configure auth-mini to trust whatever final page origin you deploy.

  • Publish the contents of demo/ so index.html, ./style.css, and ./main.js stay path-safe on GitHub Pages.
  • Store the final browser page origin with npx auth-mini origin add, then use ?sdk-origin= when the docs page and auth server are on different origins.
  • Custom GitHub Pages domains should ship a matching CNAME file so the browser origin stays stable for WebAuthn and CORS.