Passkey login issue when email authentication is the only other login method

[janko]

When I was preparing a simple app to show people on Twitter how easy it is to set up passwordless registration with Rodauth where passkey & password can be added later, I ran into an edge case where the user cannot fully login.

Initially, I enabled the webauthn_login feature, but forgot to set webauthn_login_user_verification_additional_factor? true as well. When the user didn't have a password set but they added a passkey, and email authentication was enabled, logging in via passkey authenticated 1st factor, and when Rodauth requested 2nd factor (e.g. when using change_password to set a password for the first time), it redirected to the 2FA page, but there weren't any 2FA methods left to authenticate with, so the page was empty.

Here is the full Rodauth configuration I used:

enable :create_account, :verify_account_grace_period, :login, :logout,
  :change_password, :email_auth, :webauthn_login

create_account_set_password? false
verify_account_set_password? false
webauthn_login_user_verification_additional_factor? true

The user could run into this edge case even when webauthn_login_user_verification_additional_factor? is set to true, in case they use a passkey device that doesn't perform any form of user verification (e.g. a YubiKey?), so passkey login still authenticates only 1st factor.

[janko]

My initial thought was whether email_auth feature could also be used as 2nd factor in this case, just like password can be used. That could then be an alternative to email codes that are sometimes used as 2nd factor.

I don't know how difficult that would be to support, because for password that required a separate confirm_password feature.

[jeremyevans]

Thanks for the report. Adding support for emailed codes as 2FA is possible, and could be useful more generally, not just in passwordless environments. Email codes seems more common than magic links in my experience. I personally prefer magic links as they are more secure, but email codes are definitely more friendly if the device you receive email on is not the same device used for browsing.

Alternatively, if no password has been set (or no 2FA options are available), require_authentication could succeed with only 1 factor? I don't like that as default behavior, but maybe an option/feature for it?

[janko]

I would definitely like to see an email_codes feature added at some point, though I was imagining it only as a 2FA method (like TOTP), not as a replacement for email_auth. However, I haven't considered the use case where the email is viewed on a separate device.

I'm just wondering if it's possible to somehow address interaction between passkey login and email authentication, so that Rodauth requests 2nd factor only when one can be provided. In my case, it's possible to authenticate with email authentication as 1st factor, then passkey as 2nd factor, but not nice-versa.

But that's probably not a common scenario. The app could technically also disallow passkey login if email_auth is the only other available authentication method for the user. This state of being redirected to a blank 2FA page just surprised me as a developer 😅

[jeremyevans]

I agree the current solution is suboptimal. If there is no way to 2FA after login, then in some sense, it may make sense to treat the session as fully authenticated even if only one factor was given, and an alternative authentication flow would allow for 2FA.

I was also thinking email_codes would be 2FA only, but it could work after either webauthn or password login (but not after email_auth login).

[jeremyevans]

I agree the current solution is suboptimal. If there is no way to 2FA after login, then in some sense, it may make sense to treat the session as fully authenticated even if only one factor was given, and an alternative authentication flow would allow for 2FA.

The issue with this approach is it would allow for only 1FA when the only 2FA authentication is locked out, which is definitely undesirable. If we want to support this, it has to be off by default.