[DISCUSSION] New User Login Methods about appwrite

[PineappleIOnic]

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

[saibotma]

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

[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.

[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.

[templatedop]

SMS OTP login will be the best one.

[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/

[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.

[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!

[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!

[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.