nextcloud / nextcloud/server

Allow administrators to enforce passwordless Passkey/WebAuthn login

Open
#64,390 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

0. Needs triage enhancement
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:

  1. Interactive browser login
  2. Mobile and desktop client authentication
  3. WebDAV, CalDAV and CardDAV access
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.