That is quite the rollercoaster of chained issues and PRs. (We need to reopen the issue for backup codes so thanks for digging through that)

I just want to clarify a bit, you are looking for the ability to login using a link/code that is sent to your email that would count as a single factor or did you mean something else?

I'm interested to hear what @james-d-elliott has to say on the topic of allowing email OTP to count as a single factor (or more). Although I suspect I already know his views on the matter; email is not sufficiently secure to count as a single factor by itself.

Something you know, something you have, or something you are. Email is none of those things. You have an account on someone else's server (google, apple, proton etc.), allowing anyone with access to your mailbox the ability to login using that mailbox. Email is generally seen as half a factor, and as such its not used for anything more than verifying identity on top of existing methods (via Elevated Session).
This could also be tangentially tied to allowing Authelia to act as an OIDC client and delegate auth to other providers such as github, gitlab, gmail etc which is also a planned feature, I suspect this isn't what your looking for.

I'm not against allowing administrators to make the conscious decision to allow users to use email to login (same with password expiry). We are planning to rework the way that we handle authentication to make better use of AMRs. This would allow administrators to define what each authentication method counts for (1fa, 2fa, etc.) and what users are or aren't allowed to use. This work was partially begun with the new passkey feature.

I apologize in advance, This response is quite lengthy. Hopefully my opinion and the length do not discourage you from expressing your ideas and being generally involved in the community.

I am generally not in favor of something like this, and unfortunately my opinion on this is very unlikely to waiver much but this isn't due to lack of consideration. I am open to changing my opinion, but effectively my opinion has grown more sure as time has passed. This idea has been formed though both anecdotal interactions with the kinds of people this is intended to affect and in measurable metrics from a large company.

There are two parts to how my opinion has formed.

Part 1

The reasoning presented in favor of this is users who are likely to use bad passwords, and by using a magic link or other such email it is good for security as it reduces phishing viability and MFA fatigue.

However the argument in my opinion is objectively flawed. An emailed magic link or OTP in an email is substantially easier to phish or exploit via fatigue.

The reason it's easier to phish in this case especially in a first factor scenario is that a malicious attacker is able to trigger the email being sent at an opportune time to ask the user to provide it to them. This information, when compared to a password, is far less likely to considered a security risk as it is not universally considered bad to share email content with strangers. Would a security savvy user catch deception here? Probably. But we're not talking about security savvy users. They are the ones likely to be fooled by a well crafted deception.

The reason it's easier to exploit via fatigue is directly linked to the idea of a magic link, it doesn't affect a single use code they have to manually enter or copy. The mere act of asking over and over again to authenticate could allow a person to accidentally click the link causing the authentication to go through.

Part 2

The direction of Authelia is changing slightly to better support emerging standards that make communication of authorization level easier and more universally understood. We're moving towards using AMR (RFC8176) as part of the Passkey changes.

This will allow accurate communication to third parties how much authentication stress the session has undergone.

Realistically there is not a current description of this, but it could be added for sure i.e. email. This would satisfy the "something you have" element, and a channel outside of the Authelia portal itself. This would only be sufficient for the one_factor, and the only possible factor to achieve mfa i.e. two_factor is a password at this stage.

To me this in conjunction with part 1 is a very compelling reason to suggest this should never be a passwordless option. Realistically the answer to passwordless logins is Passkeys, and the answer to users picking bad passwords is enforced MFA.

Specific Responses

An account with password-only login that can be reset by email cannot be more secure than an email-based login.

Well I happen to agree with you. That's why we not only allow disabling it (will require explicitly enabling it in v5) and offer a custom URL for password resets. We would also be interested in ideas that improve this in any way.

I see this originally came up in #2783 which was closed in favor of #2035. While #2035 was resolved through #3801 + #6332, the email-based login articulated in #2783 was not part of the final design/PRs. More recently this came up in #4619 (reply in thread).

I must admit, I did not particularly like this idea in general. I could never really pinpoint why. I had intended to reopen it but I evidently forgot. However as time has passed and some ideas you've shared my reason for disliking it has become quite clear.

I am not well versed in the security literature, but it seems to me that in a traditional password login scenario, the level of the security is the minimum between:
The strength of the password
The security of the email account (knowing the email address)

Precisely. This is an important factor to remember. The users you're talking about are the ones who will also have bad security hygiene with their emails. So the problem this tries to solve is just as bad as it was before, except any protection authelia has to prevent brute forcing passwords is completely null and void (regulation).

We're actively trying to devalue the power email access provides with options (see the require_second_factor option here) (and this is likely to be forced with no option to disable it in v5 especially once recovery codes are added). This unfortunately conflicts with that.

This comment actually helped cement my ideas somewhat. Realistically if email can be used as a second factor or first factor, the logical outcome is that the email is the only barrier between access and no access.

Here's a choice quote from it

The study seems very dated to me actually. It's from 2015 effectively before passkeys, but around the time of WebAuthn (in its early infancy). There is not a single mention of WebAuthn as a consideration (though it seems to hint towards FIDO1). It also talks about same passwords for differing websites and database leaks being an issue. But this is very very old and makes me seriously question the writers. Even in 2015 heavily salted and hashed passwords were a standard practice making a DB leak less problematic as the hash for the same password on two sites will not be the same even given the same algorithm and algorithm parameters.

The only arguments they present against FIDO itself the lack of a clear pathway to user adoption. Well I think this has been very well solved by browser and operating system manufacturers.

Ironically I feel like ZeroFactorAuthentication is a very apt name for this. The relying party (Authelia) has zero knowledge of how the user authenticated to their email, just that they might have. The relying party has to hope the email server is somewhat secure as well.

Alternatives

I don't want to let the underlying problem go unsolved. So I have some alternative ideas that may be a better direction.

I think reasonably there is a standard or two that effectively implements passwordless logins. The most widely supported one on multiple platforms natively (i.e. as part of the OS or browser) is WebAuthn Passkeys. There are many ways to interact with passkeys as well, such as with passkeys stored on phones you can interact with them over low energy bluetooth.

I think we can also reasonably include OpenID Connect 1.0 Relying Party support as an answer to this. This method heavily integrates with AMR (RFC8176) allowing us to determine how well authenticated the user is from the OpenID Connet 1.0 Provider and choose if we do or do not trust their assertion.

You could also leverage the free tier of Duo for this. This is probably easier than email if you ask me. A user just has to confirm authentication on their phone after using their bad (but hopefully long) passphrase. This may also be partially an answer to "how to get them to use good passwords". Ask them to use a passphrase instead, and teach them a way to remember it.

An other alternative that may be possible at some time is SQRL, Though I don't see large adoption for this and I think it's not as well known, probably making it difficult for the same users.