netlify-identity-widget VS gotrue

Leveraging the open-source GoTrue API, Netlify Identity can be added to your site with the Netlify Identity widget by adding this

In the first version of the website, I used Netlify Identity, which is Netlify's own authentication solution. With Netlify Identity Widget it is easy to add authentication, but I quickly discovered that I missed some more advanced functionality. I therefore switched to Auth0, which to a greater extent allowed me to tailor the login solution. Auth0 also had some functionality I needed to create a user admin dashboard, like role-based authentication.

However, it soon became apparent that Netlify Identity had some limitations. One was that the login alert was not in Norwegian (I translated it and opened a pull request, but could not wait for it to go through. It's been 7 months now...). The other reason for not sticking with Netlify Identify was that I started working on a dashboard for user account management where I would need some more advanced functionality than Netlify Identity Widget could provide. After some research, I ended up choosing Auth0.

How do you know that Netlify is production ready? I found Netlify Identity to not be production ready* and now I'm not so sure about the rest of the platform.

* Three reasons. 1) The identity widget has people setting it up in such a way that tokens aren't refreshed and logins last only an hour. https://github.com/netlify/netlify-identity-widget/issues/11... 2) Netlify Identity keeps bumping me out despite having gone out of my way to get it configured properly. I don't know why but the issue has lasted for weeks. 3) In development mode, the token can't be verified without making a request to Netlify Functions, and the suggested path (in Redwood.js at least) is to just parse the JWT without verifying it.

If you’ve been following us from the start, you will know that Supabase Auth started by forking Netlify’s GoTrue server. A lot has changed since then and we’ve diverged from the upstream repository. At this stage it makes sense to rename the project to something else (cues drumroll) — Auth.

I am testing gotrue netlift module https://github.com/netlify/gotrue

I guess since it's a deviation of it

To answer point 1: Maybe to start out, but in the long run, having only social logins may cause your app to lose a segment of the market (I don't know how much). If you're fine with that, then by all means only support social logins.

However, I strongly suggest having it (or some way for someone not to use a social provider) if you want to have as many users a possible.

Personally, I don't have a google account, I'm wary to use my Apple account for non-Apple sites, and I don't have facebook, instagram, new gen z hotness app, etc... And I can confidently say I am not alone in choosing to use apps which don't require a social login.

At the end of the day though, password auth isn't a non-trivial problem. It is a solved problem of which there are numerous articles/papers and many libraries for most languages/frameworks. For example, the Phoenix framework for Elixir has a built in command which scaffolds auth, and it works really well (I have used it in a personal project): https://hexdocs.pm/phoenix/mix_phx_gen_auth.html. For JS, you can use something like passport: https://www.passportjs.org/packages/passport-local/. If you want a separate service entirely (even though it would be more complex to have a separate service to start out), there is GoTrue: https://github.com/netlify/gotrue. These are just a few suggestions of tech I have come across. There is so much more out there, I encourage you to research options to see what may be a best fit.

If you're worried about password auth, maybe give one time passwords a try. They don't require any password reset flow, and are generally secure when implemented correctly. As an example, I don't have a password for my craigslist account. Every time I want to login, I can choose to get a magic link/otp which gets exchanged for a session. In practice (and this is my personal opinion), I prefer magic links. They are one time, hard to guess (again dependent on implementation), can be time limited, and most likely won't be intercepted in transit (though it could be in a rare circumstance).

To answer point 2: yes.

If your app is to order things (I use things in a general term) it sounds like eCommerce. And if you're in eCommerce, you better have a way for a user to track what they have ordered and how much they have paid for it at a minimum. Otherwise, your site may come across as a scam, even though it uses Stripe. Sketchy sites can use Stripe to get your money (albeit, it'll be a one time payment).

In conclusion, auth for your application seems crucial. Email/password auth is still relevant for applications. While not necessary for an MVP, there is a segment of the market you will lose if you don't have an email/password option, or even an email/OTP/magic link option (I don't know how much, really going off an educated guess).

Best of wishes in building your app! I genuinely hope it is successful and safe for people to leverage :)

Use a self-hostable auth microservice like gotrue or authelia, ORY's suite of products, etc.

Any examples for implementation like https://github.com/netlify/gotrue for Actix-web?