[techdragon]

Jumping in on this, as someone who has evaluated a lot of these over the years… you cannot predict the auth needs of future customers… don’t waste time building bespoke per authentication provider OAuth2 based authentication options… just implement an OpenID relying party or just go all the way and support the OpenID Connect standards.

Then I can use anything I want, by way of the myriad of self hosted and commercial services providing OpenID based authentication service endpoints, Auth0, Keycloak, Okata, etc. The predominant mechanism for these sorts of “auth service” is OpenID Connect, because it really does immediately get you 80% of what you want from authentication out of the box with no additional work, saving heaps of time, provided you need these kinds of features and a built in framework username and password style auth system is inadequate and as long as the pain of running (or paying for) the separate service is acceptable.

And to tie this to their request, this would facilitate you offering an auth service by way of having the wasp DSL build infrastructure as code configurations for an open source auth service like keycloak, or even partner and white label an exiting vendor service as a premium service extra at $/month…

[smcnc]

Thanks for the feedback. I agree that relying solely on per-provider integrations would not be ideal (for us as maintainers, or our users). But for now, we are using Passport.js just to help us quickly bootstrap maybe a half dozen social logins to get our users started. In the long run, I can imagine deeper integrations with Auth0 et al. and possibly building out some of the other mechanisms like you describe!

[techdragon]

While supporting a couple of the most common ones directly is worth it, building deeper integration with a specific auth as a service provider is thinking about the process backwards.

The business value for the authentication as a service companies is to make it easy to Integrate with them in order to benefit from the extra capabilities they offer, via standard mechanisms that make their service a drop in component of a larger stack.

Authentication Services are already commoditised, and they are complementary to your business, and you don’t even have to do extra work to commoditise this particular complement! Just don’t fall into the trap of thinking it’s worth doing more. Auth0 can give me SMS based magic links, while simultaneously tying those to an azure Active Directory primary user to determine if the owner of the mobile phone number is authorised to use a given application. I have all that power, all that and more via your tools and frameworks… anywhere that supports the OpenID Connect standards as a relying party. Don’t think “deeper”, just think about getting the standard part done, and leave deeper authentication stuff to the company that want authentication to be their entire business. It’s worth noting that OpenID Connect does enable using almost any other social provider a customer might want, since having a big swathe of social auth options is usually feature #1 for an authentication as a service product or service.

Also it looks like passport.js supports being an OpenID Connect relying party already thanks to a couple of libraries already on NPM. Looks like it was a good choice of JS library/framework for this job, (I don’t live in JavaScript so I stopped keeping up with all the libraries and frameworks years ago, so I have no idea how ubiquitous or obvious the choice of Passport.js is)