Passwordless login to existing accounts

[lekksi]

Hi!

The registration already supports creating an account without setting a password, that's great!

I'd like to operate completely without passwords, which isn't currently possible for users logging in to an existing account. Would you be open for a PR for adding support for completely passwordless authentication support?

I was thinking of adding a SendLoginEmailMutation for sending the login token and then support authenticating against it in the ObtainJSONWebTokenMixin.

[nrbnlulu]

Hi!
So your users would have to issue a token from email every now and then?

[lekksi]

Hello, I was thinking something like this 👇🏽. What do you think?

Auth specs

Users can register without a password ✅
Returning users can login with a token delivered via email 🆕
Refresh token is used for getting fresh authentication tokens ✅
After the refresh token expires, user is required to login again using an email token.

How I think this could be implemented

Settings

ALLOW_PASSWORDLESS_REGISTRATION: bool ✅
ALLOW_PASSWORDLESS_LOGIN: bool 🆕
JWT_LONG_RUNNING_REFRESH_TOKEN: bool ✅

Mutations

The VerifyAccount mutation should support returning tokens. This would be the preferred way of obtaining tokens when ALLOW_LOGIN_NOT_VERIFIED=False. Otherwise, tokens could already be returned from the Register mutation.

The ObtainJSONWebTokenInput should be modified to make the password field as optional and add a token field for passing the login token when ALLOW_PASSWORDLESS_LOGIN=True.

The documentation for RegisterMixin says If allowed to not verified users login, return token., but if I'm not mistaken, it never returns the tokens. I could add support for this as well or should the documentation be updated.

Alternative

The same could be implemented i.e. with a custom authentication backend which would accept the email token as password and add one custom mutation for sending the email with the token.

However, I was wondering whether it would make sense to have the support in the lib itself?

[nrbnlulu]

Thanks for the clarification.
Totally implementable though it seems would require ugly patches...
Since I plan to do major refactoring for issues #264 #250 and also I might generalize this lib soon (use
many database/orm backends (I intend to migrate to EdgeDB)). So ATM I won't work on this but further on it would
be much easier to support these kind of features without so many settings...

Having said that a contribution would be accepted.

However, I was wondering whether it would make sense to have the support in the lib itself?

Probably 😄

[lekksi]

Ok, thanks!

I took a closer look at the code and agree that supporting this pattern with the current implementation would not be too pretty. I'll implement this with the alternative approach for now.