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

[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