Skip to content

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.

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.

  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.

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

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

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).

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).

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.
ActionWhere
Change emailSettings → Profile — confirmed via a signed email link
Delete accountSettings → Profile — confirmed via a signed link
Manage API keysSettings → Developers — see REST API
Authorized OAuth appsSettings → Developers → Authorized Apps — see MCP

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.