OpenAuth

Build, deploy, and verify self-hosted OAuth 2.0 and OIDC authentication servers across Cloudflare Workers, Node.js, Bun, and AWS Lambda using @openauthjs/openauth.

Whether you need a lightweight single-file auth server for an MVP or a full-scale multi-tenant identity cluster with social logins and custom subjects, OpenAuth provides prebuilt UI (PasswordUI, CodeUI), zero-config token issuance, and cross-framework client verification.

When to Use

• Self-hosted auth server: You want to deploy an identity server without paying third-party auth vendors (Auth0, Clerk, Cognito) using SST's @openauthjs/openauth.
• Subject definition: You are defining user claims and typed token schemas with createSubjects using Standard Schema validators (Valibot or Zod).
• Prebuilt UI & providers: You need email OTP pin codes (CodeUI / CodeProvider), username/password (PasswordUI / PasswordProvider), or social logins (GitHub, Google, Discord, Apple, OIDC).
• Client verification & session cookies: You are protecting SSR routes or APIs in Hono, Next.js, Cloudflare Workers, Express, or Astro using createClient, client.authorize, client.exchange, and client.verify.
• Multi-runtime deployments: You are deploying the auth server to Cloudflare Workers (with KV storage), AWS Lambda (with DynamoDB storage), Bun, or Node.js.

When Not to Use

• Third-party SaaS auth SDKs: You are integrating proprietary managed SaaS SDKs like @clerk/nextjs, @auth0/nextjs-auth0, or Supabase Auth.
• Traditional stateful sessions: You are using legacy server-side memory sessions (express-session, Redis sessions) without OAuth2/OIDC JWT tokens.
• Pure Discord or Telegram embedded auth: You are building embedded apps inside Discord or Telegram; use discord-activities or use-telegram-serverless.