Signing up and signing in

How you sign in depends on the deployment. A self-hosted instance offers a password form, an OpenID Connect identity provider, or both. The hosted service at telmoni.com has the password form switched off and signs you in through its identity provider (listed on the Subprocessors page) with a one-time code emailed to you or with your Google account — it holds no password — so the native-account sections below do not apply there. The CLI signs in through device authorization on either.

Native accountsCopy Anchor Link

On standalone and self-hosted instances using Telmoni's built-in authentication:

• Sign up: Offered where the operator allows it (AUTH_DISABLE_SIGNUP=false; sign-ups are closed by default, and then only an address holding an invitation can register). Enter your email address, a password (8 characters at least, 256 bytes at most), and, optionally, your first and last name. When the deployment sets VERIFY_EMAIL=true, Telmoni emails a confirmation link that expires in 24 hours, and the account cannot sign in until you have opened it and pressed the button on the Confirm your email address page. Signing in before that is refused and sends a fresh link; at most five verification links go to an account a day.
• Sign in: Authenticate with your email and password. Five consecutive incorrect attempts lock the account for 5 minutes.
• Password reset: Selecting Forgot your password? emails a single-use reset link valid for 60 minutes when the address holds a password account, and the page answers the same either way; at most five links go out a day. Using the link terminates all active sessions and records the address as verified, since the link came from it.

An address at a domain the operator holds to single sign-on (AUTH_DOMAINS_WITH_SSO_ENFORCEMENT) cannot use the password form: signing in, signing up and resetting a password refuse it, and the sign-in page shows the identity provider's Continue with button in place of the form.

Passwords are salted and hashed using Argon2id.

Identity providers (OIDC)Copy Anchor Link

A deployment can configure an external OpenID Connect identity provider (AUTH_CUSTOM_CLIENT_ID, with its issuer and secret): one that publishes its discovery document at {issuer}/.well-known/openid-configuration and signs ID tokens with RS256, unless the operator names another algorithm (AUTH_CUSTOM_ID_TOKEN_SIGNED_RESPONSE_ALG). Telmoni sends you to the provider to sign in, verifies the ID token it returns (its signature, issuer, audience, expiry and nonce), and creates or links the local account; a password, if the provider asks for one, is entered at the provider. Each sign-in, there or at the password form, is bound to the browser that began it with PKCE, so a code stolen on its way back to the console opens nothing; the operator turns PKCE off (AUTH_CUSTOM_CHECKS) only for a provider that refuses it.

Beside the password form, the sign-in page shows Continue with and the provider's name (AUTH_CUSTOM_NAME, "single sign-on" unless set); with AUTH_DISABLE_USERNAME_PASSWORD=true, signing in goes straight to the provider, and Sign up, or Create an account on an invitation's page, opens the provider's own sign-up screen when its discovery document lists create in prompt_values_supported, or its sign-in page otherwise. Telmoni asks the provider for the openid, profile and email scopes unless the operator names others (AUTH_CUSTOM_SCOPE), and takes your name, and whether your address is verified, from what it answers; a sign-in the provider shares no address for is refused. A first sign-in creates your account while sign-ups are open (AUTH_DISABLE_SIGNUP=false), or, while they are closed, when an invitation is waiting for your address and the provider says it is verified (email_verified: true). An address that already holds an account here is refused unless the operator has set AUTH_CUSTOM_ALLOW_ACCOUNT_LINKING, the provider says the address is verified, and the account here proved it too, by a confirmation or reset link (see Production).

Verified addressesCopy Anchor Link

Your account records whether your address has been proved, and the console reads that record rather than the session. An address counts as verified once you confirm it on the page a password sign-up's confirmation link opens, use a password reset link, confirm an email change with the code the new address received (on the hosted service, it is recorded as its identity provider reports it), or sign in through an identity provider that vouches for it; the seeded ADMIN_EMAIL account starts verified. A password sign-up on a deployment with VERIFY_EMAIL off is not verified, and a provider's sign-in records what the provider claims, keeping a proof already recorded for the same address.

What the record gates is the inbox's word: the console lists invitations to your address, and accepts them with a press, only while it is verified, and its live stream carries no invitation to an unverified one. The link in an invitation email needs only that you sign in, or register, with the exact address it was sent to; the link is itself the proof. With VERIFY_EMAIL on, an unverified password account cannot use the console at all until its address is confirmed on the page its link opens, and a sign-in through an identity provider is refused while the address it brings has not been proved, by this sign-in or an earlier one.

Device authentication (CLI)Copy Anchor Link

To sign in from terminal sessions, SSH hosts, or the Telmoni CLI, Telmoni implements the OAuth 2.0 Device Authorization Grant (RFC 8628):

1. The CLI initiates the authorization flow via telmoni login, displays a one-time code (eight consonants, shown as XXXX-XXXX, good for ten minutes) and the address of the console's device page (/auth/device), and opens that page in your browser with the code filled in (/auth/device?code=...).
2. Open the page in any browser, on any machine. If you are not signed in there, the console asks you to sign in first and returns you to the page.
3. Confirm that the code on the page matches what your terminal displays, then select Approve, or Deny to refuse it.
4. The CLI, which polls every five seconds, saves its session as soon as you approve. It never asks for your password: you approve it in a browser, and it saves the session its poll receives. A code nobody approves within ten minutes expires, and telmoni login stops with an error; you run it again.

See the Telmoni CLI guide for full command reference and headless CI login instructions.

What your first sign-in createsCopy Anchor Link

The first time you sign in, Telmoni provisions an Organization, seating your account as its Owner (unless the operator has switched new organizations off; see below). It is named after the first word of your name, "Ada's organization" for Ada Lovelace, or "My organization" when your account has no name; nothing is taken from your email address. The name is what everyone in the organization sees, and its URL is derived from it once (adas-organization; see Name and URL). Nothing is asked first: you can rename the organization, or change its URL, on its Settings page whenever you like.

Your name is the one your sign-in supplies. On the hosted service, that is the first and last name on your profile at its identity provider. On a self-hosted deployment, it is the first and last name you gave the sign-up form, or the given and family names your OpenID Connect provider sends, or its name claim when it sends neither (as Microsoft Entra ID does until its optional claims are configured). The administrator a deployment seeds from ADMIN_EMAIL has no name, so their organization is "My organization", at /my-organization unless another organization already holds that URL.

Telmoni provisions an organization the same way whenever it finds you in no active organization, such as after you leave or delete your last one.

A self-hosted deployment may instead start everybody in one organization of its own, as its default organization. There, your account joins that organization as it is created, and perhaps a project in it, with the role the operator chose; you are given no organization of your own, and the console opens on that one.

It creates no project. The console opens on the organization's Overview; create the first one from the organization's Projects page or the switcher in the console header. API keys and connectors are made inside a project. A later sign-in opens the Overview of your default organization, or returns you to the page that sent you to sign in.

Your account is separate from the organization. You can belong to several organizations at once: ones you own, including any you create, and ones you were invited to.

When sign-ups are closedCopy Anchor Link

Two switches are involved, and they do different things:

• New accounts. AUTH_DISABLE_SIGNUP, true unless the operator sets it to false, closes the password form and first-time sign-in through the identity provider alike to new accounts. Existing accounts sign in normally. An invitation still brings a new person in: through the password form, or through the identity provider when it says the invited address is verified (email_verified: true). Anyone else who signs in at the provider comes back to a page saying the deployment admits new people by invitation, with a way to try again, as does an address an account here already holds.
• New organizations. The signup feature flag, a row an operator writes in the server's database (see closing new organizations), stops Telmoni provisioning an organization at first sign-in, and takes New organization out of the console's switcher, so nobody creates one. Signed in with no organization (because of that flag, or after leaving or deleting your last one while it is off), you see an account-only screen offering:
  • Pending invitations: Accept or decline invitations to existing organizations and projects, when your address is verified; an unverified address accepts from the link in the invitation email instead.
  • Email and Password: Change your address, for a password account or one that signs in with an emailed code, or request a reset link, for a password account.
  • Data collection: Your analytics preference, on a deployment with an analytics provider configured.
  • Active sessions: End any of your other sessions.
  • Delete your account: Permanently delete your account and personal data.
  • Sign out.

SessionsCopy Anchor Link

Each sign-in generates an active session backed by an HTTP-only cookie. Its access token lasts 15 minutes and is renewed in the background while a console tab is open, or on your next request, against a refresh token that lasts 30 days and is replaced at every renewal; a session unused for 30 days ends. Your account's Privacy page (/account/privacy) lists every session not yet signed out or revoked, one that lapsed after 30 days unused included, with device details and when each was last active. You can revoke any other session remotely: the device is refused at its next request, and a console tab left open there is sent to sign in within 15 minutes.

Changing your email address ends all your sessions immediately, and so does resetting your password on a self-hosted deployment.

Signing outCopy Anchor Link

Sign out in the account menu is a form post to /auth/logout. It revokes the session in the database, so an access token still in flight stops working, clears the console's cookies, and sends the browser home, or, for a session that began at an identity provider that publishes an end_session_endpoint, through the provider's sign-out page and back to the home page. On the hosted service, it goes through its identity provider's sign-out page, which ends your session there too. A post from another site, which the browser's Fetch Metadata or Origin header gives away, is turned back to the home page without signing you out, and so is a link to /auth/logout from another site. A link from this site, or the address typed, does not sign you out either: with a live session it opens a page that asks, and the sign-out is the button on it. A session already ended — by a deletion, an email change or a revocation from another device — is let out without the question.