SMS sign up? about gothic

[jrapoport]

There's already support for an access code, and was thinking about that for this use case. Have to noodle on it a bit, but if there is work to do to support it, it should be relatively minor/straightforward.

[jrapoport]

I think it would depend on the specific flow -- at signup, after signup, or on each login. 2FA is something I've been thinking about.

[jrapoport]

Yes, I understand how it works. My point was that supporting 2FA more than likely involves entirely new flows that don't (currently) exist. So I've been thinking about the best way to implement, because I don't think we can just tweak what we have right now to do it.

[boosh]

OK I might have misunderstood but I thought the access code stuff was more like a prerequisite for signing up. That could work for some usecases, but ideally I'd like to let users sign up with email/password (since that's lower friction), but with only limited access until they verify their mobile number. My aim is to help cut down spam on an app by e.g. preventing unverified users from posting user-generated content.

[jrapoport]

Oh, you mean in addition to a normal email/pw signup you want to verify the account against a mobile number?

If so, there is/should be support for that. When a user first signs up (and autoconfirm is disabled) they are in a restricted state (not confirmed or verified) which is reflected in the JWT. Once they confirm their email, they are "confirmed", but not "verified". The verified state was put in to support additional user verification flow (e.g. home address, state issued ID, mobile #, etc.).

The idea was that you can drop a user through an orthogonal post-signup flow (keyed off the restricted jwt). Upon completion of that flow, you'd mark the account as verified (and refresh the jwt).

Everything should be in place to support it, but I will have a look to make sure the API to mark an account as verified is exposed (it's been a while since I have had a look at that part).

Does that make sense? Or am I still missing what you mean?

[jrapoport]

p.s. this was additional functionality I added (i.e. not supported in gotrue afaik) wiw I'm not positive off the top of my head.

[boosh]

Thanks that's great. I think that means I can support all the flows I want, ideally:

1. Social logins - give users full access
2. Mobile number - give users full access
3. Email/pw - give users partial access until they also verify with their mobile, then full access. In this flow even verifying their email address should be optional

So the mobile number could either be a primary signup method, or a verification method if they sign up with their email address. I'll dig into the docs and see what I can find. Thanks for your help.

[GwynethLlewelyn]

I'm just wondering if the same approach could be used to implement Two-Factor Authentication using TOTP, e.g. using the OTP library of @pquerna.

[GwynethLlewelyn]

I think it would depend on the specific flow -- at signup, after signup, or on each login. 2FA is something I've been thinking about.

Well, following common market practice, I'd say at/after signup, and on each login — unless the user allows a cookie to be stored on their browser for a certain period of time (say, 30 days) allowing logins to proceed on that browser without TOTP as 2FA...

Complicated enough? 😂