Skip to content
Zautha

Overview

Zautha handles sign-in, user accounts and organizations for your application. Your users sign in through Zautha’s components on your own pages or through a hosted login page; your server checks who they are with a short-lived session token and manages them with the Backend API.

Workspaces, applications and instances

Section titled “Workspaces, applications and instances”
  • A workspace is your team in the dashboard. It holds your applications, its members and the plan.
  • An application is one product of yours. Every application has two instances: development and production.
  • An instance is a separate world: its own users, sessions, organizations, settings and keys. Nothing is shared between the development and the production instance of an application.

Development instance

Section titled “Development instance”

The development instance is for building and testing. It is ready as soon as you create the application and serves sign-in from its own host, such as happy-otter-1.accounts.zautha.com.

  • It works from localhost without any setup. It uses no cookies: the SDK keeps the session itself.
  • Addresses ending in +zautha_test before the @ (for example jane+zautha_test@example.com) receive no email, and the code 424242 verifies them, so tests can sign up and sign in without a mailbox.
  • It holds up to 100 users and is never counted toward your plan’s usage.

Production instance

Section titled “Production instance”

The production instance serves your real users from a subdomain of your own site, such as accounts.example.com. You point that subdomain at Zautha with a CNAME record; once Zautha verifies it, the production instance serves sign-in there and its session cookies belong to your domain.

Keys

Section titled “Keys”

Each instance has two kinds of keys, both in the dashboard under API keys:

Key Where it goes What it does
Publishable key pk_test_…, pk_live_… Your frontend; it is not a secret Tells the SDK which instance to talk to.
Secret key sk_test_…, sk_live_… Your server only Calls the Backend API. It is shown once, when you create it; keep it out of browsers and repositories.

_test_ keys belong to the development instance and _live_ keys to the production instance.

Signing users in

Section titled “Signing users in”
  • Components: sign-in, sign-up, user and organization components that you place on your own pages, with @zautha/react, @zautha/nextjs or @zautha/js and the @zautha/ui components.
  • Hosted login: the instance’s own sign-in and sign-up pages. Your app sends the user there and gets them back signed in, without any sign-in UI of its own.
  • OIDC: every instance is a standard OpenID Connect provider, for other apps and tools that sign users in with OIDC. Its discovery document is at https://{instance host}/.well-known/openid-configuration.

Your server

Section titled “Your server”
  • Session tokens: a signed-in browser sends a session token, a JSON Web Token that lives 60 seconds and that the SDK renews. Your server verifies it with @zautha/nextjs, @zautha/backend (Node.js and Express) or Zautha.AspNetCore, and reads the user’s id, session and active organization from it.
  • Backend API: manage users, sessions and organizations from your server with the secret key (API reference).
  • Webhooks: Zautha calls your server when users, sessions and organizations change (Webhooks).

Next steps

Section titled “Next steps”