# Security support and threat model matrix

WRNexus security controls are defense layers, not substitutes for TLS, secret
management, database isolation, or operational monitoring. This matrix defines
the supported 0.8 contracts and the boundary application owners retain.

| Area                    | Framework guarantee                                                                                                                                     | Application/operator responsibility                                                                           |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Sessions and passwords  | Rotating sessions, idle/absolute expiry, revocation, password hashing policy, trusted-device controls                                                   | TLS, durable session storage, breach response, account recovery policy                                        |
| MFA and passkeys        | One-use OTP/recovery state, TOTP counter replay defense, WebAuthn challenge consumption, RP/origin provider inputs, signature-counter regression checks | Use a conformant WebAuthn provider, configure the exact public origin/RP ID, transactional credential storage |
| OAuth/OIDC              | State consumption, PKCE, safe return URLs, strict issuer discovery, HTTPS endpoints, RS256 JWKS rotation, nonce/audience/`azp`/`at_hash` validation     | Register exact redirect URIs, protect client secrets, select trusted issuers and scopes                       |
| JWT                     | HS256 local keyrings and bounded HTTPS RS256 JWKS caches with `kid` rollover                                                                            | Rotate/retire keys deliberately, set issuer/audience/expiry/max-age, revoke refresh families                  |
| CAPTCHA and rate limits | Expiring one-use challenges, action/session binding, bounded create/verify endpoints                                                                    | Treat CAPTCHA as one signal and keep route/account/network rate limits                                        |
| Encrypted HTTP          | AEAD, request context binding, age checks, optional one-use replay stores                                                                               | Keep HTTPS, use a shared replay store across instances, rotate server-managed keys                            |
| Authorization           | Explicit policies/roles and deny responses                                                                                                              | Model tenant/object ownership and test privilege boundaries                                                   |
| Browser/runtime         | Production CSP, HSTS, MIME-sniffing, referrer/permissions policies and safe hydration serialization                                                     | Configure allowed origins/sources, terminate TLS correctly, review third-party scripts                        |

`AUTH_SECURITY_EVENT_TYPES` is the stable machine-readable authentication audit
event vocabulary. Events include an ID, timestamp, severity and available actor,
user, session, IP, user-agent and structured data. Consumers should alert on
critical events and retain warning/critical records according to their policy;
never place credentials or raw tokens in event data.

Protocol and adversarial tests cover replay, expired state, counter regression,
key rotation, algorithm/key-type confusion, issuer/audience/nonce mismatch,
unsafe return URLs, request binding, rate limiting, and built production response
headers. Live provider certification remains an integration responsibility
because provider metadata and credential policies are deployment-specific.
