Authentication

Authentication is administered in Settings → Server → Authentication. Only the super administrator can change server sign-in methods.

First account and registration

The first-run setup creates the super-admin account and the server signing secret. After setup, new users join through an allowed registration policy, invitation, or configured OIDC provider. Registration can be closed without removing existing accounts.

Server users, licence seats, roles, and invitations are managed separately. A valid account may still lack a seat or project role, and therefore be unable to open protected work.

Stib-managed sign-in

Stib-managed accounts use the server's normal login and refresh-token flow. Passwords are stored as one-way hashes; session tokens must still be protected like credentials.

Use HTTPS whenever the server is accessed beyond localhost. Do not expose a password-enabled HTTP origin to an untrusted network.

OIDC SSO

OIDC requires:

• an issuer URL with a reachable discovery document;
• a client ID and optional client secret according to the provider;
• scopes, normally openid email profile;
• the exact callback URL shown by Stib, registered at the provider;
• a correct public server origin.

Set STIB_SERVER_ORIGIN=https://stib.example.com before configuring the provider when Stib sits behind a reverse proxy. The callback is constructed from that origin; do not point it at an internal container hostname.

Stib uses the authorization-code flow with PKCE and validates issuer, audience, expiry, and state. Client secrets are encrypted at rest. Use Test in the OIDC settings before enabling the method for users.

Provisioning and access

OIDC can create or match a Stib user from validated identity claims, subject to server policy and email-conflict protection. Identity-provider group membership does not automatically replace Stib's organization/project roles unless a specific mapping feature is configured.

After successful sign-in, access still depends on:

1. server role and licence seat;
2. organization membership or inherited administration;
3. direct or inherited project role;
4. column-level access restrictions.

Desktop and mobile

The web client can use a popup/redirect flow. The desktop client redirects through the configured server and returns to the app. Mobile uses the registered stib:// callback path. Test each client type because reverse-proxy and deep-link behavior differ.

Recovery checklist

Before changing authentication, keep a tested super-admin login and a database backup. If sign-in fails, verify server time, public origin, HTTPS certificates, discovery URL, callback URI, client credentials, requested scopes, open-registration/invitation policy, and available licence seats.

Next: Server Configuration and Audit & Collaboration.