Kizaki
Learn

Add Authentication

Configure sign-in, sessions, and principal data in Inspire so your app code can rely on a stable user model.

Authentication starts in Inspire. Your schema decides which providers exist, how long sessions last, and which user attributes become available to policies and server functions.

For a first-time Kizaki app, auth should be simple and structural. The point is to establish a dependable identity model early so the rest of the stack can build on it.

Configure The Auth Block

auth {
  providers: [email, google],
  sessionDuration: 30d,
  mfa: optional,

  principal {
    displayName: string @from(Profile.displayName),
    organizationId: Organization.id? @from(Profile.organizationId),
  }
}

Recommended defaults for a new SaaS app:

  • start with email
  • add OAuth providers once your product needs them
  • keep principal fields focused on authorization and UI identity

That last point matters the most. The principal block should expose the values the rest of your platform logic actually needs, not mirror every user-related field in your database.

Use The Authenticated Principal

Inside exposed server functions, use getPrincipal():

import { getPrincipal } from "@kizaki/sdk";

/** @expose */
export async function me() {
  const principal = getPrincipal();
  return {
    id: principal.id,
    displayName: principal.attributes.displayName,
  };
}

Once auth is configured, this becomes the standard server-side pattern:

  • the platform authenticates the request
  • your function reads identity through getPrincipal()
  • your business logic stays focused on the action itself

Most apps should keep auth identity and app profile data separate:

  • __User is the built-in authenticated user entity
  • Profile is your app-specific user record
  • the principal block pulls the few profile fields you need often

This separation keeps the model easier to evolve:

  • identity remains stable
  • profile data can change with product needs
  • policies do not need to rediscover the same join logic over and over

A Good First Version

For most apps, a strong first auth model is:

  • one or two providers
  • one profile entity
  • one or two principal attributes

That is enough to support ownership rules, tenant selection, and user-facing UI state without overcomplicating the foundation.

Next Step

After auth is configured, put your authorization rules where they belong: in the schema. Continue with Add Access Policies.

On this page