Security and assurance model.

Assurance matrix

Secret handling

• Tenant Member login attempts return a one-time client secret that stays only in browser function memory and a dedicated request header. It is never persisted, placed in a URL, or accepted as a session.
• Console sessions use an HttpOnly, SameSite=Lax cookie and carry explicit bootstrap or strong assurance. Ordinary management operations require strong assurance.
• Tenant Member credential reads expose only bounded metadata. Authenticator IDs, public keys, counters, and WebAuthn ceremony payloads remain internal.
• Invitation acceptance proofs are stored as hashes, delivered directly to the invitee in a browser URL fragment, and never returned to Tenant administrators or carried in an HTTP request line.
• Tenant Member verification and password-reset proofs are one-time, expiring, and stored only as hashes. Their recipients and delivery payloads are encrypted with versioned authenticated context.
• Project service credentials use environment-specific visible prefixes plus keyed server hashes, expire, permit at most two active versions per service account, and are returned only on issue or exact idempotent replay.
• OAuth client secrets use a visible prefix and keyed hash, expire, permit a maximum two-secret rotation overlap, and are returned only on issue or exact idempotent replay.
• OAuth RSA private signing keys are encrypted with versioned AES-256-GCM keys and authenticated row context. JWKS contains only active and still-needed retiring public keys.
• Authorization request handles, codes, and access tokens are stored as hashes. OpenID subjects are random, persisted, and pairwise per application.
• Resource-bound tokens carry one exact audience. UserInfo rejects them, and the authorization decision API derives Tenant, principal, audience, and capabilities only from the active token record.
• Project User session and login references are stored hashed in PostgreSQL.
• Support subjects, diagnostics, messages, attachment metadata and bytes, and external references use versioned AES-256-GCM encryption with Tenant, case, field, and child identifiers as authenticated context.
• The BFF substitutes separate UUID bearer tokens before anything reaches browser code.
• Biometric source images are forwarded to a provider and not retained by ComplicatedAuth.

Delegated authorization boundary

A Resource Server identifier and delegated scope name are immutable protocol contracts. An OAuth Application may request only scopes in its active administrative grant, and Tenant Member consent can only narrow that set. ComplicatedAuth revalidates the grant at authorization, approval, code exchange, and online decision time.

The baseline scope-v1 policy is intentionally capability-based. It does not claim that an opaque resource belongs to a principal, and it does not turn caller-supplied context into authority. Customer Resource Servers remain responsible for their own object mapping. See the delegated authorization guide.

Production controls still required

• Production configuration and monitoring for the shared TTL-backed RedisReferenceStore; the in-memory store remains development-only.
• Operational custody, scheduled rotation, re-encryption, and recovery procedures for the configured data-encryption keyring.
• Backup/restore drills that verify migration checksums, keyring availability, recurring maintenance, and live-session preservation.
• Malware-scanning and quarantine policy before support attachments are opened in privileged operator tooling.
• A metadata trust policy for attested security keys.
• A liveness and anti-spoofing contract for facial authentication.
• Service-credential rotation drills, secret scanning, and a clean repository history.