SemAuth documentation

SemAuth is a multi-tenant OpenID Connect (OIDC) identity provider, operated as a hosted service by Kovilo. It lets your organization run its own login service: you register the applications that need sign-in, choose how your users authenticate (magic links, passkeys, or "Sign in with Google/LinkedIn"), and SemAuth issues the standard ID tokens and access tokens your apps verify.

This documentation is written for two audiences, side by side:

Administrators who configure organizations, realms, applications, and sign-in policy in the admin console.
Developers who connect an application to SemAuth and call the OIDC and Admin API endpoints.
It also explains what the experience looks like for the end user who has to log in.

Start here

Core concepts →

Organizations, realms, applications, clients, and users — what each one is and how they nest.

Getting started →

Create your organization, sign in for the first time, and register your first application.

How users sign in →

Magic links, passkeys, and federated login — the end-user experience and how to enable each.

OIDC endpoint reference →

Discovery, authorize, token, userinfo, JWKS, logout — the protocol surface your app talks to.

What SemAuth gives you

Capability	Summary
Standard OIDC	Authorization-code flow with mandatory PKCE, refresh tokens with rotation + reuse detection, RS256-signed ID tokens, and a published JWKS for stateless verification.
Passwordless by default	Users sign in with a magic link emailed to them or a passkey (WebAuthn / FIDO2). No passwords to store or leak.
Federation	Let users sign in with an external identity provider — Google, LinkedIn, or any generic OIDC provider.
Assurance levels	Require a minimum authentication strength (single-factor, MFA, or phishing-resistant) per realm, enforced at token issuance.
Multi-tenant	SemAuth hosts many organizations side by side; each gets isolated realms, users, and an admin console on its own subdomain.
Custom domains	Serve a realm at your own hostname (e.g. `idp.acme.com`) with automatic TLS.
Admin API	Automate realm, client, and federation management over a bearer-authenticated REST API, or from the terminal with the CLI.
Audit trail	Every change and every sign-in is event-sourced and visible in the Activity and Events views.

The big picture

At a glance, here is how the pieces fit together — an organization owns realms, a realm hosts your applications and your users, and applications contain the OIDC clients your software authenticates as:

flowchart TD Org["Organization your tenant · admin console"] Realm["Realm an OIDC issuer"] App["Application a product grouping"] Client["Client an OIDC relying party"] User["User an end-user identity"] Org --> Realm Realm --> App Realm --> User App --> Client

Read Core concepts next for a precise definition of each of these and the URL each one lives at.

Core concepts →