Skip to content
DarkAuth Docs

Developer Overview

Developers can integrate DarkAuth as a normal OIDC provider, as a zero-knowledge key delivery service for trusted apps, or as both. The right starting point depends on the kind of application you are building.

If your app just needs login, use standard OIDC. If your browser app needs user-held key material, use the ZK key delivery flow. If you are contributing to DarkAuth itself, start with the architecture and schema docs so your changes fit the existing controller, model, service, and OpenAPI patterns.

Integration paths

Section titled “Integration paths”

What DarkAuth expects from applications

Section titled “What DarkAuth expects from applications”

DarkAuth can authenticate users and issue tokens, but applications still own their authorization checks. Your backend should verify token issuer, audience, expiry, signature, scopes, organization context, and permissions before allowing protected actions.

For zero-knowledge apps, your frontend must also verify key-delivery bindings, decrypt envelope material in the browser, remove sensitive fragments from the URL, and avoid persisting plaintext key material unless you intentionally accept that tradeoff.

Local development

Section titled “Local development”

Use DarkAuth Mock when you want to exercise your app’s real OIDC flow without installing and operating a full DarkAuth instance. Use a real instance when you need to test OPAQUE, MFA, federation, provisioning, administration, or other behavior beyond the mock’s focused protocol surface.

When integrating against a real instance, use the default public client for local browser integration or create a new client for your app. Keep redirect URIs exact. If you need separate local, staging, and production environments, create separate client records so a mistake in one environment does not weaken another.