Live

Auth

Multi-tenant auth without the sprint.

Auth is the auth layer for products that need tenancy on day one. Users, organizations, roles, MFA, machine-to-machine tokens, and audit logs, all behind one REST API. Tokens are scoped and signed per app, so the isolation between tenants is a property of the token, not a policy check.

Most auth stacks split in half: consumer widgets that crack once you need tenancy, or enterprise IdPs that take a quarter to wire up. Auth sits in the middle. Opinionated enough to ship in an afternoon. Flexible enough to run thousands of tenants without a rewrite.

No dashboard-driven config. Every operation is an HTTP call with a JSON body, so if your stack can POST, it can use Auth. A typed Node client sits on the same OpenAPI spec if you want one; the flat HTTP surface is still the product. And every ProductCraft product runs on Auth — we eat our own tenancy model.

Read the docs Open in console

Capabilities

Core features

Everything you need to add production-grade auth to a multi-tenant application. Nothing you don’t.

Two levels of tenancy

An App is the hard boundary — its own signing key, its own roles, permissions, and users. Inside an App, organizations group users: a member’s organization and their role in it ride on the token as org_id and org_role, and GET /me/permissions returns the union of their app role and their organization role.

Role-based access control

Create roles, attach permissions, and assign them to users. Enforce access at the API level with a single guard. Permissions follow a resource.action format, and each App can extend the catalogue with entries of its own.

User management

Create, update, suspend, reinstate, and delete users through the API — one at a time or in bulk — with session revocation and multiple verified contacts per account. A user belongs to exactly one App, so the same email address in two Apps is two unrelated accounts.

Multi-factor authentication

TOTP from any authenticator app, or a single-use code emailed to a verified contact. Recovery codes are issued on enrolment and can be regenerated, and an already-signed-in session can step up with a fresh code when an operation warrants it.

Sign-in you don’t have to build

Email and password, or Sign in with Apple, Google, and GitHub. Email verification, password reset, and refresh-token rotation are endpoints, not a project. Session length, lockout threshold, password rules, and allowed redirect origins are per-App config.

Machine-to-machine tokens

Mint client credentials scoped to specific permissions and exchange them for an app-scoped JWT over the standard OAuth 2.0 client_credentials grant. Rotate a secret or deactivate a client from the admin API. No user session required.

App invites

Mint an invite for an App with an expiry, a usage limit, and a role to grant. Invites have a real lifecycle you can list and filter — pending, used, expired, revoked — and are redeemed on an accept endpoint. Organization membership is a direct add today; organization-level invites are not built yet.

Webhooks on identity events

Signup, sign-in, contact verified, password reset requested and completed, suspension, reinstatement, role change, deletion, organization and membership changes, app slug change, and every MFA event. HMAC-SHA256 signed, retried with backoff, and auto-disabled after sustained failure.

Audit logging

Every authentication event, permission change, role assignment, and admin action is recorded with a timestamp, actor, and context. The log is append-only and cursor-paginated, filterable by action, actor, and date range.

Integration

How it works

A typical integration takes three steps: create an App for your product, issue tokens for your users or services, and check permissions on each request.

Create an App

An App is your product, or one environment of it. Creating one mints its own signing keypair and provisions system roles and permissions. Your customers are organizations inside it, not Apps of their own.

POST /v1/apps

{
  "slug":         "acme-corp",
  "display_name": "Acme Corporation",
  "workspace_id": "835015dc-7bde-4a8a-b306-c066d4733b90"
}

Issue a token

Authenticate a user or a service and receive a signed JWT. Users sign in with email and password, or with Apple, Google, or GitHub. Services use the OAuth 2.0 client-credentials grant.

POST /{app_slug}/v1/oauth/token

{
  "grant_type":    "client_credentials",
  "client_id":     "m2m_a1b2c3d4...",
  "client_secret": "base64url-secret"
}

Check permissions

Verify the token and check whether the caller holds the permission you require. Pass permission for a single check, or permissions for a set that must all be held. When you only need the claims, verifying offline against the app’s JWKS endpoint is the fast path.

POST /{app_slug}/v1/authorize

{
  "token":      "eyJhbGciOiJSUzI1NiIs...",
  "permission": "user.read"
}

→ { "authorized": true }

Under the hood

Technical details

Here is what matters for your integration.

REST-first, SDK-optional

Every operation is a standard HTTP call, so curl or any HTTP client in any language is a first-class way to use Auth. The OpenAPI spec is published, and a typed Node client — @productcraft/auth — sits on top of it, with a Passport adapter alongside. Reach for the SDK if you want the ergonomics; nothing in the product requires it.

JWT-based authentication

Tokens follow the JWT standard with RS256 signing. Each App gets its own keypair, and iss is the app’s own issuer URL, so a token minted for one App is both distinguishable from and unverifiable against another. Verify locally against the per-app JWKS endpoint, or call the API when you want the live answer.

Tenant-scoped data isolation

Every query is filtered by App, and by organization where the token carries one. Auth enforces the boundary, so you never need to write tenant-filtering logic in your own queries.

LLM-friendly surface

Consistent snake_case naming, predictable response shapes, cursor pagination everywhere, and thorough error messages. AI coding assistants can integrate Auth endpoints without guesswork.

Horizontal scaling

Stateless request handling. Deploy multiple instances behind a load balancer. Token verification works offline using cached JWKS keys.

Use cases

Built for these workloads

SaaS with team workspaces

Your product is one App; each customer is an organization inside it. Users hold an app-level role and a role within their organization, and the token carries both. Auth handles the boundaries so you can focus on features.

Internal tools with service accounts

Issue M2M credentials for your cron jobs, CI pipelines, or internal services. Scope them to specific permissions and rotate the secret on a schedule.

Marketplaces and platforms

Sellers, buyers, and admins each operate within their own permission model. Auth keeps the access rules clean without custom middleware in every route.

AI agent backends

Agents that call your API need scoped credentials. Issue short-lived tokens with narrow permissions so agents can act on behalf of users without broad access.

Skip the auth sprint

The quickstart goes from zero to a signed token in under ten minutes. Create an App, issue a token, verify it against the JWKS endpoint — all with copy-paste curl.

Start the quickstart Open in console