OBLETHdocs

Accounts and sign-in

Create and manage accounts, send invitation and recovery links, and add sign-in through your identity provider.

3 min readUpdated for Chat 0.5.2Edit on GitHub

Manage inSettings › Administration › People
Always onUsername and password
OptionalOIDC
RegistrationNone, unless OIDC allows it

Add people

There is no public registration. In Settings › Administration › People, create an account and give it one of:

  • An invitation link. A one-use, time-limited link you copy and send to the person; they choose their own password. Chat sends no email.
  • A temporary password. The person must change it before they can chat.

From the same list you can promote and demote administrators, disable an account, send a recovery link, revoke a person's sessions and link an OIDC identity. The last enabled administrator can't be demoted or disabled.

Settings › Administration › Groups holds groups for model access and sharing; see Models, groups and limits.

Sessions

Sessions are opaque HttpOnly cookies, stored hashed in Postgres and valid for OBLETH_CHAT_SESSION_HOURS (12 by default). People see and revoke their own sessions in Settings › Personal › Security. Changing a password revokes older sessions, and disabling an account ends its access on every replica. Ending a session also ends the personal API tokens and workspace preview access made in it. A response that's streaming rechecks its session every 15 seconds.

Passwords are hashed with Argon2id and must be at least 12 characters.

Add OIDC sign-in

OIDC is an addition: local sign-in stays available. Set all three of issuer, client ID and secret, or none of them:

OBLETH_CHAT_OIDC_ISSUER=https://idp.example.edu/realms/research
OBLETH_CHAT_OIDC_CLIENT_ID=obleth-chat
OBLETH_CHAT_OIDC_CLIENT_SECRET=…
OBLETH_CHAT_OIDC_ALLOW_SIGNUP=false

Register <OBLETH_CHAT_ORIGIN>/api/auth/oidc/callback as the exact redirect URI.

Identity is keyed by issuer and subject. Chat never links accounts by email address. To connect an existing account to an identity-provider user, link the subject in People. With OBLETH_CHAT_OIDC_ALLOW_SIGNUP=true, anyone who can sign in to that issuer gets a standard account on first sign-in.

Map identity-provider groups

Chat can put people into its own groups from a claim in their ID token:

OBLETH_CHAT_OIDC_GROUP_CLAIM=groups
OBLETH_CHAT_OIDC_GROUP_MAP={"research-staff":["<chat group UUID>"]}
OBLETH_CHAT_DEFAULT_GROUP_IDS=<chat group UUID>

The map turns claim values into Chat group UUIDs, and Chat reconciles only the memberships the mapping created; ones you add by hand stay. OBLETH_CHAT_DEFAULT_GROUP_IDS adds every new local or OIDC account to those groups. No mapping grants the administrator role.

Sign-in throttling

Limits are shared across replicas:

  • Each client address gets OBLETH_CHAT_LOGIN_RATE_PER_MINUTE (300) sign-in, password-change and activation requests a minute. OIDC redirects have their own budget of the same size.
  • Each account gets 10 password attempts a minute per client. A correct password refunds its own attempt.
  • 50 failures a minute on one account stop only the clients that are failing on it. A client with no failures on that account in the last 10 minutes counts against a separate limit of 50 a minute, so failures from other addresses can't lock someone out, and rotating addresses still adds at most 50 guesses a minute.
  • A refused client stays refused until it has been quiet for 10 minutes since its last counted attempt. Chat logs when an account reaches either limit.

Behind a reverse proxy, every client looks like the proxy until you trust it; see Reverse proxies.

What the OIDC flow checks

Authorization code with PKCE, state and nonce, ID-token signature, issuer and audience, and a one-use transaction bound to the browser and stored in Postgres. Sessions are capped by the ID token's expiry and by OBLETH_CHAT_SESSION_HOURS. Refresh tokens and identity-provider logout aren't supported; signing out ends the Chat session. Linking an identity revokes the account's pending invitation and recovery links.

What's audited

Role, account, model, group and limit changes appear in Settings › Administration › Activity. The audit log never stores passwords, tokens or conversation text.