[DISCUSSION] New User Login Methods

[eldadfux]

We are starting to think about new login methods that will be available for future releases.
We would love to get the community feedback regarding new ideas for user signups:

These are some of the ideas we have, and we would like to get more.

• OTP / Email code
• Magic URL
• Phone
• OpenID
• Anonymous login (DONE)
• 2FA (should work only with email/password or with any method?)
• Hardware U2F keys
• WebAuthn API
• Existing OAuth Access token (IN PROGRESS)
• Google Authenticator / Other alternative

If you have reference for implementations in other projects or apps that will be great, also any technical docs could be awesome as well.

[sagarvd01]

My suggestions on this are

• Email OTP login alone isn't much safe (without a password). 2FA should be enforced in this case.
• SMS based login doesn't require 2FA.
• Anonymous login is a good idea but certain checks should be implemented to prevent abuse.

[eldadfux]

@sagarvd01 thanks for your feedback.

Why in your opinion OTP alone isn't safe enough?

About the Anonymous login, we already have abuse mechanism in place the work on all login methods to protect from brute-force attacks.

[christyjacob4]

@eldadfux There are also situations where a user may want to receive a call get the OTP instead of an SMS. Twilio seems to be the most popular option to handle SMS, Calls and Emails
https://www.twilio.com/

[eldadfux]

@christyjacob4 thats sound like a good idea but we don’t want to be biased towards a commercial company like @twillio (which I love, but that doesn’t matter), or make the setup more complex.

I guess that we should allow different adapters to allow the enabling of this kind of features as there are no notable open-source solutions that I am aware of either for calls or SMS.

How do you see the workflow of enabling SMS / Call services as part of the authentication service? Is it part of the settings? A new settings page just for auth? Love to get your feedback

Anyway I think it important that we put a lot of emphasis on making sure we stay un-opinionated where we can’t use open-source solutions and easy to get started or setup even when such a 3rd party integration possible, meaning it shouldn’t be a requirement to setup.

[sagarvd01]

Hi @eldadfux , in my opinion, email ownership may be changed over time. Especially when users login with business emails. So we can't distinguish whether it's the same person or not.

Additionally, Firebase by Google provides a good sdk for authentication purpose, which will reduce a lot of work.

[eldadfux]

@sagarvd01 I definitely agree that email ownership may change over time. This is something we need to think of when relying on email as the main recovery process and identification of the user's accounts.

I don't think the usage of business email should be a major concern for us, as this can actually be treated as an advantage for people wanting to have different accounts for personal or company usage.

Regarding Firebase, we are building an open-source and self-hosted product. Meaning, people can use it for free, set it up everywhere they want and control their data. Relying on a commercial, paid, SAAS product as an internal dependency will go against all these goals.

[monatis]

Hi @eldadfux you might want to have a look at Jasmin SMS gateway to implement SMS login and varification. It is open source and can be readily containerized with Docker, and it supports both http and smpp protocols.

[eldadfux]

@monatis wow this seems like a really cool project and it's awesome they have a docker container! checking it out now.. thank you!

[Shiba-Kar]

Ya its a cool project @monatis

[m7md10]

Glad I found this amazing project , one thing that keeps me away to switch from Firebase is Phone number auth , any update about SMS login method?

thanks!

[eldadfux]

@m7md10 this is something we definitely want to add, but no timelines yet.

[drandell]

A create session & return access token would be very useful login alternative.

[PineappleIOnic]

Hardware U2F keys would be a nice addition for those who require alot of security on appwrite

[eldadfux]

@PineappleIOnic cool idea!

[PineappleIOnic]

We could use the WebAuthn API for the client-side prospect which has wide compatability with firefox, chrome, edge and safari.

[eldadfux]

As mentioned in #354 another useful method we can add here is to login with existing OAuth access tokens (today we are creating them ourselves). This will be specially beneficial when integrating with native OAuth SDKs for better UX.

[saibotma]

Anonymous login or login by username without an email would be great as some projects don't have unique emails for their users.

[templatedop]

SMS OTP login will be the best one.

[eldadfux]

Updates 28-02-2021

• Anonymous login is almost ready for release, probably on Appwrite 0.8
• work has been done to create a new endpoint for existing OAuth2 access tokens. More on that soon.
• We are working on adding more ways to control which auth methods are enabled (view screenshot)
• We are working on a way to limit the max number of users allowed per project (view screenshot)

[ameerfayiz]

when will be the phone authentication available?? @eldadfux

[Shiba-Kar]

Phone auth should be in higher priority !!!.

[gat786]

How about using Authenticator apps like Google Authenticator. Can we make Appwrite to create such authentication mechanisms?

[eldadfux]

How about using Authenticator apps like Google Authenticator. Can we make Appwrite to create such authentication mechanisms?

Added it to the list :)

[manutheblacker]

Is the authentication by phone number still viable ?

[eldadfux]

It was just released in the latest Appwrite version!
https://dev.to/appwrite/announcing-appwrite-015-with-phone-authentication-more-5cjj

[eldadfux]

Update 14-07-2022 - we now support both Magic URL and Phone Authentication :)

[saibotma]

I noticed that email is still required to create a user (https://appwrite.io/docs/server/users?sdk=nodejs-default#usersCreate).
This does not work for applications where multiple users share the same email address.
What we do at the moment, is, we create dummy email addresses like username@dummy.appwrite and add the @dummy.appwrite suffix on the client side when logging in. This way, the user thinks that he is using a username to log in and does not notice that he is actually logging in with an email.

A more beautiful solution would be if appwrite did support username authentication natively. Are there any plans on supporting this?

[keul]

Unsure if in the list above the reference to OpenID stands for OpenID connect, which in case means: automatically be compatible with well-known tools lie Keycloak and WSO2

[zdanl]

i would start working on 2FA with an app (like Google Authenticator), if someone can advise on integration on the side, maybe.

should work with user/password and magic link for starters, i propose.

[hortigado]

Existing OAuth Access token (IN PROGRESS)
Hello, how come with this functionality, as it is very necessary to have Google Sign in native for the comfort of the end user.

[gaganyadav80]

OAuth using access token.
This issues was mentioned in 2020. And it's 2024 now. That's all I'm going to say.

[hortigado]

Sad but true