Getting started
This walkthrough takes you from nothing to a working login: create your organization, sign in to the admin console, create a realm, and register your first application — then point an app at it.
Step 1 — Create your organization
Go to semauth.cc and fill in the sign-up form:
| Field | What to enter |
|---|---|
| Your work email. You'll receive a verification link here, and it becomes your first administrator account. | |
| Organization name | A human-readable name, e.g. Acme Inc. |
| Slug (subdomain) | Lowercase letters, digits, and hyphens only. This becomes your admin console subdomain: {slug}.semauth.cc. Choose carefully — it identifies your tenant. |
Submit the form. SemAuth creates your organization, provisions your hidden admin realm, and emails you a verification link.
No password. SemAuth is passwordless. Sign-up does not ask you to choose a password — you prove ownership of your email by clicking the link, and from then on you log in with a magic link or a passkey.
Step 2 — Verify your email and sign in
Open the email titled "Your SemAuth login link" and click the link. This both verifies your address
and signs you into your admin console at {slug}.semauth.cc.
On first sign-in SemAuth will invite you to enroll a passkey — a fingerprint, face, or device PIN that becomes a fast, phishing-resistant way to log in next time. You can skip it for now and add one later from your account page, unless your realm requires it.
Step 3 — Create a realm
In the admin console open Realms and use the Create Realm card. The only field is a Name (a display label such as Production). On submit, SemAuth:
- generates a random issuer ID and serves the realm at
{issuer_id}.semauth.app; - generates an RSA signing key (RS256) for the realm;
- enables magic link and passkey sign-in, with the minimum assurance level set to "Any factor".
You'll see the realm in the list with its issuer ID and a Discovery link pointing at its
/.well-known/openid-configuration.
Planning a custom domain? If you intend to serve this realm at your own hostname
(e.g. idp.acme.com), set the custom domain before onboarding any users. Changing
it later invalidates every issued token and every enrolled passkey. See
Custom domains.
Step 4 — Register your first application
From the realm, open Apps and create an Application (give it a name like Acme Web). Then add a Client inside it. For a server-side web app, the typical choices are:
| Label | Backend |
| Auth Method | client_secret |
| Redirect URI | https://app.acme.com/auth/callback |
| Grant types | authorization_code refresh_token |
| Scopes | openid email offline_access |
On creation SemAuth shows the Client ID and, for a client_secret client, the
secret — once. Copy both immediately; the secret is never shown again. Full details in
Applications & clients.
Step 5 — Connect your app
Configure your app's OIDC library with the realm's discovery URL and your client credentials:
Issuer / discovery: https://{issuer_id}.semauth.app/.well-known/openid-configuration
Client ID: (from step 4)
Client secret: (from step 4)
Redirect URI: https://app.acme.com/auth/callback
Scopes: openid email offline_access
Most OIDC libraries take it from there: they read the discovery document, send the user to
/authorize, and exchange the returned code at /token. SemAuth requires PKCE
on every authorization request — virtually all modern libraries do this automatically.
Want to verify the wiring without writing code first? Use the Test link next to your client in the admin console — it launches the real login flow against your client's redirect URI.