How is everyone managing user authentication for their platform? | Hacker News Reader

How is everyone managing user authentication for their platform?

8 pointsaisha_mc19 comments

I am thinking of using only SMS based authentication for my SaaS. Any suggestions?

It really depends on who the service is being sold to.

Business - SSO via Oauth2, with Azure AD as a ready to use integration

Developers - SSO via Oauth2, with prepared integrations for Github, Gitlab, Keycloak, Okta, or Google.

Personal banking or services where a tie to your real identity is an absolute must - SSO through your national id provider.

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.

Consumers - SSO via Oauth2 with Azure AD B2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c...)

Azure AD/Entra ID I don’t mind. It’s crufty, but seems to work reliably. But the Microsoft B2C solution is far less supported and configurable than most of the competitors in the space. It doesn’t seem to get nearly as much attention from Microsoft and the dev experience for it shows. I’ve found solutions like Auth0 to be far superior.

Currently we use passport.js (https://www.passportjs.org/) 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 (https://github.com/ssoready/ssoready), among others.

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: https://stytch.com/blog/totp-vs-sms.

As a suggestion for what to implement (I'm biased because I work there) but I'd encourage you to check out Stytch (https://stytch.com). 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.

Exact same here, Google auth in a chrome extension

Definitely NOT with SMS.

https://www.okta.com/blog/2020/10/sms-authentication/

"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.

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.

email-based auth is much preferable in my opinion.

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.

I stick to Django User + custom secret link via email for my pet project. No need to remember any password or 3rd party auth flow.

We use authentication provided by Laravel Passport. Has been working great for us.

Just enter a username and I’ll give you full access

Depends what you need.

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?

LOL.

No device fingerprinting via JS or any 3rd party as I believe in users' liberty.

So, how the user gets the above JWT:

Is any authentication needed?

Is they want to opt in, how's a trip code?

An account name recoverable via email. Or secret. Or SMS. Or remembering last account action? Or a combination?

For a sensitive action, what's the tradeoff between verification and convenience? Against what sort of actor?

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.

scrypt, totp

My firm doesn’t offer SMS to clients unless they explicitly ask for it now.

node.js - oidc-provider library with passport.js.

SAP

Reply on news.ycombinator.com