Registration, authentication, and why sms? (Discussion)

[bengtan]

This is a spin-off from https://github.com/hippware/wocky/issues/800 (hence I've posted on the same board). Apologies for taking longer than expected for this to appear.

The trigger for this discussion is 'why sms?' but we're going to open up the discussion. Maybe we might find something better or more suitable.

Firstly, here are the requirements we'd like for our registration and authentication schemes. I've split them into two because I think it will clarify our thinking.

Registration

• Solution should be very mobile friendly.
• Should be very easy to understand and use for TR user.
• Discourages anonymous or multiple accounts
  • In the belief that this would reduce trolling or misbehaviour.
• Should be a low costs solution.
• Solution should scale for the long term.
• Cross-platform
• Moderately easy for staff to bypass so we can test onboarding flow
• Flexible [1]

Authentication

• Solution should be very mobile friendly.
• Needs to be more secure than passwords
• Should be very easy to understand and use for TR user.
• Should be a low costs solution.
• Solution should scale for the long term.
• Cross-platform
• Moderately easy for staff to have multiple accounts and pass accounts around
• Flexible [1]

[1] so we can mould it to fit our (present or future) onboarding flow.

So, let's have a discussion. Let's challenge the notion that we have to use sms for registration/authentication. Let's challenge openID. Let's see what else we uncover.

---

(Also, Twitter Digits expires September 30th ... which isn't far away.)

[bengtan]

I'm going to throw some things out there in order to start the discussion off.

---

From the previous ticket, some people mentioned openID and I posted a response:

https://github.com/hippware/wocky/issues/800#issuecomment-310561178

---

I would also mention:

I think we should have username/password authentication ... Maybe not as the main scheme but as a fallback. That would make it straightforward for staff to log into each other's accounts and debug issues.

For authentication, instead of sending 6 digit codes to a phone number, we can send 6 digit codes to a user's email address. Appear.in does the same thing (the last time I looked).

---

cc @thescurry, @zavreb, @aksonov, @southerneer, @bernardd, @toland

[toland]

Pulling in the discussion of SMS vs. OpenID from #800:

@thescurry wants to use SMS for a number of reasons:

• It's a better user experience than using passwords. (So while we may implement passwords in the future, passwords would be an alternative login mechanism rather than the main mechanism). Also, Steve doesn't like passwords.

Agree 100%

• We believe that tying an account to a phone number is likely to discourage trolling or unsocial behaviour.

Seems reasonable.

We're not considering OpenID (ie. Google/Facebook/Twitter/etc) for now because:

• We want to own our userbase instead of being dependent on other providers ie. we don't want to be 'locked in' into Google/Facebook/etc.
• OpenID allows people to create multiple/anonymous accounts ie. facilitates trolling or unsociable behaviour.
• OpenID can suffer from the problem of people forgetting which provider they used to log in ie. a person registers with Google and then tries to login with Facebook.

These are all good points and I would agree that we wouldn't want to use OpenID with a third-party provider. I was thinking about running our own OpenID provider. That would allow us to use whatever authentication workflow suites us while at the same time having a secure and thoroughly reviewed protocol.

---

As for security ... It's probably okay for now.

I don't necessarily disagree. However, I think we can use push notifications instead of SMS to get the same workflow without the problem of a potential MitM attack.

---

I think we should have username/password authentication ... Maybe not as the main scheme but as a fallback.

Agreed. We currently use password auth for the integration tests. I don't think that functionality will go away; we just have to discuss how/when we want to expose it via the client.

[bengtan]

Quoting @toland:

I was thinking about running our own OpenID provider.

I don't understand how this would help. To me, it seems like just shifting the problem around.

To operate our own OpenID provider, wouldn't we run into the issue of ... how do we register and authenticate our users? It's the same issue again, no?

use push notifications instead of SMS

And I don't see how this would work either.

[bengtan]

I'm surprised there isn't more discussion here.

Alright, I'm going to put in a speculative suggestion. This probably won't be the final form as I expect it to change depending on others' feedbacks.

1. Only use sms during registration. The sole purpose is to verify the user's phone number (ie. as part of onboarding).
2. Don't use sms for authentication. Instead, we use password authentication, or we send a six-digit temporary code to their email address (or both).

Notable characteristics of this scheme:

• A phone number is needed to create an account. This still discourages anonymous or multiple accounts.
• Saves on sms costs. SMS is only sent once per user (ideally).
• Once the account is created, user does not use sms to log in.
• Six-digit-code-to-email is user-friendly-er than passwords.
• Somewhat more secure (ie. less chance of interception) since we aren't using SMS for authentication.

What do others think?

[aksonov]

I don't agree about hybrid sms/email login. I still think that SMS login is much easier than email - you don't need to remember what email you registered, check your email with separate app (gmail or mail or browser). It even could allow us to make email optional (I don't understand why we made it required).

Anyway, we have only 40 days left and we must decide what to use ASAP. I'm not big specialist in auth, but I'm sure that creating it from scratch will take a lot of time to design/develop and test - both server and client - and we cannot risk.

Firebase provides good base for auth and allows various types - email/sms/openid/etc and allows to do it faster than from scratch-solution (even if we will not go with sms).

However even Firebase requires a lot of time to integrate because React Native implementation for Phone auth is not ready yet: https://github.com/invertase/react-native-firebase/issues/119

[thescurry]

@aksonov how about auth0 as a solution? It would appear they have more react-native ready libraries: https://github.com/auth0/react-native-auth0

[bengtan]

I don't agree about hybrid sms/email login. I still think that SMS login is much easier than email

Fair enough. The main advantage of Six-digit-code-to-email over Six-digit-code-to-sms is sms cost. Any other differences between the two are (I believe) debatable.

I'm not big specialist in auth

Six digit codes aren't anything special. Just generate a random one and get it to the user somehow.

Anyway, we have only 40 days left

If we're running short on time, that would tip the balance towards Firebase. At the least, we don't have to spend any time discussing/debating API design.

However, this:

Firebase requires a lot of time to integrate because React Native implementation for Phone auth is not ready yet

and the fact that our server side needs to be integrated [1] with Firebase's servers tips it away from Firebase.

[1] I presume that server-to-server integration is needed.

---

how about auth0

When I looked at auth0 in the past, I didn't see anything special in what they're offering. Maybe others can see what I'm not seeing.

[thescurry]

@bengtan, let's talk about this tonight during our call. I wanted to discuss some of my thoughts regarding Auth0 and why I think it's interesting (feature wise).

[toland]

I looked at Auth0, and it looked fine to me. I haven't looked at it or Firebase enough to make an informed judgment about which one is better. I can say that I can see why Steve would like Auth0; they are heavily targeting the business-side with metrics and insights.

I did a quick search and both Auth0 and Firebase have Elixir libraries. Both are community contributions, but we should be able to make them work on the server side.

[bernardd]

I had a bit of a poke around Auth0 this afternoon and it looks really nice. They look like they've done a lot of work to make stuff as easy to use as possible which is always a good thing. If I had to point to a down-side, it's that their marketing video is done by a guy pretending to be a "user" talking about how great he finds it but who is very clearly a marketing hack. But if I never used any products whose marketing rankled me, I'd be living in a cave trying to keep warm by rubbing sticks together.

[bengtan]

@aksonov had a look and wrote some comments at:

https://github.com/hippware/rn-chat/issues/1091#issuecomment-321846042

I'm cross-posting below

---

Initially their web site looks quite good. BUT... I tried some demos and examples, created company account, registered our app and so far I DON'T like auth0 for following reasons:

1. Not-native iOS experience, auth0 just popups web browser window (with visible URL headers). It doesn't look good (see screenshots below).
2. Too complex UI and business logic - I was asked to enter email and then I was asked to enter sms (I enabled sms before) - so there is no way to use SMS without email like Digits (?)
3. You cannot change your device after 'successful' login easily - you must to remember some code (?)
4. Finally I got 'oops... something goes wrong' after 'successful' login. I created github issue.
5. Lack of documentation for react-native-auth0, github is not active. Latest commit was 2 months ago. No good examples, found only one without description - https://github.com/auth0-samples/auth0-react-native-sample

Screenshots:

[bengtan]

Based on what @aksonov wrote about, it seems auth0 is too heavyweight, intrusive and inflexible. The constraints that Digits puts on us (and our user registration process) are bad enough. Auth0 seems worse.

I guess that leaves just Firebase on the table. (cc @thescurry)

[bengtan]

After out-of-band discussion, we're going with SMS registration and login using Firebase.