Passkeys In Released ProAuth User Stores: Sign-In And Account Management

On this page

A passkey removes the shared password from an individual sign-in. The rollout still needs a stable login domain, a place for users to manage credentials and a plan for the user who replaces a device.

ProAuth 3.0.0 shipped passkeys for UserStore sign-in and MFA. This follows the June preview with the released authentication capabilities and the decisions to make before enrollment.

Separate primary passkeys from MFA

A UserStore login passkey is a primary credential for a local UserStore user. It lets that user authenticate through a WebAuthn ceremony instead of entering the UserStore password.

Passkey MFA is configured separately. It can protect UserStore users and users authenticating through a federated identity provider. Adding an MFA passkey does not remove a UserStore password or make every sign-in route passwordless.

This distinction determines who owns the rollout. A team introducing local passkey sign-in needs to configure the UserStore identity provider. A team adding a further factor needs to review its MFA configuration and enrollment journey.

Establish the relying-party domain first

WebAuthn binds a credential to its relying party. A credential registered for one RP ID cannot simply be used under an unrelated RP ID after a domain change.

Choose the production login hostname and relying-party configuration before users enroll. Review the host URL, RP metadata and allowed origins together. A successful ceremony on a development hostname does not establish that the production configuration is correct.

The UserStore documentation and WebAuthn specification explain the configuration and protocol boundary. Treat the RP ID as a credential-lifecycle decision, rather than another branding field.

Test the browser ceremony and account journey

sequenceDiagram
    participant User
    participant Browser
    participant Authenticator
    participant ProAuth
    User->>Browser: Choose passkey sign-in
    Browser->>ProAuth: Request authentication challenge
    ProAuth-->>Browser: Challenge and relying-party parameters
    Browser->>Authenticator: Perform WebAuthn ceremony
    Authenticator-->>Browser: Signed authentication response
    Browser->>ProAuth: Submit response
    ProAuth->>ProAuth: Validate credential and ceremony
    ProAuth-->>Browser: Continue authentication

Registration also requires the user’s browser and authenticator. Listing a credential in an administration interface is different from completing that registration ceremony on the user’s behalf.

Account Management provides the self-service surface for managing credentials. Test adding another passkey, renaming a credential, removing a retired authenticator and returning to the application after authentication. Include both UserStore login passkeys and MFA credentials where they apply; they are distinct parts of the account.

Keep recovery in the rollout plan

Offering passkeys alongside passwords gives users time to enroll and exercise the new path. It also leaves password authentication and password recovery in the account’s threat model. A phishing-resistant sign-in option does not make a weaker fallback disappear.

For a pilot, verify the normal journey and the exceptions: an unavailable authenticator, a new device, an incorrect origin and a user with no registered passkey. Make the account-management entry point visible before inviting a wider population.

The Account Management guide describes the self-service surface; the passkey MFA guide covers the separate factor. Start with a repeatable enrollment and support process. Passwordless adoption depends on users being able to manage the credential after their first successful login.