Sign In
DarkAuth sign-in looks like a normal hosted login screen, but the password exchange is different. The user portal uses OPAQUE, a password-authenticated key exchange, so the password is not posted to the server as a plaintext form value.
Standard sign-in flow
Section titled “Standard sign-in flow”When an application needs a user to authenticate, it redirects the browser to DarkAuth. If the user is not already signed in, DarkAuth shows the login screen. After OPAQUE authentication succeeds, DarkAuth creates or updates the user session and continues the authorization flow.
The flow normally looks like this:
- The application redirects to DarkAuth.
- The user enters email and password.
- The browser and server complete the OPAQUE login messages.
- DarkAuth checks whether password reset or MFA is required.
- DarkAuth asks for consent if an application authorization request is pending.
- The user returns to the application with an authorization code.
If there is no pending application request, the user lands on the dashboard instead.
Federated sign-in
Section titled “Federated sign-in”Some email domains are configured by an administrator to use an external OIDC provider. In that case, DarkAuth may route the browser to the organization’s provider instead of asking for the local password first.
The application still redirects to DarkAuth, and DarkAuth still returns the final authorization result to the application. The external provider is only used for the user’s sign-in step.
Federated sign-in can authenticate the account, but it does not automatically unlock zero-knowledge account keys. If an application needs encrypted key material, DarkAuth may ask for an unlock method after federated sign-in, such as a recovery key, passkey PRF, trusted-device approval, or any other configured envelope that can unlock the account key locally.
Passkey sign-in
Section titled “Passkey sign-in”If passkeys are available for the account and browser, a user may sign in with a passkey. Some passkeys are authentication-only. Others support WebAuthn PRF and can also unlock encrypted account material.
If a passkey signs the user in but cannot unlock keys, the session is key locked. The user can still access ordinary account pages, but zero-knowledge clients need an additional unlock method before DarkAuth can deliver client app keys.
Registration
Section titled “Registration”Self-registration is controlled by administrators. If it is enabled, users can create an account from the sign-in screen. If it is disabled, the sign-up route sends users back to login and accounts must be created or invited through an administrative flow.
Registration also uses OPAQUE. The server stores the OPAQUE record for future authentication, not the user password.
Organization context
Section titled “Organization context”Some users belong to more than one organization. When an application needs an organization-specific session, DarkAuth may ask the user to choose an organization. If the user belongs to exactly one active organization, DarkAuth can select it automatically. If multiple active memberships exist and no organization was provided, the flow may require an explicit choice.
The selected organization can appear in tokens as org_id, org_slug, roles, and permissions.
What can interrupt sign-in
Section titled “What can interrupt sign-in”Several security checks can pause a normal login:
- The account may require a password change before continuing.
- OTP may be required by user, admin, or organization policy.
- Email verification may be required for the requested flow.
- A federated domain may redirect the browser to an external provider.
- A zero-knowledge authorization request may require a key unlock step.
- The authorization request may be invalid, expired, or not allowed for the client.
These interruptions are intentional. They keep the application integration simple while allowing the identity system to enforce security policy centrally.