Skip to content

Authentication infrastructure for your product

Sign-in for your app, hosted and on your brand.

3een Authentication gives your users branded sign-in, sign-up, verification, password reset and MFA pages, and gives your Next.js or Express app verified sessions with roles and permissions through the @3een/auth SDK.

  • Development and production environments
  • 16 languages
  • Responsive light and dark themes
  • Verified server sessions
Hosted sign-inExample · not interactive

Example of a hosted sign-in page for a company called Northwind: an email field, a Continue button, and buttons to continue with Google or GitHub.

Hosted pages and the SDK, working together

Your app never handles a password. It sends people to your hosted page, and the SDK turns the result into a verified session on your server.

  1. Your app

    Sends the visitor to /api/auth/signin (SignInButton, or any link).

  2. @3een/auth

    Looks up your environment with the API key and redirects to your hosted sign-in page.

  3. Hosted AuthKit

    Your branding, every enabled method, MFA and bot protection. Returns a one-time code.

  4. @3een/auth

    Redeems the code on your server and sets httpOnly session cookies.

  5. Your app

    Reads the verified session with getAuth(), or protects routes with the middleware.

Every screen your users need

These are the real hosted pages, rendered with sample data. Each follows your branding and works on a 320-pixel phone; MFA, magic-code and passkey steps appear in the same card when enabled.

Sign-upExample · not interactive

Example sign-up page: email and password fields and a Create account button.

Email verificationExample · not interactive

Example verification page: six boxes for the emailed code and a Resend code button.

Forgot passwordExample · not interactive

Example forgot-password page: an email field and a Send reset link button.

Reset passwordExample · not interactive

Example reset-password page: new password and confirmation fields.

Your brand, on your domain

Set colors, logo, layout and languages per environment and preview every screen as you edit. Serve the pages on your 3een subdomain, or verify a domain of your own.

Northwind · auth.northwind.exampleExample · not interactive

The sign-in page with Northwind's blue branding.

Acme Health · login.acme.exampleExample · not interactive

The same sign-in page with Acme Health's green branding and square-ish corners.

Connecting a custom domain

  1. Enter the domain in the environment’s Domains settings.
  2. Add the TXT records shown and verify.
  3. Add the CNAME to your 3een subdomain.
Example DNS records for auth.northwind.example
TypeNameValue
TXT_verification.authauthentication-verification=…
CNAMEauthyour 3een subdomain

Example values; the dashboard shows the exact records for your domain.

Sign-in methods

Turn each one on or off per environment. The hosted pages show only what is enabled.

  • Email and password

    With a breach check and NIST-style policy.

  • Social sign-in

    Google, GitHub, GitLab, LinkedIn, Apple.

  • Magic codes

    A six-digit code by email, instead of a password.

  • Passkeys

    WebAuthn, registered on your hosted domain.

  • Authenticator-app MFA

    Off, optional or required per environment.

  • SAML single sign-on

    Per organization, found from the email domain.

Organizations, environments and your users

Each project has a development and a production environment with separate users, keys and settings. Inside an environment, organizations group your customers’ people, with roles, verified domains and SSO.

What stays separate

  • Users: the same email in two environments is two unrelated accounts.
  • Tokens: signed with each environment’s own key, verified only against it.
  • API keys: each acts only within its environment.
  • Sessions carry one current organization; switching refreshes roles and permissions.

Manage users and sessions

  • Create, update and delete users, and end any session, from the dashboard or the users API.
  • Reset a user’s MFA, see linked social identities, and provision users from Okta or Entra ID over SCIM.
  • Blocking or deprovisioning a user stops sign-in and refresh at once.

Integrate in a few files

Mount the SDK’s routes, protect pages with middleware, and read the verified session on the server. The API key stays on your server; the browser only ever holds httpOnly cookies.

app/api/auth/[...auth]/route.tstype-checked

// app/api/auth/[...auth]/route.ts
//
// Mounts the SDK's routes under /api/auth:
//   GET  /api/auth/signin    → redirects to your hosted sign-in page
//   GET  /api/auth/signup    → redirects to your hosted sign-up page
//   GET  /api/auth/callback  → redeems the one-time ?code=, sets the session cookies
//   POST /api/auth/sign-in   → embedded <SignIn /> (email + password)
//   POST /api/auth/sign-in-mfa → embedded <SignIn /> TOTP step
//   POST /api/auth/sign-up   → email + password sign-up
//   POST /api/auth/sign-out  → revokes the session, clears the cookies
//   GET  /api/auth/user      → the signed-in user, for useSession()
//   GET  /api/auth/organizations, POST /api/auth/switch-organization
import { handleAuth } from '@3een/auth/nextjs';
import { authConfig } from '@/lib/auth-config';

const handler = handleAuth(authConfig);

export { handler as GET, handler as POST };
app/billing/page.tsxtype-checked

// app/billing/page.tsx — a Server Component
import { notFound, redirect } from 'next/navigation';
import { getAuth } from '@3een/auth/nextjs';
import { authConfig } from '@/lib/auth-config';

export default async function BillingPage() {
  // Verified locally against the environment's published keys (no API call).
  const auth = await getAuth(authConfig);
  if (!auth) redirect('/api/auth/signin?redirect_uri=/billing');

  // Roles and permissions come from the verified token.
  if (!auth.has({ permission: 'billing:read' })) notFound();

  return <h1>Billing for {auth.claims.email}</h1>;
}

Next.js App Router and Express are supported today. Follow the quickstart.

Security controls that are already on

Nothing to switch on: these apply to every environment by default.

  • Per-environment signing keys

    RS256 session tokens, published as JWKS and verified in your app without an API call.

  • One-time sign-in codes

    The hosted page returns a 60-second, single-use code bound to your redirect URI; tokens never appear in URLs.

  • Registered redirects only

    Unknown redirect URIs are refused, and return paths stay on your own origin.

  • Shared rate limits

    Per account across all servers: 10 sign-ins a minute, 3 password resets or magic codes a minute.

  • Password protection

    Breach check with k-anonymity and bcrypt hashing; administrators can block an account at once.

  • Single-use reset links

    Stored as hashes; a reset ends every existing session of that user.

  • Cloudflare Turnstile

    On the first-factor forms of hosted pages served from 3een subdomains, verified on the server and failing closed.

  • Audit log and signed webhooks

    Authentication attempts and security changes, delivered with HMAC signatures and retries.

API keys can be rotated and revoked at any time. What your app still has to do.

Start with the development environment

Create a project, point the SDK at it, and sign in on your own hosted page.