auth-landscape

Reference map of authentication, unlock, and sealing-key primitives.

What this page is

noy-db is a zero-knowledge document store: every record is encrypted on the user's device before it reaches any storage backend. The whole key hierarchy hangs off one root — a key-encryption key (KEK) derived from a user credential, which wraps the per-collection data-encryption keys (DEKs) (see Core 02 — Enclave). "Login" therefore always means one concrete thing here: producing the material that unlocks the KEK.

This page maps the authentication, unlock, and sealing-key methods in common use, scores each on the dimensions that matter for a zero-knowledge offline-first vault, and names the @noy-db/* package that covers it — or states plainly that it is deliberately omitted, not covered, or out of scope. The next time someone asks "can we log in with Cognito / Active Directory / Windows / Touch ID / BankID?", the answer is one table lookup.

Three distinct functions get conflated as "auth"

Conflating these is the single most common source of misdesign in this space. A Windows DPAPI sealing provider is not an authenticator. A hypothetical on-google would not be different from on-oidc.

Session tiers, briefly

Several rows below refer to noy-db's session tiers — the three-rung privilege ladder that structures unlock (defined in full on session-tiers):

Dimensions

Legend: ✅ good fit · ⚠️ works with caveats · ❌ poor fit / breaks model

1. Knowledge factors

2. Possession — software OTP / link

3. Possession — hardware

4. Inherence — biometrics

Biometrics never are the secret — they gate access to a local credential. So the noy-db match is always indirect.

5. Threshold / split secrets

A recovery profile is an enrolled way back into the vault when the secret is lost (full lifecycle on session-tiers). Four profiles exist in the recovery API: paper (printed single-use codes), shamir (K-of-N shares held by trustees), multi-channel 2-of-3 (email OTP + device PIN + paper code; any two suffice), and admin-mediated (an admin issues a magic-link grant and the user adds one factor). Paper and Shamir are available today; multi-channel and admin-mediated declare their API surface and throw RecoveryProfileNotImplementedError when used.

6. OIDC / federated identity providers

All require online at auth time. All map to on-oidc with different issuer URLs. Differences are ecosystem fit and built-in 2FA strength, not protocol.

Server-side dependency — OIDC is the only on-* family that requires consumer-operated infrastructure. @noy-db/on-oidc uses a split-key model: the KEK is XOR-split into a deviceHalf (a per-device secret that never leaves the device) and a serverHalf held by a small HTTP service — a key connector — that verifies ID tokens against the issuer's JWKS and stores each user's serverHalf indexed by the token's sub claim. The package implements the client side and documents the two-endpoint server contract (PUT /kek-fragment, GET /kek-fragment); it deliberately does not ship a reference server, hosted instance, or deploy template. If you have no off-device infrastructure, prefer @noy-db/on-webauthn (platform passkey via Touch ID / Face ID / Windows Hello) — the same "Login with X" UX without a server, because the platform passkey is the device-bound credential.

7. Enterprise / directory protocols

8. OS keychain / device-local sealing — NOT authenticators

These don't authenticate the user — they protect the vault's root secret under OS-account guarantees. They map to the at-* family: implementations of the NoydbSealer interface that @noy-db/hub exports for managed-secret mode — the vault mode where the secret is machine-generated, sealed by the provider, and never shown to the user (see session-tiers). One caveat is structural: unlike every other satellite family, an at-* host can decrypt the vault it unseals — that is the point, and the safeguard is scoping the host to a dedicated vault (the trust boundary is spelled out on the at-* overview).

9. Cloud / centralized KMS & HSM — server-context sealing

Same family as section 8 (sealing, not auth) but server-side: at-* sealing providers for managed-secret mode in server contexts — a host you control opens a scoped vault to compute on a user's behalf.

10. Password managers / personal vaults

Out of scope for on-* — users compose them upstream by storing their secret there. Listed for completeness; not a wrap-key target.

11. Threat / context layers (modify, don't replace, the above)

12. Emerging / specialized

What's covered today

• Coverage is strong on offline-first primitives (TOTP, WebAuthn, recovery codes, Shamir, PIN, password) — the parts where zero-knowledge actually buys you something. That is deliberate.
• Coverage is uniform on OIDC. One on-oidc package handles every provider in section 6, because the protocol — not the brand — is the unit of abstraction. There is no on-cognito, on-okta, or on-google, and none is needed: they are issuer URLs in an on-oidc config.
• Sealing coverage is host-first. The at-* family ships providers for the host environment (at-env), macOS Keychain (at-macos-keychain), and the three major cloud KMSes (at-aws-kms, at-gcp-kms, at-azure-keyvault). There is no provider for Windows DPAPI, the iOS/Android keystores, Linux Secret Service, or HashiCorp Vault.
• Not covered today: on-prem directory bind (LDAP / Kerberos), smart cards (roaming WebAuthn covers most of that ground), standalone push-notification factors (reachable via on-oidc), and regional ID schemes (BankID, EUDI Wallet).
• Deliberately omitted: SMS OTP, security questions, pattern locks — each breaks the security model in a way stated in its table row.
• on-threat is structurally unique. It is the only on-* package that doesn't authenticate; it modifies how the others authenticate (lockout, duress, honeypot).

Why the hub and the on-* packages are separate

When you enroll recovery codes you install @noy-db/on-recovery and call db.team.enrollRecovery(...) on the hub — and the same two-package shape recurs for passwords and PINs. The split is deliberate: the hub owns the cryptosystem; the on-* package owns the user-facing credential format.

The shared "wrap a DEK set under a credential-derived key" primitive — mintWrappedDeksBlob / unwrapDeksFromBlob, exported from @noy-db/hub — derives an AES-GCM key from the credential string via PBKDF2-SHA256 (600,000 iterations) and encrypts the serialized DEK set. It is the same primitive whether the credential is a printed recovery code or a typed password. What differs is what counts as a well-formed credential: a Base32-with-checksum string (on-recovery), a validated password (on-password). (@noy-db/on-pin follows the same pattern but at 100,000 PBKDF2 iterations — a PIN slot's protection window is short and idle-timeout-bounded, and its wire format is deliberately incompatible with the 600K one.)

The classification rule behind the table: does the thing produce wrap-key material directly, or does it just shape user input?

• Produces wrap-key material directly (secret → PBKDF2 → KEK; KEK → AES-KW → DEKs; the wrap-DEKs primitive itself) → hub. There is one cryptosystem, and there is one of it.
• Shapes user input (Base32 codes with checksums, password length policies, 4-digit PINs, WebAuthn ceremonies, OIDC token flows) → an on-* package. There are many possible shapes; each consumer picks one.

This is also why @noy-db/on-recovery stays a separate small package rather than a hub subpath: keeping the format outside the hub is what lets you swap Base32 for another code format without forking the cryptosystem.

Classifying a method that isn't in the tables

Evaluating an authentication method this map doesn't list? Walk the same checklist the map itself was built with:

1. Is it an authenticator, an IdP, or a sealing-key store? Mis-classification means the wrong package family — and the wrong threat model. See "Three distinct functions" above.
2. Does the protocol already have a generic package? A vendor-flavored OIDC provider is an on-oidc config, not a missing package. A vendor-flavored OS keychain is a sealing concern (at-*), not an authenticator.
3. Can it carry wrap-key material on its own? If not (LDAP bind, Kerberos tickets, Cognito tokens), the only honest shape is split-key — the same pattern as on-oidc — or gate-only composition with a real authenticator.
4. Does it work on shared devices? If only on personal devices, treat that as a hard constraint in your deployment. Tier 3 (on-pin) is never safe on shared workstations regardless.

Common questions this map answers

See also

• session-tiers — how the primitives compose into the three-tier session lifecycle and policy gates.
• on-* family catalog — factor table and per-package summaries.
• at-* family overview — the sealing-provider family: trust boundary, managed-secret mode, per-package summaries.
• Core 02 — Enclave — the key hierarchy (secret → KEK → DEKs) everything on this page ultimately unlocks.
• Core 06 — Permissions and keyring — the keyring: the per-user record of wrapped keys that every method on this page ultimately opens.
• Per-package READMEs: on-webauthn, on-oidc, on-pin, on-totp, on-email-otp, on-recovery, on-shamir, on-magic-link, on-password, on-threat