The power of nothing
No secret vault means no jackpot breach event.
Security is strongest when the browser never handles confidential exchange secrets and backend services treat identity tokens as verifiable artifacts, not implicit trust signals.
Security architecture
Threat model focused on reducing credential breach impact.
ZKAuth security posture is tied to a concrete OAuth implementation contract: strict authorize inputs, backend token exchange, and deterministic JWT validation.
Covered threat scenarios
Protected
Redirect and callback tampering
Exact redirect URI matching and strict state validation reduce callback manipulation and CSRF-style auth hijack risk.
Protected
Frontend credential misuse
Backend-only token exchange prevents client secrets from being exposed in browser code or intercepted frontend traffic.
Mitigated
Forged access tokens
RS256 verification against JWKS and claim checks (`iss`, `aud`, `exp`) mitigates acceptance of invalid tokens.
Mitigated
Identity mapping drift
Using `sub` as the stable local anchor mitigates user-account mismatch caused by optional or changing profile claims.
Outside direct scope
- Compromised user devices, browser malware, and endpoint takeover.
- Weak account recovery flows and social engineering susceptibility.
- Authorization/business-logic flaws after a valid authentication event.
- Unreleased dependencies such as refresh-token-centric or userinfo-centric login assumptions.
Operational baseline controls
- Enforce HTTPS and strict request validation for authorize/callback/token endpoints.
- Keep `client_secret` in backend secret stores with rotation and access auditing.
- Generate high-entropy state values and reject any callback mismatch deterministically.
- Verify JWT with JWKS cache strategy and fail closed on signature or claim violations.
- Monitor token exchange failures, callback anomalies, and claim-validation rejection rates.
Public communication boundary
Security documentation should be transparent without promising unsupported behavior. Keep the split strict:
- Public pages can document supported OAuth contracts, flow roles, and secure integration defaults.
- Public pages must not expose secrets, private keys, internal runbooks, or environment topology.
- Implementation caveats must be explicit when capabilities are unavailable or subject to change.