Skip to content

Conversation

@swissbit-eis-admin
Copy link

@swissbit-eis-admin swissbit-eis-admin commented Dec 17, 2025

  • require resident keys/UV for new FIDO2 registrations, but retry without if unsupported
  • allow username-less login by probing discoverable credentials first, then fall back to the old flow
  • keep legacy (non-discoverable) registration/login paths working for older authenticators

Updated by #57154

  • Resolves: #

Summary

TODO

  • ...

Checklist

- require resident keys/UV for new FIDO2 registrations, but retry without if unsupported
- allow username-less login by probing discoverable credentials first, then fall back to the old flow
- keep legacy (non-discoverable) registration/login paths working for older authenticators
@susnux
Copy link
Contributor

susnux commented Dec 17, 2025

Thank you for your contribution!
Pull requests need to go through the master branch first and then can be backported if needed.
So could you change the pull request target to master?

@swissbit-eis-admin
Copy link
Author

swissbit-eis-admin commented Dec 17, 2025 via email

@p1gp1g
Copy link
Contributor

p1gp1g commented Dec 17, 2025

Non-discoverable passkeys aren't "legacy", and they are useful when using a hardware tokens with limited number of key slots.

Registering a discoverable key should be an explicit action from the user:

  • there can be 2 buttons, one for the discoverable, another for the non-discoverable
  • or an input checkbox to use a discoverable or not

@swissbit-eis-admin
Copy link
Author

swissbit-eis-admin commented Dec 17, 2025 via email

@p1gp1g
Copy link
Contributor

p1gp1g commented Dec 17, 2025

With the setting, this is an appreciated feature 👍 (talking as a user).

BTW, we still need to fix this issue to get passkey only login: #44342

@ChristophWurst ChristophWurst self-requested a review December 17, 2025 15:56
@swissbit-eis-admin
Copy link
Author

swissbit-eis-admin commented Dec 17, 2025 via email

@tushev
Copy link

tushev commented Dec 18, 2025

Yes, choosing discoverable or non-discoverable credential is a must.

Also, UV must be mandatory for discoverable credentials. We don't want totally passwordless+usernameless logins without even a PIN (or other UV), this would be a disaster.

Or there could be an option to disable UV with big red 'I understand the risks' warning (ideally, this should be controlled by admins depending on organization policies).

@swissbit-eis-admin
Copy link
Author

Yes, choosing discoverable or non-discoverable credential is a must.

Also, UV must be mandatory for discoverable credentials. We don't want totally passwordless+usernameless logins without even a PIN (or other UV), this would be a disaster.

Or there could be an option to disable UV with big red 'I understand the risks' warning (ideally, this should be controlled by admins depending on organization policies).

this is as follows:

if ($requireDiscoverable) {
$authenticatorSelectionCriteria = new AuthenticatorSelectionCriteria(
AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_NO_PREFERENCE,
AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_REQUIRED,
AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_REQUIRED,
);
} else {
$authenticatorSelectionCriteria = new AuthenticatorSelectionCriteria(
AuthenticatorSelectionCriteria::AUTHENTICATOR_ATTACHMENT_NO_PREFERENCE,
AuthenticatorSelectionCriteria::USER_VERIFICATION_REQUIREMENT_PREFERRED,
AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_NO_PREFERENCE,
false,
);
}

@swissbit-eis-admin
Copy link
Author

May I suggest to consider #57154 as an imrovement?
And as refernce PR to master: #57151 .

@tushev
Copy link

tushev commented Dec 18, 2025

Shouldn't it be AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_DISCOURAGED for non-discoverable option to be more robust?

@swissbit-eis-admin
Copy link
Author

AuthenticatorSelectionCriteria::RESIDENT_KEY_REQUIREMENT_NO_PREFERENCE

good and valid point in my opinion. Having a user option for RESIDENT_KEY_REQUIREMENT_REQUIRED, RESIDENT_KEY_REQUIREMENT_DISCOURAGED more likely forms the real opposite.

@MrRinkana
Copy link

This work is greatly appreciated! Thank you!

I will test when I have the time! In the meantime, am I understanding this correctly?:

  • If UV is used, the login is considered as passing 2fa and other configured 2fa is skipped.
  • If UV is not used, other 2fa is not skipped.

@tushev
Copy link

tushev commented Dec 19, 2025

In my opinion, the correct thing to do would be to treat all WebAuthn credentials as a form of :

  • either passwordless login (for non-discoverable credentials)
  • or passwordless+usernameless login (for discoverable credentials = passkeys).

At least, this is how it's implemented right now: existing non-discoverable credentials are form of passwordless login (and the corresponding header in Account > Security literally says that).

WebAuthn credentials are generally regarded as secure and thus do not require 2FA. 2FA is usually required for passwords only, in order to compensate for some of their weaknesses (passwords can be stolen/leaked, reused/sprayed, bruteforced etc, unlike WebAuthn credentials).

UV is a whole different dimension. It's goal is to protect WebAuthn credential on user's side from unauthorized use. Imagine if someone finds a Yubikey in the street with [email protected] passkey. So, we definitely want UV for usernameless+passwordless logins = discoverable credentials. As for just passwordless logins where you still have to type your username, UV can be optional (but it's still better to request it).

Type Form Proposed use for Nextcloud login UV 2FA
Password Login with username + password + 2FA N/A TOTP, WebAuthn etc
WebAuthn Discoverable Usernameless + passwordless login Mandatory Not required
WebAuthn Non-discoverable Passwordless login Preferred Not required

Note another use case for WebAuthn: on many websites, it's used as a better alternative to TOTP codes. In this case, UV is indeed optional, or even often discouraged, because the user already has to provide a password. By the way, this is exactly how it's implemented with Two-Factor WebAuthn app.

A good UX example would be GitHub itself: https://github.com/settings/security We have:

  • Sign in methods (email, password, passkeys, 'Social login' = 3rd party services)
  • 2FA (TOTP, SMS, 'Security keys' = WebAuthn, mobile app)
  • Recovery options

Their docs are actually very good and worth reading: https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys


So, I'd envision the UI in Account > Security as follows (new text in italic):

Passwordless Authentication

Set up your account for passwordless authentication following the FIDO2 standard.
This type of login satisfy both password and 2FA requirements, so you can complete your sign in with a single step, safely and easily, without requiring a password and two-factor authentication.

These credentials can be stored on hardware keys, or managed by your OS, or in some password managers.
You can also choose not to ask for username.

The following WebAuthn credentials are configured for your account:

Name Date Added Use
Yubikey 5 19 Dec 2025 Passwordless login (username required) [ Rename ] [ Delete ]
Windows Hello on ABCD12 19 Dec 2025 Usernameless login [ Rename ] [ Delete ]

Register new WebAuthn credential:

  • Do not ask for username when logging in

[ Register credential ] [ ... ]


As for my proposal for an option to disable UV for passwordless logins (not usernameless+passwordless!), it could be hidden inside that [ ... ] button.

@swissbit-eis-admin
Copy link
Author

Not sure how the interest is at all here. I would like to make it really simple...
Again, I do recommend to consider #57154 for further discussions regarding stable32.
The concept is improved there. I tend to close this one here.

@swissbit-eis-admin
Copy link
Author

I do recommend to consider #57154 for further discussions regarding stable32.
Let's continue there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3. to review Waiting for reviews enhancement

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants