Include feature comparison table for different auth providers

[ajcwebdev]

The Problem

There are a wide range of current options for auth. The options have expanded exponentially since the original tutorial and there’s numerous overlapping implementations with a complicated matrix of pros and cons for each. We have thorough docs for implementing any of the available options but not something that actually compares features.

The question is, why would you use one implementation vs. another?

Some of the most important differentiating factors include:

• Which are complete identity services vs just login?
• How aligned is the auth provider with a deploy target?
• Are you managing your own auth vs. using a third party?
  • Who is responsible for keeping user profile, password, and other credentials secure?
  • Who is handling anomaly attacks, logging, and audits?

Potential Solution

This could be represented in a comparison table on the Authentication page with:

• Providers across the top
• Features down the left
• Checkmarks

[thedavidprice]

This feels like limited ROI for me — more so overhead. Maybe better if it's in the Forums as a Wiki for editing and discussion.

Don't get me wrong. I 💯 feel the pain of upfront decision overload + fatigue --> I feel like this will only add to the overload. (Go ahead and just imagine a chart with 15+ "features" across the top and 12+ providers vertical... how does that "feel" to your mind's eye?)

Instead, let's direct people to the next step:

1. Get started e.g. "Just try this... look, it's so easy! Oh, and now I'm changing providers. Also easy!"
2. Give people a few guidelines about how to evaluate and choose
3. Suggest a limited number of options — max 3 — and reasons why they should try 'em. I'd suggest Netlify Identity (easiest to get going), Supabase (if you're interested in Supabase it's da bomb), and dbAuth (only self-hosted option).

[jacebenson]

How bout a "what do I get with these providers" widget where they pick auth provider (provide snippet), db provider (provide snippet), hosting provider (provide snippet)

you pick the three it builds out the links to the relative docs and commands to get started w/ small feature set of what it buys you either "at little cost" or "free"?

[dthyresson]

My concern would be some inferred or implied bias or recommendation of one provider over another — just as there is choice over a host and deployment would one weigh in with a feature set comparison?

[ajcwebdev]

I definitely agree we want to avoid information overload and I don't think this necessarily needs to live in the docs repo. But I think it's useful information to collate somewhere, because there are going to be users who look at this list and will have to do the due diligence themselves unless they want to throw a dart and hope for the best.

It's true there is a low switching cost but if we can also remove the time required to try out different options we'll be saving developers valuable prototyping time. Many core team members have all this context in their head and know generally what the difference is between these services, but that information has not been externalized anywhere. I wouldn't want the feature list to be too long, maybe somewhere in the area of 4-6 depending on what features users think are the most important.

To the point about hosting and deployment providers, I think this is a similar situation and it would be useful to provide more explicit guidance around what the different options include and how they are different from one another. This is one of the reasons I wrote A History of Hosting RedwoodJS.

[dthyresson]

I do see the argument, but I just am playing "devil's advocate" for the slippery slope -- does the official documentation also include a breakdown of databases (PG vs MySQL vs Aurora vs SQLServer vs Mongo) and even db providers (Digital Ocean vs Heroku vs Supabase vs Render vs PlanetScale vs Railway).

As DP noted, perhaps the place for this info is a cookbook or blog vs the docs.

[ajcwebdev]

I'd say no to database type but maybe yes to database providers (for example some of those give you PostgreSQL, MySQL, and Mongo instead of just Postgres or MySQL which would be good to know).

[keithtelliott]

I recently fell into an auth hole and have been clawing-out for a month. I never messed with auth in the past, so I can offer the noob perspective…

I crave cookbooks/tutorials like the Rob’s Netlify GoTrueJS Cookbook.

I was NOT bogged-down picking an auth path. I just picked Supabase Auth b/c my Maker Hour peeps use it. (just tell me a reasonable path and I'll take it)

I WAS bogged down figuring out what’s-what. I can now tell you that the Redwood Supabase auth client wraps the Supabase GoTrueJS client which is a fork of Netlify’s GoTrueJS client (which is different than Netlify Identity, and none of these have anything to do with dbAuth, and I don't need to mess with RBAC at the moment). But, it took a few weeks to figure that out.

So, I'm motivated to write a Supabase Auth Cookbook and post it on the forums, following Rob's great example... to save others from getting bogged down figuring out what's-what.

In a React Podcast Tom mentions taking a Redwood golden path to make dev easier. A key challenge for us Redwooders will be to create few selected golden paths through third-party providers (which are related and necessary but not as tightly controlled by us)...

[thedavidprice]

@keithtelliott that's a fantastic idea especially since we recommend Supabase all the time. Bonus points if you create a recorded screencast that goes through the cookbook. We could upload to the Redwood YouTube channel! (no pressure 😉)

[thedavidprice]

Thinking further on this, here's what my recommendations would be if I were to take a stab at this doc:

Caveat: Redwood is designed with iteration in mind. Although each Auth provider will have it's own specific setup required, Redwood Auth reduces the pain of switching to a minimal amount. 90% of Redwood project switch up Auth providers along the way. Don't get bogged down in comparing features and trying to answer the question "which Auth will I need when I hit 100k users in 3 years... ?" Just get started with one of the options below, learn, iterate, and repeat!

1. Just looking to see how easy it is to set up and deploy Redwood auth (especially on serverless)?
   • Use Netlify Identity and then deploy on Netlify
2. New(er) to Auth and want to learn the aspects of Auth setup and management in a full-stack app?
   • Use dbAuth
3. Already understand Auth, want to use a 3rd party, and want an integrated Auth + DB solution that works for serverless and traditional (and included a lot of additional bells and whistles)?
   • Use Subapase

There are a lot of other amazing Auth Providers available as well, severing all ranges of products from "just getting started" to "enterprise ready". If you have specific needs, experience, etc. and already know what you want, definitely ignore the advice above and dive in. Redwood has your back, too!

[keithtelliott]

@thedavidprice all right, I’m in. Call it a Hacktoberfest project…. I’ll drive to deliver a Supabase Auth cookbook by Halloween

[keithtelliott]

Progress update... I'm writing and I'll deliver - just a little late.

I have to say I'm an Astros fan, and therefore baseball became a part-time job for me as my team headed to the World Series in October.

Fortunately, Astros Manager Dusty Baker gave me official permission to turn in my Supabase Auth Cookbook a week late (but just one week late).

[keithtelliott]

Did it! A few days ago I posted a Supabase GoTrue Auth Cookbook on the Redwood Forums.

I hope it's a handy resource for those climbing the Supabase auth learning curve!

[ajcwebdev]

Awesome job Keith!