v4 Decoupling Auth Providers: Discussion about Ongoing Built-in Support for Nhost, magicLink, azureActiveDirectory, and WalletConnect (Ethereum)

[thedavidprice]

Redwood v4 will include new architecture for integrating specific auth Providers with Redwood Auth, which we refer to as the "Decoupling Auth" project. The core auth API and functionality will remain the same while radically improving the ability to implement any provider plus making auth more sustainable to maintain overall. For related PR and description, see background details at the end of this Issue. (Note: there will be breaking changes with v4, but like all our major versions we are focused on a simple path to upgrade that will include an RC release period for testing.)

Built-in Provider Support versus Custom Integrations

With these changes comes a new capability to integrate any auth provider using the Custom implementation (e.g. yarn redwood setup auth custom).

👉 To learn more about Custom auth, see [RFC]: Thoughts on Custom Auth Setup and Ideas to Improve #6909

Before v4, support for any provider must be "built-in" to Redwood, e.g. added directly to the Redwood framework codebase.

After v4, there will be the option for supported providers to be:

1. built-in (via upcoming @redwoodjs/auth-[provider] packages) or
2. implemented directly per-project (i.e. custom, one-off integration) or
3. third-party packages (pending CLI plugin support, which has been technically validated)

We plan to continue built-in support for the existing auth providers (see all via docs here), however, we want to discuss whether or not several of them would be better as custom integration options from v4 ongoing. Why? Due to some combination of the folllowing:

• not currently working as is
• small existing installation base
• lack of active maintenance
• challenges/overhead upgrading to v4

🎙️ Discussion: Moving Magic.js, Nhost, Azure Active Directory, and WalletConnect (Ethereum) to Custom Integrations

I propose transitioning the following Auth Providers from built-in support to custom integration options:

• Magic.js
• Nhost
• Azure Active Directory
• WalletConnect
• Okta

What this would mean for v4:

1. There will not be packages for these auth providers
2. Instead, Custom implementation setup will be used

Note: in either case, the Redwood Auth API and features will not change

I'm especially interested in feedback and questions from these fine folks below. (I've attempted to tag all the individuals who have contributed code and direction to the providers listed above. Please let me know or include anyone I missed!):

@jeliasson
@BurnedChris
@shahbaz17
@doesnotexist
@stephenhandley
@nunopato
@pi0neerpat

What say you all?

Background: Decoupled Auth PR and Description

• Decouple auth #5985

...from the PR

v4 Decoupled Auth
For this release Redwood has totally revamped its authentication subsystem. The biggest change is that all auth providers are totally decoupled from Redwood's internals. We're doing this for a couple of reasons. One reason is we want to make maintaining the auth providers more sustainable for Redwood as a project. Auth providers can now be their own packages on NPM, so we're hoping devoted community members and auth companies will take over maintenance and ownership of auth providers, so we can focus on adding other features to Redwood. Another big reason is we wanted to make it easier for anyone to write their own custom auth provider. And finally we wanted to make it possible to have multiple auth providers configured at the same time. This is great if you for example want to switch from one provider to another and need to run both for a short time while moving all your users over to the new provider. Or if you want to have a different auth system for API access to your app.

[jtoar]

Think we missed one ping: @NoahC5 (feel free to reach out to me on Discord as well!)

[pi0neerpat]

Sounds good to me! The Ethereum login was always intended to be a "some-assembly-required" option anyways

[Tobbe]

@pi0neerpat auth setup has gained some additional abilities/flexibility, so it should now be possible to write a setup command that adds extra api side functions, like those used by dbAuth. So if you're up for it I think those assembly steps could be greatly simplified. And the implementation wouldn't need to inject itself into apollo like it does now. At least that's what I gathered from reading yours and Rob's comments from when you initially wrote the integration. But my understanding of Ethereum/Wallet Connect is very limited, so I could be wrong.

[pi0neerpat]

@Tobbe the api-side code injection is very helpful. Also, just a reminder that the new method 'wraps' dbAuth, so any advice there would be appreciated. I'll have to look at how its implemented now with v4

[jeliasson]

Sounds good to me! It would be great if we could continue to have Azure Active Directory built-in throughout v4, and I'll be happy to port and maintain a custom integration for v5 and onward. Currently just some time constraints on my part.

[Tobbe]

Also, just a reminder that the new method 'wraps' dbAuth, so any advice there would be appreciated.

@pi0neerpat Again, limited understanding here. But my guess is you'd copy/paste the dbAuth implementation and add your code ontop of it. So it's not actually wrapping an existing dbAuth setup. It's dbAuth+Ethereum baked as one provider

Sounds good to me! It would be great if we could continue to have Azure Active Directory built-in throughout v4, and I'll be happy to port and maintain a custom integration for v5 and onward. Currently just some time constraints on my part.

@jeliasson I've actually already done the porting work. Do you think you'd have time to just help me test it? I'll provide you with step-by-step instructions for how to test and what I'd want tested in that case.

[jeliasson]

I've actually already done the porting work. Do you think you'd have time to just help me test it? I'll provide you with step-by-step instructions for how to test and what I'd want tested in that case.

@Tobbe Great stuff! Hit me up on Discord and we'll do some testing!

[Tobbe]

v4 has shipped. GoTrue, Magic.js, Nhost, WalletConnect, Okta are now deprecated. Read our docs if you want to use any of those five https://redwoodjs.com/docs/auth/custom

[jeliasson]

Good work on this everyone!