Passkeys (WebAuthn)

Syncplify Server! supports passkeys, the industry standard passwordless sign in method built on WebAuthn (FIDO2). A passkey is a cryptographic credential stored on the user's device (a phone, a laptop with a fingerprint reader or face unlock, or a hardware security key) that signs a server issued challenge instead of transmitting any secret. This page explains where passkeys apply, how they interact with two factor authentication, how credentials are bound to host names, and how they behave in a high availability cluster.

Where passkeys apply

Passkeys can be used by all three account types, each on its own login page:

• SuperAdmins sign into the SuperAdmin UI.
• Admins sign into the Admin UI of their virtual site. Admin passkeys are scoped to one virtual site, so the virtual site must be entered on the login page before the passkey button becomes active.
• Users sign into the WebClient. Passkeys are available to normal users and to OIDC users. LDAP and SAML users cannot enroll passkeys, because their authentication is delegated entirely to the directory or identity provider, and a local passkey would keep working even after the account is disabled on the directory side.

Passkeys are available in every edition of the product; no specific license tier is required.

How signing in works

Every login page shows a "Sign in with a passkey" button when the browser supports WebAuthn. Passkeys are enrolled as discoverable credentials, so the user does not need to type a username first: the browser lists the matching passkeys for the site, the user picks one, unlocks it with the device screen lock (PIN, fingerprint, or face) or with a hardware security key, and is signed in. All the usual account checks still run on every passkey login: account status, allow lists, protocol permissions, connection limits, and scripted authentication events for WebClient users.

Passkeys and two factor authentication

Every passkey ceremony in Syncplify Server! requires user verification, which means the authenticator itself must confirm the user's identity with a PIN or a biometric before it signs the challenge. A verified passkey is therefore inherently two factor: something the user has (the device holding the key) plus something the user knows or is (the PIN or the biometric). For this reason a successful passkey login does not ask for a TOTP one time code, even when the account has an authenticator app enrolled or is required to use MFA. Password logins are unaffected and keep their usual second factor behavior.

Host name binding

A passkey is cryptographically bound to the host name (the WebAuthn relying party ID) it was created on. A passkey enrolled on files.example.com works on that host only; if the same virtual site is also reachable as transfer.example.com, a separate passkey must be enrolled there. Keep this in mind when you plan bindings and additional host names for your virtual sites, and when you migrate a deployment to a new domain: after a host name change users must enroll new passkeys and can keep signing in with their password in the meantime.

WebAuthn defines the relying party ID as a domain name, so a passkey can only exist for a login page that was opened under a DNS name. A page opened by IP address (for example https://192.168.10.20:8443) or by a short host name with no domain (for example https://sftpserver:8443) cannot enroll or use passkeys: the server declines to start the ceremony and tells the person at the browser to open the page under its full DNS name instead. Password and SSO sign in are not affected and keep working on any address. The one exception is localhost, which is accepted for local testing.

Browsers refuse IP addresses on their own. Some password manager extensions do not, and older versions of Syncplify Server! accepted what they sent, so a passkey may exist that was enrolled while the server was reached by IP address. Such a passkey can no longer be used: enroll a new one under the DNS name of the server.

Enrollment and management

Each account manages its own passkeys from its settings page:

• SuperAdmins: SuperAdmin UI, Settings, Security tab.
• Admins: Admin UI, Settings, Security tab.
• Users: WebClient, Settings, Authentication tab.

Every account can hold up to 10 passkeys, and each one can be named, renamed, and deleted. Administrators additionally have oversight:

• Admins can review and revoke any user's passkeys from the user editor.
• SuperAdmins can review and revoke any Admin's passkeys through the REST API.

Revoking a passkey takes effect immediately: the next login attempt with the revoked credential is denied. Passkeys are never the only credential on an account; password (or SSO) sign in always remains available, so a lost device never locks anyone out.

Security properties

• The private key never leaves the user's device or security key; the server stores only the public key.
• Nothing that is typed or stored on the server can be phished or replayed: each login signs a fresh, single use challenge, valid for five minutes.
• Credentials are bound to the exact host name and origin, which defeats lookalike domain phishing.
• The server verifies the authenticator's signature counter and rejects logins that look like a cloned credential.
• No personal information is stored on the authenticator; the account reference kept on the device is an opaque salted hash.

Log events

Passkey activity is written to the log with numeric event IDs, so a log collector or a SIEM can follow it without parsing text. Log event IDs lists every ID with its fields.

What happened	Users (WebClient)	SuperAdmins and Admins
A passkey sign in was rejected	3107	6108
A passkey was enrolled	3206	6208
A passkey was deleted	3207	6209
A passkey enrollment was refused	3211	6210

A successful passkey sign in is the ordinary sign in event (3001 for users, 6001 for SuperAdmins and Admins) with passkey as its authMethod.

The enrollment refused events are written when the server turns down what the browser, or the password manager acting for it, returned at the end of an enrollment. They are warnings, so a node records them at its default log level, and the comment of the record says what the validation refused: for example an origin that does not match the address the page was opened under, or a user verification that was not performed. The comment of a rejected sign in says why in the same way. These records are the first place to look when a passkey cannot be enrolled or used; the person at the browser is only told that the request was refused.

High availability

Passkey credentials and in flight ceremony state are stored in the shared database, so in an HA cluster a login can begin on one node and complete on another without any special configuration.

Browser support

Passkeys work in all current versions of Chrome, Edge, Safari, and Firefox, on Windows, macOS, Linux, Android, and iOS. On browsers without WebAuthn support the passkey button and the enrollment section are simply hidden, and password or SSO sign in works as usual.