🎉 Announcing dbAuth OAuth Plugin v2.0.0 - easily enable Sign in with Apple, GitHub, Google, and more!

Get Help and Help Others Show & Tell
21

We discussed it with my colleague two weeks ago and decided to invest some time in our next sprint for some POC tests.

I’m right now in vacation and would give you a feedback as we went further.

22

Thank you for putting the work in on this. I had the exact same need - nice to see the work’s been done already!

Just a caution. You asked for suggestions on additional providers to include. I’ve seen similar libraries in other frameworks (not just login, but anything that adapts to 3p services). I’ve noticed that libraries that support a large number of 3p providers end up not being well maintained, it’s just too much work.

I’d suggest just sticking to the providers you have and having a well-defined plugin architecture for your plugin, with good documentation on how to add custom providers. If you’d like any suggestions on the API for the extension point, I’d be happy to chime in - I haven’t looked through your implementation because it’s not a pressing need for me yet (fakin’ it till I make it).

1 Like
23

Sounds great! Let me know if I can provide any further information or assistance.

24

Of course! :slight_smile:

Totally hear what you’re saying - I did some research on other implementations, and found the same. Most OAuth libraries, IMO, try to do way too much, and end up being extremely provider specific with the exact issues you described. The other downside is that it then increases setup complexity.

For this reason, the approach I took here is to only focus on auth, with minimal user info retrieval from the providers (lowest common denominator is Apple, which only provides email).

Therefore, rather than provider specific solutions, this plugin focuses on using OIDC ID tokens (where possible), or OAuth2 user info endpoints (when OIDC isn’t supported).

What this means is that adding a new provider ideally just means adding the provider specific endpoints.

Whenever you get around to giving the plugin a go, definitely don’t hesitate to chime in with any suggestions or questions!

25

Awesome. Thank you!

1 Like
26

Of course! :slight_smile: Let me know if you have any thoughts!

27

This is great work. Thank you. I there a way to add easily another provider at the moment? Or could I make a PR? I want to integrate with Linear.app

28

Thanks! :slight_smile:

Definitely feel free to open a PR! Let me know if you have any questions or run into any issues.

I took a quick look at the Linear.app docs - it doesn’t look like it supports OIDC, just OAuth2, in which case you would follow the same pattern I took for GitHub.

Another note - I want to minimize dependencies, so use their REST endpoint instead of their client SDK.

Keep me posted!

29

Another thing - I use Yalc and Lerna to keep the working project in sync with my testing Redwood app, and the Yarn workspaces are already set up with scripts for running these. Let me know if you run into any issues with that as well.

30

Just published v2 of this plugin, which works with RedwoodJS v8!

The sample project has also been updated :slight_smile:

4 Likes
31

@arimendelow Thank you for the plugin. I have a quick question.
I don’t really understand the rational behind Sign up and Sign in differentiation using OAuth. I am thinking of just adding “Sign-in with Google” and then detect on the backend if email already exists. If it exists, continue, otherwise create a new row in the user table. What am i missing here? Wouldn’t it simplify the flow a lot?

I see that since you wrote the plugin, you had to target a wider audience and there would always be someone with a need that they need to differentiate it at the user level.

Just trying to steer away from future problems as early as I can.
(My question is nothing urgent. Hope you enjoy holidays.)

Adorn

1 Like
32

Hi Adorn, and welcome to the community!

That’s a great question, and it was a deliberate design decision to avoid allowing users to accidentally create new accounts. A UX belief that I tend to adhere to is that all actions taken by the user should be deliberate ones — in this case, clicking “Sign Up” if one attempts to sign up, and “Sign In” if one attempts to sign in. Bad things can happen if you try to “simplify” a user’s experience by taking action on their behalf that they may not have intended.

For example, it’s not uncommon to have multiple emails, and quite common to not remember which log in method you used with a given platform.

Therefore, the library is designed to support two scenarios:

  • Not remembering which login provider you signed up with, or which account within one of those providers. It’s important to this scenario to be able to try signing in with any number of accounts.
  • Connecting multiple providers to a single account. This way, we can minimize the odds a user forgets which provider they used by simply allowing them to connect all of them to their account.

That said, if you do want to support a unified “Sign In” button that will sign up any user without an account, I believe it would be pretty straightforward to add a configuration option. Let me know if opening a PR for this is something you’d be interested in working on, and I can give you some code pointers to help get you started! :slight_smile:

33

@arimendelow Yes, I would be interested in contributing. Would need a lot of pointers though - I am new to full stack development.
I think I can get something working and create a PR, we can take it from there.

1 Like
34

Sure! To start, take a look in the following places:

So I would add an option to OAuthHandlerOptions called something like signupOnFailedLogin that calls that signup method instead of returning an error.

That said, if you’re focusing on building some type of app, I wouldn’t worry about details like this just yet — the difference it’ll make to any perspective users it not worth the effort.

However, if you’re just learning FSD and this interests you, then go for it!! I’m here to help :slight_smile: