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)
Section titled “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
Section titled “Add a passkey”- Go to Settings → Security.
- Click Add passkey, optionally name it (e.g. “MacBook Touch ID”).
- 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
Section titled “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
Section titled “Manage / remove”Each passkey can be renamed or deleted from the list. Removing a passkey immediately prevents it from being used to sign in.
Sessions
Section titled “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)
Section titled “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
amrofmfa/a recognised second factor, or an MFAAuthnContextClassRef). 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
Section titled “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 MFAAuthnContextClassRefsuch 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.
Account controls
Section titled “Account controls”| Action | Where |
|---|---|
| Change email | Settings → Profile — confirmed via a signed email link |
| 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 |
Operator hardening
Section titled “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.