Zero-Knowledge

Zero-knowledge features are easiest to understand as a key custody decision. DarkAuth can help applications authenticate users without the server learning the password, and it can help trusted apps receive client-scoped key material without storing that plaintext key material on the server.

What DarkAuth protects

DarkAuth uses OPAQUE for password authentication. In the OPAQUE flow, the password is not sent to the server. The server stores an OPAQUE record that lets it participate in future logins without learning the password.

For zero-knowledge enabled apps, the browser can derive key material after login, unwrap account key material locally, derive a client app key for the requesting app, encrypt that key to the app’s ephemeral public key, and deliver it through the URL fragment. The server stores only encrypted envelope material and a hash binding for the handoff.

The account key can be unlocked by different envelope types depending on what the user has configured:

• Password-derived material from OPAQUE login.
• A passkey with WebAuthn PRF support.
• A recovery key saved by the user.
• A trusted-device approval from another unlocked browser.

Some sign-in methods authenticate the user but do not unlock keys. For example, an external federated login or an authentication-only passkey can create a valid session that is still key locked. A key-locked session must complete an unlock step before a zero-knowledge app can receive a client app key.

What this does not protect

Zero-knowledge does not mean the browser never sees the key. The browser code needs the key to decrypt data or hand it to an application. That means users still rely on:

• The JavaScript served by DarkAuth.
• The JavaScript served by the application.
• The browser and operating system.
• Browser extensions and device security.
• Correct application behavior after it receives the key.

If any of those are compromised, a key may be exposed while it is in use.

Admins and the DarkAuth backend can see account metadata, client configuration, encrypted envelopes, key-delivery version, and audit events. They cannot see the user’s password, OPAQUE export key, plaintext account root key, plaintext client app key, plaintext recovery key, passkey PRF output, or decrypted application data during the designed flow.

Unlock once per sign-in

You unlock your keys once each time you sign in, not once per tab. DarkAuth keeps an encrypted copy of your account key in the browser. The key that opens it stays on the server and belongs to that one sign-in. New tabs and reloads open it without asking you again.

Signing out, the sign-in expiring, or signing it out from Where you’re signed in deletes the server key. The copy in the browser can then never be opened.

The trade-off: while you are signed in, someone with a copy of your browser profile, or a malicious script on the DarkAuth site, could open your keys. Sign out on shared computers, and sign out any browser you do not recognize. Your organization may turn this feature off.

Where you’re signed in

Account security lists each browser where you are signed in, with when it started and was last used. You can sign out any one of them, or sign out all others.

Remembered app approvals

Once you approve an app, DarkAuth remembers it. Next time that app asks for the same access, you go straight back to it without the approval screen, including zero-knowledge apps. If the app asks for more, you see the screen again.

You can review and revoke approvals in account security. Revoking signs that app out and shows the approval screen next time.

Why app reloads can matter

Apps keep their client app key in memory, so reloading an app loses it. The app starts a new authorization to get the key again. While your DarkAuth sign-in is live this usually happens without a prompt. If not, you may need to sign in or unlock again.

Password reset tradeoff

Email password reset restores account access. It does not magically recover encrypted data that depended on old password-derived key material without another recovery envelope or app recovery path. If an app relies on zero-knowledge protected data, it should explain its recovery model clearly before users need it.

The benefit is that the server is not silently holding the user’s decryption key. The tradeoff is that recovery requires explicit design.

Federated account tradeoff

Federation lets an organization use its existing identity provider for sign-in, but the external provider still does not receive DarkAuth account keys. Users who sign in through federation need at least one DarkAuth-side key unlock method if they use zero-knowledge applications.