[kinos]

The only thing preventing me from jumping right onto this is the fact it doesn't seem to be an oauth2 provider, and it doesn't seem to have the verify/reset/etc jobs necessary for username & password.

Verify/reset/etc is always what pushes me away from doing multi-user webapps. Its a headache every time due to needing to think about e-mail, and I'd love an all-in-one oauth2 provider with signup and etc thats super lightweight and just does everything through an API.

[smcnc]

Hi there! Engineer on the team here (and the one actually doing some of our auth and jobs stuff recently). We currently integrate with Google via oauth2 for social login, and plan to add more providers soon (GitHub coming next). The underlying mechanism is using Passport.js, which in turn uses oauth2 for most of their provider integrations, but that is abstracted so we can change in the future without breaking Wasp users. How would you envision Wasp itself being an oauth2 provider as beneficial vs integrating with other more popular providers?

As for username & password - correct, we do not do any email verification and reset right now. We actually changed the name from email & password to username & password to reflect the fact that we don't have tight email integration yet in Wasp. However, that will be coming soon, and once we do have first-class email support we plan to enrich that login method to have email verification with password reset, perhaps magic links, etc.

So long story short, we are trying to move quickly to add more auth options but be deliberate in how we integrate everything to ensure they all play together nicely. Please do check us out if it seems interesting and drop into Discord to let us know how we can improve to fit your use cases. Thanks!

[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)

[Terretta]

85% of companies, their users have Microsoft accounts via M365 for their company accounts. Your users work at companies ...

Login with Google leaves at least 85% of your company employed userbase by the wayside, so add Login with Microsoft.

Really, your auth should look something like this:

https://www.xsplit.com/user/auth

[smcnc]

Hi there! Yep, we plan to add many more social login options. I'm confident all of those on that site will be supported. As with our first implementation (Google), each will be enabled by Wasp users by changing a few lines in their Wasp file and adding the appropriate envars. We're just refactoring it a bit as we add a few more to speed up the internal process of exposing them. Thanks!