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:
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user