Security & passkeys

Orimora is passwordless by design — you sign in with a magic link or an SSO provider, and can add passkeys for fast, phishing-resistant logins. This page covers the account-security controls under Settings → Security and related areas.

Passkeys (WebAuthn)

A passkey is a cryptographic credential stored on your device (Touch ID / Face ID / Windows Hello / a hardware security key). It logs you in without a password or an email round-trip, and cannot be phished.

Add a passkey

1. Go to Settings → Security.
2. Click Add passkey, optionally name it (e.g. “MacBook Touch ID”).
3. Complete your device’s biometric / security-key prompt.

The passkey appears in the list with its name and creation date. Add one per device you regularly use.

Sign in with a passkey

On the login screen, choose Sign in with a passkey and complete the device prompt. No email or password is involved.

Manage / remove

Each passkey can be renamed or deleted from the list. Removing a passkey immediately prevents it from being used to sign in.

Tip

Register a passkey on more than one device (or a hardware key you keep safe). If you only have one passkey and lose that device, fall back to the magic-link / SSO login you originally used.

Sessions

Sessions are cookie-based and rotate on login. Two timeouts apply:

• An absolute lifetime (30 days).
• An idle timeout — a session is invalidated after SESSION_IDLE_TIMEOUT_DAYS (default 7) of inactivity, even within the absolute window. Operators can tune or disable it (see Configuration).

Two-factor authentication (TOTP)

Magic-link users can add a time-based one-time code (RFC 6238) from an authenticator app (Google Authenticator, 1Password, Aegis, …) as a second factor, under Settings → Security.

• Set up: scan the QR code (or enter the key manually), then confirm a 6-digit code. You’re shown 10 single-use backup codes once — store them safely.
• At login: after a magic link, you’re asked for a code before the session is created. A backup code works if you don’t have your authenticator.
• Passkeys always bypass it; SSO only when the IdP asserts MFA: a passkey is already a strong factor. For OIDC/SAML the MFA requirement is delegated to your identity provider only if the provider’s assertion proves it performed MFA (an amr of mfa/a recognised second factor, or an MFA AuthnContextClassRef). A single-factor SSO login does not count and falls through to the local-factor requirement.
• Disable / regenerate backup codes requires a current code (proof of possession). If a member is locked out (lost device + backup codes), a team admin can reset their MFA (audited) so they can re-enroll.

Secrets are encrypted at rest, backup codes are hashed and single-use, codes can’t be replayed within their window, and verification is rate-limited.

Step-up for sensitive actions: changing SSO config, creating a SCIM token or an API key, adding a member to a system group (e.g. Admins), and similar high-impact actions ask you to re-verify a factor — a recent TOTP/backup code or a passkey — even within an active session, protecting against a hijacked session making irreversible changes. Users with no second factor are not prompted (no lockout).

Require MFA for the whole team

A workspace admin can require every member to hold a second factor under Settings → Workspace → Two-factor authentication. While enabled:

• Members without a TOTP authenticator or a passkey are sent to a one-time enrollment page and cannot use the workspace until they set one up.
• SSO logins are exempt only when the IdP asserts MFA — if a member signs in through OIDC/SAML and the provider’s assertion proves multi-factor (amr: ['mfa']/a recognised second factor, or an MFA AuthnContextClassRef such as Microsoft Entra’s multi-auth class), MFA is delegated to the IdP and they are not asked to add a local factor. A single-factor SSO login is treated as not-yet-MFA, and the member is sent to the local enrollment page like everyone else. To rely on this exemption, configure your IdP to assert MFA.
• To switch it on you must already have your own second factor (so you can’t lock yourself out), and the change is step-up protected and audited. If a member loses their factor, an admin can reset their MFA so they can re-enroll.

Step-up (re-verification)

Some actions are sensitive enough that a valid session alone isn’t sufficient — Orimora asks you to re-verify a second factor immediately before they proceed, even if you’re already signed in. This limits the damage of a borrowed or hijacked session.

Step-up protects, among others: changing your email, transferring workspace ownership, recovering a member’s email, toggling team-enforced MFA, deleting the workspace, and managing API keys / developer settings. When required, you’re prompted for a passkey or a current TOTP/backup code; the re-verification stays valid for a short window so a burst of actions doesn’t prompt repeatedly.

Note

Step-up is a soft gate for members who have no second factor at all (so magic-link-only users are never locked out) — unless the team enforces MFA, in which case a factor is mandatory. Setting up a passkey or TOTP (above) is what turns step-up into real protection for your account.

Account controls

Action	Where
Change email	Settings → Profile — dual confirmation (see below)
Delete account	Settings → Profile — confirmed via a signed link
Manage API keys	Settings → Developers — see REST API
Authorized OAuth apps	Settings → Developers → Authorized Apps — see MCP

Change your email address

Changing your email under Settings → Profile requires both mailboxes to agree before anything changes — a hijacked session alone can’t re-bind your account to an attacker’s address:

1. You enter the new address. Orimora sends two emails:
   • an authorisation link to your current address (it also doubles as an early warning, with a “this wasn’t me — reject” link), and
   • a verification link to the new address (proving you control it).
2. The change takes effect only after both links are confirmed (in either order). Until then, your address is unchanged.
3. Once applied, a security notification is sent to your previous address.

If you have a second factor, requesting the change is step-up protected. Each link is single-use and expires after 24 hours.

Email sending must be configured

The email-change form (like invitations and magic-link sign-in) is disabled until the operator has configured SMTP. See Configuration → SMTP. If your current mailbox is permanently inaccessible, a system administrator can set your address directly under Settings → Members (step-up protected and audited).

Deleting your account or workspace

Orimora has two distinct destructive flows. Both are irreversible and deliberately hard to trigger by accident — they are not the same as moving a document to the trash.

Delete your account

Under Settings → Profile, deleting your account is a two-step flow:

1. You type a confirmation phrase, which sends a signed confirmation link to your current email address.
2. Only by following that link (proving you control the inbox) is the deletion carried out.

This protects you against a single mis-click — and against a phishing page submitting the request on your behalf, since a stray click can’t complete the email step. Email link-preview bots are safe too: the link only shows a confirmation page, it doesn’t delete anything until you actively confirm.

When confirmed, your account is erased, not just hidden: your name and email are anonymised, every one of your sessions is revoked, your API keys and credentials are invalidated, and any live collaboration connection is dropped. This is a real GDPR right-to-erasure path.

Last administrator or workspace owner

If you are the only administrator of your workspace, account deletion is refused — otherwise the workspace would be left with nobody who can administer it. The same applies if you are the workspace owner (see Permissions → Workspace owner): transfer ownership (or admin rights), or delete the workspace, first — then delete your account.

Delete the workspace

Under Settings → Workspace → Danger zone, an admin with workspace-edit rights can permanently delete the entire workspace. To confirm you must type the workspace name, and — if you have a second factor — re-verify it (a recent TOTP/backup code or a passkey), the same step-up protection used for other high-impact actions.

Deleting the workspace permanently removes all of its data — documents, collections, and member data — in a single atomic operation (it either fully succeeds or changes nothing). Every member is signed out immediately (all their sessions are revoked) and detached from the workspace; their individual accounts survive so they can join or create another workspace. The deletion is recorded in the audit log before the data is removed.

Danger

Workspace deletion cannot be undone and is not covered by the trash. If you only want to remove a single space’s content, delete its collections instead. Make sure you have a current backup if there is any chance you’ll need the data again.

Operator hardening

Self-hosted operators should also review: at-rest encryption keys (LLM_ENCRYPTION_KEY, PUBLISHING_ENCRYPTION_KEY), the CORS allowlists (API_CORS_ALLOWED_ORIGINS, MCP_OAUTH_CORS_ORIGINS), and the audit log under Settings → Admin → Audit. All are covered in Configuration.