I honestly don't understand why this needs to be a service. Isn't it trivial to implement with an SMS API like Twilio? I could probably implement a random number generator -> SMS push -> store in my DB faster than I could read the docs of a 3rd party service like Cotter.
So what we provide is not an SMS OTP login. SMS OTP is insecure, that's why we recommend apps not to use SMS OTP as a way to authenticate users. The SMS OTP is only used as a way to verify that the phone number is actually active.
The main idea is that we are making phone number login more secure by using Trusted Devices to login instead of SMS OTP. Using trusted devices, users can only login from their trusted device, and would need approval to login from another device. Our goal is to make it easy and fast for developers to make a secure authentication flow using phone numbers by just using our SDK.
Also, Twilio might be pretty simple to use in the US, but the pricing for other countries doesn't make sense. So we also help by integrating with local sms providers.
To add a trusted device, the new device will generate a QR Code, which then have to be scanned by a trusted device. So all logins and adding new trusted devices will still have to be approved by a trusted device. (Similar to how you login to WhatsApp desktop/web, you scan the QR code from your phone)
So what happens if you lose a trusted device? Or maybe it crashes, or the user signed-in with incognito originally, or anything like that? What's the recovery mechanism?
When you lose your only trusted device, then you would have to go through recovery methods, which is set by the website/app depending on what level of security they require.
For apps that prefer lower security, higher convenience, then possibly users can fall back to SMS OTP.
For apps that require higher security, the app can revoke the lost device and either delete the account, or go through customer support to verify the user's identity and enroll a new device.
If you have 2 trusted devices and lost one, you can revoke access from the lost device.
Incognito shouldn't affect this because the trusted device works in mobile apps, not websites.
but haven't you said that the trust is cross app? Doesn't that mean I could make my own app with bare minimum security requirements and then use it to make a new trusted device using fallback SMS OTP (which you agree is insecure) and then hey-presto I'm trusted cross app?
Oh, yeah, sorry I wasn't clear on this. If App A allows fallback SMS OTP and App B doesn't allow fallback SMS OTP, then you will never be able to login to App B with just having your phone number verified.
Our product have 3 features:
- Cross-app phone number verification. The phone number is used only to check if the phone number is active. This is never used for authentication or logging in, and don't have anything to do with the Trusted Device. (For example, sometimes you would register to a website with email and password, and then somewhere in the flow they ask you to verify your email. This email verification has nothing to do with your password)
- Trusted Devices for authentication. The trusted devices are done using cryptographic keys that are generated upon registration. This keys are unique per app, per account, per device. No Cross-App trust here, we don't want any app to be reliant on any other app on authentication.
- Pin/Biometric as additional features.
So the cross-app is only for verifying the phone number. The trusted device is not shared across apps.
