Allow administrators to enforce passwordless Passkey/WebAuthn login
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 36.9k
- Forks
- 5.2k
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 713
Description
[!TIP]
Help move this idea forward
- Use the 👍 reaction to show support for this feature.
- Avoid commenting unless you have relevant information to add; unnecessary comments create noise for subscribers.
- Subscribe to receive notifications about status changes and new comments.
Is your feature request related to a problem? Please describe.
Currently, Nextcloud can be configured to support Passkeys/WebAuthn, but the traditional username/password login remains available as a fallback.
For environments that require phishing-resistant authentication, administrators need a way to prevent users from bypassing Passkey authentication by using their password instead.
Enforcing 2FA does not fully solve this problem, because users can still start the login with their password and then complete the second factor.
Describe the solution you'd like
Add an administrator-configurable authentication policy that allows Passkey/WebAuthn to be enforced as the only interactive browser login method.
Possible configuration options:
- Enable Passkey-only login globally
- Enable Passkey-only login for selected groups
- Require user verification, such as PIN, Chip card or biometrics
- Prevent the normal username/password login from being used as a fallback
- Provide a recovery or break-glass mechanism for administrators
- Allow administrators to define how users without a registered Passkey are handled
The policy should clearly distinguish between:
- Interactive browser login
- Mobile and desktop client authentication
- WebDAV, CalDAV and CardDAV access
- App passwords, device tokens, OAuth tokens and other API authentication methods
…
The feature should not disable official mobile and desktop clients.
Mobile and desktop clients should continue to authenticate using an appropriate non-interactive mechanism, for example:
- OAuth/device authorization flow
- Device or app passwords
- Long-lived device/session tokens
The normal user password should not be required by the clients if Passkey-only browser authentication is enabled.
When the policy is enabled for a user:
- Browser login with username and password is not available, rejected or redirected to Passkey authentication.
- A registered Passkey is required for interactive web login.
- Password reset should not re-enable password-based browser login.
- App passwords, OAuth tokens and device tokens remain usable according to administrator policy.
- Administrators retain a documented recovery method in case a user loses all Passkeys.
The implementation should:
- Prevent bypass through alternative login endpoints.
- Apply the policy consistently to the normal login page, login flows and relevant authentication endpoints.
- Clearly document which APIs and client authentication methods remain available.
- Provide audit-log entries when the policy is enabled, disabled or bypassed by an administrator.
Describe alternatives you've considered
- Enforcing 2FA: This still allows password-based login as the first factor.
- Enabling Passkeys without disabling passwords: This makes Passkeys optional.
- Disabling password authentication at the reverse proxy: This may break mobile clients, WebDAV and other authentication flows and is difficult to configure safely.
Additional context
The goal is to support deployments where Passkey/WebAuthn is mandatory for interactive web access, while official mobile and desktop clients continue to work through dedicated device or OAuth authentication.
This should ideally be configurable globally and per group, with a safe recovery mechanism for administrators.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
The issue names no files or tests; it identifies the normal login page, login flows, relevant authentication endpoints, password reset, client/API authentication, group settings, recovery, and audit logging as areas to cover. Start by locating the existing Passkey/WebAuthn and authentication-policy flows. Done means browser password fallback is controlled without disabling supported client and API authentication, with recovery and audit behavior documented and tested.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100