It really depends on who the service is being sold to.<p>Business - SSO via Oauth2, with Azure AD as a ready to use integration<p>Developers - SSO via Oauth2, with prepared integrations for Github, Gitlab, Keycloak, Okta, or Google.<p>Personal banking or services where a tie to your real identity is an absolute must - SSO through your national id provider.<p>Personal sites with less stringent security - SSO with Google or Apple. Here you may also roll your own identity with user+pass+2fa. I guess this is the category you are interested in based on your suggestion. This is also the category with most variety in the field, for example some sites allow email login and recently passcodes are getting popular here.
Currently we use passport.js (<a href="https://www.passportjs.org/" rel="nofollow">https://www.passportjs.org/</a>) and it gives all basic authentication - SSO, email etc. we found OKTA expensive, have used it before.
I'd highly discourage you from using SMS; it's very insecure. I'd go as far as to recommend you not to implement your own auth and instead use something like Auth0, WorkOS, SuperToken, or SSOReady (<a href="https://github.com/ssoready/ssoready">https://github.com/ssoready/ssoready</a>), among others.<p>Building auth stacks is not trivial and is not what will make your SaaS successful. The more you can leverage experts to focus on what makes your SaaS special, the better.
Regarding SMS only auth, you should be cautious. Here's a blog with more detail: <a href="https://stytch.com/blog/totp-vs-sms" rel="nofollow">https://stytch.com/blog/totp-vs-sms</a>.<p>As a suggestion for what to implement (I'm biased because I work there) but I'd encourage you to check out Stytch (<a href="https://stytch.com" rel="nofollow">https://stytch.com</a>). We're an API-first authentication, authorization and fraud prevention B2C and B2B solution with several methods including email/password, email magic links, social logins and 2FA (OTP, TOTP).
I'm using Firebase Auth for my side project. Pretty easy to get started and has generous free limits. I went with Google Auth and passwordless email links. SMS auth would start getting expensive very quick, especially with international users.
Definitely NOT with SMS.<p><a href="https://www.okta.com/blog/2020/10/sms-authentication/" rel="nofollow">https://www.okta.com/blog/2020/10/sms-authentication/</a>
"it really depends!!" on the level of security required for the data/actions that seat behind the authentication - for e.g. for Banking and Financial services - a 2factor auth is a must.<p>For average usage, mobile based auth is ok - although in that case you are relying on the security infrastructure of telecom operator, which in many country is not that good - e.g. identity theft to hijack someone mobile number is quite common.
Don't do anything unusual like SMS. It becomes a friction point where you'll lose people. Email/password, Google auth, and maybe another social depending on your product space is what people are used to.
Depends what you need.<p>From just the headline I thought the question was slightly different however: JWT with requires time, UA, IP and some decay of variance of these customisable via an integer value from 0 to 100. Let the user choose?<p>LOL.<p>No device fingerprinting via JS or any 3rd party as I believe in users' liberty.<p>So, how the user gets the above JWT:<p>Is any authentication needed?<p>Is they want to opt in, how's a trip code?<p>An account name recoverable via email. Or secret. Or SMS. Or remembering last account action? Or a combination?<p>For a sensitive action, what's the tradeoff between verification and convenience? Against what sort of actor?<p>SMS is exclusionary. Which works if you want to exclude non US/EU phone dependent users and target those that care little about security or privacy.