docs(auth-model): explain authn model

1. Identity model — email is the identity, three optional credential slots (username, password_hash, oidc_subject), the @-in-username ban that makes namespaces provably disjoint.
  2. Login dispatcher — @-in-input decides the path. Single DB lookup.
  3. Login paths — four ways in (username+password, email+password, email+magic-link, OIDC redirect) with their pre-conditions.
  4. Magic-link eligibility ladder — the three-branch table with OIDC unconditional reject, password flag-gated, no-credential allowed.
  5. Registration paths — four ways (/api/auth/register with full creds, email-only, grant-by-email invitation, OIDC JIT).
  6. Anti-enumeration — per-endpoint table showing what each surface returns and why; explicit note that instance-wide policy stays visible.
  7. Security trade-offs — mailbox-as-bypass (lenient vs strict), no native MFA, magic-link as bearer token, enumeration via timing.
  8. Rate limits — the five caps from PR 12 + classic auth, with env knobs.
  9. Audit events — table of 12 event names with reason keys; every entry verified grep-able in src/.
  10. Migration path — what existing instances see when PR 16-20 land (forward-only, non-destructive).
  11. Future direction — login_strategy — the seven-row matrix sketch as the explicit-policy north star.
  12. Out of scope — TOTP/WebAuthn, external→internal promotion, session_kind, differentiated session TTL, OCM, email-verified gates (PR 23), device-bound tokens (PR 22), anti-enum timing parity, per-user opt-out, login_strategy implementation.
  13. Related documents — cross-refs to magic-link-auth, ReBAC, share-integration, env-vars.
This commit is contained in:
Edouard Vanbelle
2026-06-02 23:09:31 +02:00
parent 00af0e8a89
commit ac2bdef96e
3 changed files with 188 additions and 1 deletions
+1 -1
View File
@@ -2,7 +2,7 @@
OxiCloud supports sharing resources with people who do not yet have an account on the instance, via per-email invitations and per-email sign-in links. Recipients are provisioned lazily as **external users** and authenticate exclusively through one-time URLs delivered by email, until they later set a password or link an OIDC identity.
This page is the architectural overview. For configuration knobs, see [Environment Variables](/config/env). For how grants are evaluated, see [ReBAC Authorization](/architecture/rebac-authorization). For how shares relate to grants, see [Share Integration](/architecture/share-integration).
This page is the architectural overview of the magic-link mechanism specifically. For the overall identity / login / registration model — what credential slots a user has, which login paths are available, anti-enumeration behaviour — see the canonical [Authentication model](/architecture/auth-model) page. For configuration knobs, see [Environment Variables](/config/env). For how grants are evaluated, see [ReBAC Authorization](/architecture/rebac-authorization).
## Why this exists