Passwordless SMS code authentication

[splaunov]

Is your feature request related to a problem? Please describe.

Mobile applications developers often choose to authenticate their users by sending unique SMS codes. This type of flow is not implemented in Kratos yet.

Describe the solution you'd like

Implement new "SMS" login strategy. This strategy will require two login flow submissions from a mobile app:

• the first one is to send a phone number to the server
• and the second - to send the received SMS code for validation

Describe alternatives you've considered

None

Additional context

We are interested to implement this login strategy in the July-August timeframe. Please give your feedback on how will it fit into the overall architecture and roadmap and whether it would be accepted as a PR.

[aeneasr]

Hello, that would be a great contribution! I think twilio would probably be a good integration to start with?

[splaunov]

Yes, we use twilio. Although not directly but through our internal notifications service. I think we can abstract this call with the configuration parameters so it will be possible to call twilio directly as well.

I have started to implement this strategy. Will get back with the PR soon.

[aeneasr]

Nice! To ensure that we get through code review faster (and save you same work), would you mind sharing a high level architecture of what you're implementing first? :)

[splaunov]

I'm adding a new login strategy to selfservice/strategy/sms.
Here is the expected sequence of events:

• mobile app calls new flow create endpoint
• then it calls the flow submit endpoint with phone number in payload
• then I generate a random code and call twilio to send it to the phone number provided. The code and phone number are persisted in the Kratod db
• user receives the code on the mobile and enters it into the app
• the flow submit endpoint gets called a second time but now with the code
• I verify the code against the db and return the identity if code is valid

This is the core happy path. I also plan to add checks for the number of failed attempts and for the code expiration.

[aeneasr]

That sounds good! Would that flow also have verification / recovery capabilities? Or do you want to focus on login/registration first?

[splaunov]

Verification is part of this login method, as you need to present the SMS code to log in.
As to recovery - I will look into this after I implement the login. Probably we will also need to do something with a phone number change operation.

[aeneasr]

Yeah absolutely. So how would registration look like? Would SMS registration only work if we have the session issuer enabled for the post-registration hook? I assume we would use the registration flow then also to mark the phone number as verified?

[splaunov]

Why do we need registration flow at all? The beauty of the SMS method is the ultimate simplicity for the user. Just enter your phone number and then the code and you're done - registered and logged in.

[aeneasr]

What's the user's first name? Last name, birthdate, ... How do you know if she/he accepted the terms of service? And so on.

Provisioning users as part of the login will not work with Ory Kratos' internal architecture right now and I don't think it will work well for most people

[zepatrik]

To really be safe and implement proper recovery you probably need another factor next to SMS. WhatsApp has a six digit code that you can reset via email as an optional additional factor:
https://lifehacker.com/use-2fa-to-stop-this-new-whatsapp-account-attack-1845765591
https://faq.whatsapp.com/general/verification/about-two-step-verification/?lang=en
Just FYI for the next steps.

[splaunov]

What's the user's first name? Last name, birthdate, ... How do you know if she/he accepted the terms of service? And so on.

Provisioning users as part of the login will not work with Ory Kratos' internal architecture right now and I don't think it will work well for most people

It's an important use case for us. Can we implement this as a configurable option?
I would call IdentityManager().Create() from the login flow if the option is active. How could this compromise the current architecture?

[splaunov]

To really be safe and implement proper recovery you probably need another factor next to SMS. WhatsApp has a six digit code that you can reset via email as an optional additional factor:
https://lifehacker.com/use-2fa-to-stop-this-new-whatsapp-account-attack-1845765591
https://faq.whatsapp.com/general/verification/about-two-step-verification/?lang=en
Just FYI for the next steps.

@zepatrik thank you for the hint. I will look into this later when the main login flow starts to work.

[aeneasr]

It's an important use case for us. Can we implement this as a configurable option?
I would call IdentityManager().Create() from the login flow if the option is active. How could this compromise the current architecture?

Sorry but that will not work and will not be accepted as a PR. Login and registration are two functionally separate things. Mixing them is not a good idea. I am sure there are ways to achieve what you want without crushing this together. Ory Kratos supports, for example, login after registration which is what you probably need here.

[splaunov]

Yes, we could just use registration flow instead of login. But doing so we need to change this code:

kratos/selfservice/flow/registration/hook.go

Line 121 in 60d848d

if errors.Is(err, sqlcon.ErrUniqueViolation) {

To make registration logic lookup for existing identity before trying to create the new one.
Would it be a better solution than auto-provisioning from login flow?

[aeneasr]

You would probably end up needing this PR: #1420

[rferons]

Hey what is the current status of this issue? Having SMS as an option not only for passwordless login but for 2fa/mfa would be a really nice option to have.

[splaunov]

You would probably end up needing this PR: #1420

The idea (to always use registration flow instead of login) has its own drawbacks. This would work fine only if we have used passwordless methods only. Let's say, SMS and oidc, but not username/password. If there is a need to mix password methods with passwordless, it's not acceptable. We absolutely need a separate registration flow for the password method.

As the registration and login flows are already mixed for oidc, can we extend this practice to all passwordless methods?

[mohdalali]

Any updates on this issue? SMS is one of the main requirements for most of my projects.

[arjprd]

Hi @aeneasr ,
I have been trying to implement the OTP mechanism and have successfully implemented the login part of it.
Had a query why are we storing UI components in DB. Please let me know if is it necessary to handle the UI components else i'll implement the verification and recovery flow soon.

[ysaakpr]

Hi @aeneasr , I have been trying to implement the OTP mechanism and have successfully implemented the login part of it. Had a query why are we storing UI components in DB. Please let me know if is it necessary to handle the UI components else i'll implement the verification and recovery flow soon.

Can you add myself to collaborate on your PR...I can also contribute on this feature.

[kmkumar07]

Any updates on this issue?

[ysaakpr]

I have moved to supertokens https://supertokens.com/

One thing good about is that, you have lots of flexibility to fine tune the operations, not just the UI - May be against the ory philosophy, but will help you while you boot strapping

You can even login with whatsapp, or use otp with email or slack or you can send where ever you want it. its really convinient

[jeremy-serenne]

As #3682 has been merged, I think we can close this issue right ?

[edubacco]

As #3682 has been merged, I think we can close this issue right ?

#3682 is about a different feature: sending SMS to provide MFA.

The point within this issue is using SMS as passwordless auth