User management (journal-backed)

The open-core roleAuth works with a handful of tokens defined in hardcoded config — adding a new user requires a deploy. createJournalUserStore instead keeps users in the journal (data-driven, like policy/budget): an operator creates a new user from Studio, the returned token is handed to that person, and the user makes requests with that token via Authorization: Bearer <token> — no deploy, no code change.

Concrete scenario: in a SaaS deployment, the operator (an organization-less admin) creates a member from Studio's "Users" view for each new customer organization (with an organization assignment), and hands the token to the customer; the customer uses the API scoped to their own organization with that token. An organization-admin, in turn, can only manage members of their own organization.

import { createEnterpriseAuth, createJournalUserStore, createJournalAuditSink } from '@gnldev/auth-ee';
import { toJournal } from '@gnldev/durable';
import { SqliteStorage } from '@gnldev/durable/sqlite';

@gnldev/auth-ee is a paid/licensed package. createJournalUserStore requires a journal that supports listKeys to store users — toJournal(storage.runs) (Sqlite/Postgres/InMemory all provide listKeys) fits that structurally.

1. Set up the store on the journal and pass it to createEnterpriseAuth as userStore — it kicks in after SSO, before the open-core fallback:

const userStore = createJournalUserStore(toJournal(storage.runs));
const auth = createEnterpriseAuth({
  licenseKey,
  failClosed: true,
  userStore,
  audit: createJournalAuditSink(toJournal(storage.runs)),
  fallback: roleAuth({
    admin: { token: ADMIN_TOKEN, user: 'ops' },  // bootstrap operator
  }),
});

2. Pass that same userStore to Studio via the users option — this opens the "Users" view in Studio and the /users endpoints:

app.route('/studio', createStudioApp({
  reader: toJournal(storage.runs),
  gnl,
  auth,
  users: userStore, // the Studio "Users" view — add/remove; the token is shown once
}));

3. When a new user is created from Studio (or programmatically via userStore.create()), the returned token is shown only at that moment — the server never stores the plain token anywhere, only its SHA-256 hash is written to the journal:

const { user, token } = await userStore.create({
  email: '[email protected]',
  roles: ['viewer'],
  orgId: 'acme',
  ttlMs: 30 * 24 * 60 * 60 * 1000, // expires automatically after 30 days
});
// token: 'eeu_...' — returned HERE ONLY; if it is lost, userStore.revoke() then create() again

4. The user sends that token in an Authorization: Bearer eeu_... header; authenticate() looks up the token's SHA-256 in the journal's reverse index, and if it isn't expired (expiresAt) or revoked (revoked), it returns a Principal and updates lastUsedAt on a best-effort basis.

To cut off a user's access without deleting them, use userStore.revoke(id) — the record stays (for audit/history), only the token's reverse index is removed and it's marked revoked: true.