Integrations

OutlabsAuth UI

Optional sidecar admin console — point it at any FastAPI host running OutlabsAuth and manage the full surface.

OutlabsAuth UI is an optional sidecar admin console — a separate Vite/React app you run next to your API. It is not part of the Python package, and it does not ship a second auth stack. It talks to whatever FastAPI host has OutlabsAuth mounted, using the same routers your product already exposes.

We maintain it ourselves and use it day-to-day: it is the fastest way to see and operate what is going on in an OutlabsAuth-backed system — users, roles, entities, keys, sessions, audit, and more — without building that console from scratch.

The UI only shows what the backend advertises. Mount the right router factories first.

Why it exists

Sidecar, not a product UI

Point it at any instance that mounts OutlabsAuth — local examples, staging, or production. Your customers still get your screens; this console is for operators and implementers.

Full gamut of features

When the matching routers are mounted, you get the same surface the library exposes: invites, roles, permissions, ABAC, entities, memberships, API keys, sessions, audit search, account self-service, passwordless entry flows, and OAuth link/unlink where enabled.

Visualise the system

Browse the org tree, inspect memberships, search audit events, check active sessions, and watch activity signals on users and entities — useful while integrating and debugging, not only for “admin CRUD.”

Reference for your own UI

The repo is a working example of how to consume /auth/config, permission gates, and the management APIs. Steal patterns; you do not have to ship this SPA to end users.

What you can do in the console

Workspaces appear based on GET {authApiPrefix}/auth/config (preset + feature flags). Typical surfaces:

Workspace	What it is for
Dashboard	Capability snapshot and shortcuts into visible workspaces
Account	Profile, password, linked social accounts, self-service phone OTP
Users	Invite / create, status, roles, memberships, orphaned users, history, permission checks
Roles & permissions	Catalog, role composition, ABAC conditions when enabled
Entities	Enterprise org tree — create, move, members, local roles, activity
API keys	Personal keys (self-service) and system/integration keys (admin)
Audit	Cross-user event search with before/after/metadata inspection
Settings	Runtime capabilities from `/auth/config` plus mutable entity types

Auth shell flows the console needs to reach those workspaces are covered too: password login, forgot/reset, magic link, access code, accept invite, and invite-only Google OAuth when the host mounts them.

Self-registration for end customers stays a host concern. The console is invite-oriented (plus admin create-user with password). Your product UI can still offer open registration via the library if you want that.

How it connects

sidecar

Your FastAPI app (any host)
└── OutlabsAuth routers under a stable prefix (/v1, /iam, …)
        ↑
        │  apiBaseUrl + authApiPrefix
        │
OutlabsAuth UI (separate process / deploy)

Configure two values:

Field	Meaning
`apiBaseUrl`	Origin of the FastAPI app (no trailing slash)
`authApiPrefix`	Parent of `/auth` — e.g. `/v1` when you mount `/v1/auth`

With authApiPrefix: "/v1", the UI calls /v1/auth/config, /v1/auth/login, /v1/users, /v1/roles, and so on. It adapts navigation for SimpleRBAC vs EnterpriseRBAC from that config snapshot (entity hierarchy, context-aware roles, activity tracking, …).

If you mount get_auth_router(..., prefix="/v1/auth"), set authApiPrefix to /v1, not/v1/auth.

Quick start

Clone and install

Terminal

git clone https://github.com/outlabsio/OutlabsAuthUI.git
cd OutlabsAuthUI
bun install
cp public/app-config.template.json public/app-config.json

Point at your API

public/app-config.json

{
  "apiBaseUrl": "http://localhost:8004",
  "authApiPrefix": "/v1",
  "appName": "OutlabsAuth UI",
  "appSubtitle": "Shared auth admin console",
  "authBrand": "OutlabsAuth",
  "signInDescription": "Sign in against the configured auth backend to access this console."
}

Example host	API port	Suggested config
`examples/simple_rbac`	`8003`	`apiBaseUrl: http://localhost:8003`, `authApiPrefix: /v1`
`examples/enterprise_rbac`	`8004`	`apiBaseUrl: http://localhost:8004`, `authApiPrefix: /v1`

Run the UI

Terminal

bun run dev

Default Vite URL is http://localhost:5173. Sign in with a bootstrap or seeded admin from the host app.

Config precedence (runtime inject → /app-config.json → Vite env → localhost defaults) is documented in the UI repo’s runtime configuration.

What to mount on the backend

Minimum for login: get_auth_router (and GET /auth/config comes with it).

For a useful admin console, mount the admin UI–friendly sets in Routers & Prefixes — users, roles, permissions, API keys, and (for Enterprise) entities / memberships / audit as needed.

If a workspace is missing in the UI, the usual cause is a missing router or a feature flag off on the backend — not a broken SPA.

Simple vs Enterprise behaviour

The same SPA serves both presets. Invite and membership forms change with the backend:

SimpleRBAC — no entity scope on invites; selected role_ids become direct account role memberships.
EnterpriseRBAC — entity hierarchy and memberships appear when advertised; invites can attach roles through an entity membership when entity_id is supplied.

Building your own UI instead

You do not have to deploy OutlabsAuth UI. Many products keep customer-facing auth screens in-house and only use this console internally.

If you do build your own:

Call GET {prefix}/auth/config and drive feature UI from that payload.
Reuse the same permission names the library enforces (user:read, …).
Treat the OutlabsAuth UI repo as a worked example of query keys, forms, and workspace boundaries — not as a required dependency.

Deploy notes

Prefer one generic build; inject app-config.json (or window.__OUTLABS_AUTH_UI_CONFIG__) per environment.
Keep CORS on the FastAPI host open to the UI origin in each environment.
The UI never holds host secrets for OAuth/SMS/email — those stay on the backend; the console only uses the public auth API.

Routers & Prefixes — what to mount
Getting Started — wire the library first
Sessions & Audit — backend contracts the Audit workspace uses
API Keys — personal vs system integration keys
OutlabsAuthUI on GitHub

API Keys

Personal and system integration keys for host apps.

Data Models

Postgres / SQLModel schema reference.