Which authentication methods does the Web Client 2.0 support?

The Web Client 2.0 supports six authentication methods – considerably more than the Web Client 1.0 (Legacy), which only offered the standard sign-in. In each case, the method must be allowed on the Enterprise Server (Manage → Server settings → Connections → Supported authentications) and enabled for the user. In the sign-in dialog, users select the method under Authentication Method.

1. Standard (Username & Password) – sign-in with the server user's Password Depot credentials (default method).

2. SSPI (Domain Login) – sign-in with Windows domain credentials. The username must be entered in UPN format (user@domain.com) or in down-level format (DOMAIN\username).

3. Windows SSO (Negotiate) – passwordless sign-in via the existing Windows logon (Kerberos/SPNEGO). Prerequisites: Integrated Windows Authentication (IWA) is enabled in the server settings; IWA is enabled as an authentication method for the user, with a SAM account name or UPN on file; the device is a member of the domain (or of a trusted domain); the browser allows Negotiate for the server (Chrome/Edge: AuthServerAllowlist policy, can also be distributed via Group Policy; Firefox: network.negotiate-auth.trusted-uris).

4. Passkey (WebAuthn) – passwordless sign-in with a passkey (e.g. Windows Hello or a hardware security key). Passkeys can be registered, renamed, and removed in the web client's user profile; passkeys registered in the desktop client and in the web client are interchangeable.

5. Identity Provider (OIDC) – new as of 2.0: sign-in via OpenID Connect, e.g. with Entra ID, Ping Identity, Auth0, or a generic provider. The web client retrieves the available providers from the server. At the identity provider, the web client's base URL (origin only, without a path) must be registered as the redirect URI, and id_token must be allowed as a response type.

6. Azure AD / Entra ID (deprecated) – legacy Microsoft sign-in via a fixed app ID, for existing environments only. For new setups, support consistently recommends the OIDC route with your own Entra ID provider.

Two-factor authentication (2FA): TOTP is supported for all methods; on first sign-in, the web client shows the QR code for setting up the authenticator app. There are no trusted devices via the REST API – the 6-digit code is required on every sign-in. FIDO2 security keys as a second factor are not supported via the REST API (use TOTP or an email code instead); this is not to be confused with the passkey sign-in described in item 4.

Note: With the Web Client 1.x, sign-in via OIDC/Entra ID did not work – it is only available as of version 2.0. In a self-hosted web client, administrators can preconfigure the selection via config.json (defaultAuthMethod, disabledAuthModes).

Related topics:

• Connecting Entra ID (formerly Azure AD) to the Enterprise Server – requirements and recommended approach

• Setting up Single Sign-On (SSO) login to the Enterprise Server and troubleshooting errors

• How do I get the Web Client 2.0 and what are the requirements?

• Installing and deploying the Web Client 2.0 (on-premises)