Add Authentication

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

Kizaki's auth service exposes the /__auth/* routes and handles login, session management, verification, password reset, and OAuth flows. You configure the model in Inspire. The service does the rest.

Configure The Auth Block

auth {
  providers: [email, google],
  sessionDuration: 30d,
  linking: manual,

  password {
    minLength: 12,
    blockCommon: true,
    breachCheck: true,
  }

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

Recommended defaults for a new SaaS app:

• start with email
• add OAuth providers once your product needs them
• set an explicit password policy for email accounts
• keep principal fields focused on authorization and UI identity

The principal block should expose only the values your platform logic actually uses. It is not a mirror of 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,
  };
}

This is 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

Recommended Data Model

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 easy to evolve. Identity remains stable. Profile data changes with product needs. Policies avoid rediscovering the same join logic repeatedly.

A Good First Version

For most apps, a strong first auth model is:

• one or two providers
• one password policy block if email is enabled
• one profile entity
• one or two principal attributes

Remember the split:

• auth {} configures user auth
• routes(..., auth: session) protects user-facing routes
• apiKeys {} is separate and handles machine callers

That setup supports 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.