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.