Preview: Passkeys In ProAuth User Stores

Passwords are not going to disappear from enterprise systems because one feature flag changes.

They disappear when the surrounding login model is ready: the domain is stable, users have a place to register and recover credentials, support teams understand what happens on a new device, and the authentication server can enforce the right behavior without locking out people who have not enrolled yet.

That is the practical way to read passkeys in the upcoming ProAuth v3 preview. ProAuth adds WebAuthn-based passkey authentication for UserStore sign-in and passkey-based MFA, but the rollout decision is not only “enable passkeys”. It is also a relying-party decision. The hostname users see during login becomes part of the credential boundary.

The preview is meant to make passkeys usable in ordinary ProAuth deployments: a UserStore user can sign in with a security key, platform authenticator such as Windows Hello, Touch ID, or Face ID, or a synced passkey from a password manager. The same v3 work also adds account-management surfaces so users can register, rename, and remove passkeys without turning every credential change into an administrator task.

In a password flow, the user proves knowledge of a secret that can be typed into the wrong site.

In a WebAuthn flow, the browser and authenticator perform a public-key ceremony scoped to a relying party. The authenticator signs a challenge, ProAuth verifies the assertion with the registered public key, and the credential is only useful for the relying party identifier it was registered with. The W3C WebAuthn specification defines public-key credentials as scoped to a WebAuthn relying party, and the RP ID is the domain identifier that controls where a credential can be used.

For users, that can look like a much simpler interaction:

select a passkey from the username field when Conditional UI is available;
click a sign-in-with-passkey button when an explicit ceremony is clearer;
approve the authenticator prompt with a device unlock, PIN, biometric gesture, or security-key touch;
continue without entering the account password.

For product and security teams, the important shift is not only convenience. A copied password can be replayed. A copied WebAuthn assertion is bound to a challenge and origin context, and the credential private key does not leave the authenticator.

sequenceDiagram
    autonumber
    participant User
    participant Browser
    participant ProAuth as ProAuth UserStore login
    participant Authenticator

    User->>Browser: Open the ProAuth login page
    Browser->>ProAuth: GET login page
    ProAuth-->>Browser: Username field plus passkey options

    alt Conditional UI
        Browser->>ProAuth: Request WebAuthn assertion options
        ProAuth-->>Browser: PublicKeyCredentialRequestOptions
        Browser->>User: Offer available passkeys in autofill
        User->>Browser: Select a passkey
    else Explicit passkey button
        User->>Browser: Choose sign in with passkey
        Browser->>ProAuth: Request WebAuthn assertion options
        ProAuth-->>Browser: PublicKeyCredentialRequestOptions
    end

    Browser->>Authenticator: navigator.credentials.get(options)
    Authenticator->>User: Request user verification or presence
    User->>Authenticator: Approve
    Authenticator-->>Browser: Signed assertion
    Browser->>ProAuth: Submit assertion
    ProAuth->>ProAuth: Verify challenge, RP ID, origin, signature, and user verification policy
    ProAuth-->>Browser: Complete login and continue authorization flow

This is preview content for the upcoming ProAuth v3 release. It describes the passkey behavior available in the preview, not a generally released v3 version.

The RP ID is a deployment decision

The most important passkey setting is not the display name.

ProAuth derives the WebAuthn RP ID from BaseServiceSettings:HostUrl. If users access ProAuth at https://login.example.com, the derived RP ID is login.example.com. The UserStore passkey documentation is explicit about the consequence: passkey registrations are bound to that domain and cannot be used on a different domain.

That makes hostname planning part of rollout planning. If the login host changes after users register passkeys, those existing passkeys will no longer authenticate for the new RP ID. The documentation states this more strongly: changing the RP ID after registration invalidates existing passkey registrations.

Plan this before enrollment:

Decision	Why it matters
`BaseServiceSettings:HostUrl`	ProAuth derives the primary origin and RP ID from this URL.
Login hostname	Users should register passkeys on the hostname that will stay in production use.
RP ID scope	The RP ID must be equal to the origin host or a registrable domain suffix of it.
`PasskeyAllowedOrigins`	Additional origins can be configured when the deployment needs them; the primary origin still comes from `HostUrl`.
Migration timing	A later hostname or RP ID change can turn a passkey rollout into a re-enrollment project.

Using a broader RP ID can be useful when the WebAuthn rules and deployment model allow it. For example, a login page on auth.company.com may use auth.company.com or company.com as the RP ID. That choice should be made deliberately. Broader scope can help across related subdomains, but it also means the organization is committing to that domain boundary as the credential boundary.

What ProAuth v3 preview exposes

Passkey support is configured on the UserStore identity provider instance. The core options are intentionally operational rather than magical:

Option	Default	Role
`PasskeyEnabled`	`false`	Enables passkey registration and authentication for the UserStore IDP instance.
`PasskeyRpName`	`ProAuth`	Sets the relying-party display name shown by clients that expose it.
`PasskeyAllowedOrigins`	empty	Adds optional comma-separated allowed origins beyond the primary origin derived from `BaseServiceSettings:HostUrl`.
`PasskeyConditionalUiEnabled`	`true`	Enables WebAuthn Conditional UI so passkeys can appear in the username-field autofill experience.
`PasskeyAllowLoginWithoutUserVerification`	`false`	Allows login passkeys without user verification; the docs mark this as not recommended.
`PasskeyEnforcePasswordless`	`false`	Requires users who already have at least one passkey to use passkey login instead of password login.
`PasskeyAuthenticatorTimeoutSeconds`	`180`	Controls the WebAuthn ceremony timeout.
`PasskeyAttestationConveyance`	`none`	Sets the attestation preference: `none`, `indirect`, `direct`, or `enterprise`.
`AccountManagementLinkVisibility`	`auto`	Controls whether the login page shows the Account Management link.

The defaults say quite a lot about the intended rollout model. Passkeys are opt-in. Conditional UI is on by default because it reduces friction where the browser supports it. User verification is required for normal login unless an administrator explicitly weakens that policy. Attestation defaults to none, which is the right default for many deployments that do not need to verify authenticator make and model.

The preview also separates passkey sign-in from passkey MFA. Login passkeys for UserStore users are first-factor credentials and use userVerification: "required" in the documented login model. Passkey MFA is a second factor and operates with userVerification: "discouraged" because the first factor has already established the user’s identity; the second ceremony proves possession of the registered credential.

That distinction matters for storage and scope too. Login passkeys are stored with the User Store account. MFA passkeys are stored in the ProAuth database, which allows passkey MFA to work for UserStore users and federated identity-provider users when a Passkey MFA instance is configured.

Enforcement must follow enrollment

Passwordless enforcement is where it is easiest to overstate the feature.

ProAuth v3 preview supports enforcement at two levels:

IDP-level enforcement with PasskeyEnforcePasswordless = true;
user-level enforcement through the Account Management portal, where an individual user can require passkey login for their own account.

Both levels apply only when the user already has at least one registered passkey. Users without passkeys can still log in with a password.

That is the right failure mode. A passwordless policy that applies to people with no registered passkey is not stronger authentication; it is a lockout generator. For most teams, the sequence should be enrollment first, monitoring second, enforcement third.

A practical rollout usually looks like this:

Confirm the production login hostname and RP ID.
Enable passkeys for one UserStore IDP instance.
Keep password login available while users register passkeys.
Surface the Account Management link so users can add and manage credentials.
Watch registration, failed ceremonies, support volume, and device-change cases.
Enable passwordless enforcement only for users or IDP instances where enrollment is already real.

Account management is part of the feature

Passkeys need a lifecycle surface. Users replace devices, add security keys, rename credentials, remove old authenticators, and sometimes need to understand why a synced passkey behaves differently from a device-bound key.

The v3 account-management portal is the self-service surface for that lifecycle. It runs at /account/security and uses a dedicated OIDC authentication flow before rendering account data. For UserStore users, the portal exposes login passkey management, MFA passkey management, and password change. Federated users see MFA passkey management when it applies, but not UserStore login passkeys.

The login page can show an Account Management link. With AccountManagementLinkVisibility = auto, ProAuth shows it when passkeys are enabled. Client applications can also use the documented pa_account_management_url claim from ID tokens or UserInfo responses to present the account-security link inside the application experience.

This is not just a usability detail. If users cannot manage passkeys safely, administrators become the recovery interface for every device change. The ProAuth docs also draw a hard boundary around registration: administrators can list and remove UserStore passkeys through the administration API, but they cannot register a passkey for a user because registration requires the WebAuthn ceremony to run in the user’s browser and authenticator.

Security details that should stay visible

The passkey rollout checklist should include a few settings that are easy to skip when the demo works on the first try.

User verification. For UserStore login passkeys, keep user verification required unless there is a very specific reason to relax it. PasskeyAllowLoginWithoutUserVerification exists, but the documentation marks it as not recommended.

Attestation. The default none avoids collecting authenticator attestation where the deployment does not need it. Use direct or enterprise only when the organization has a real requirement to verify authenticator properties and is prepared to handle the operational and privacy implications.

Backup eligibility. WebAuthn exposes backup eligibility and backup state as credential properties. Synced passkeys can be backup-eligible; platform-bound or hardware-backed credentials may not be. That difference matters for user support and recovery planning.

Allowed origins. Do not treat PasskeyAllowedOrigins as a quick fix for an unclear deployment topology. The primary origin still comes from BaseServiceSettings:HostUrl, and the RP ID remains the credential boundary.

Account API hardening. The v3 release notes track related account-management hardening work, including stricter tenant and identity-provider validation, CSRF protection for account APIs, HTTPS-only cookie handling, configurable relying-party metadata and allowed origins, and sanitized error behavior.

The conference demo script for the 2026 identity protocols talk treats passkeys as part of the authentication baseline in front of OAuth and OpenID Connect. That framing is useful. Passkeys do not replace the rest of the protocol baseline: authorization code flow, PKCE, exact redirects, issuer validation, audience discipline, refresh-token handling, and logout still matter.

They improve the moment where the user proves who they are.

For teams using ProAuth UserStore sign-in, the v3 preview creates a clear path: introduce passkeys without removing password fallback too early, let users manage credentials through account management, and make the RP ID decision before the first production enrollment. That last point is the one to write on the rollout plan in bold. Passkeys are friendly at the login screen, but they are strict about the domain they trust.