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

[arimendelow]

Edit: This has now been updated to v2, which supports RedwoodJS v8!

If you’ve been using dbAuth and feeling envious over how easy those that use hosted auth providers have it when it comes to enabling signing in with a provider, today that all changes!

Introducing the RedwoodJS dbAuth OAuth plugin!

If you’d like a demo, this is currently being used in production at spoonjoy.app.

This library provides an easy and effective way to integrate OAuth into your RedwoodJS applications, offering a seamless experience for both developers and end users. Currently, it supports OAuth providers including Apple, GitHub, and Google, with a flexible architecture that allows for the expansion to more providers.

It even includes button components to make setup even more effortless:

The repo also includes a fully set up RedwoodJS sample project for reference.

This was super fun to build, and is only the first stage! Shoutout to @thedavid and @rob for getting me started. This v1 currently includes a limited number of providers (Apple, GitHub, and Google), so let me know what else you’d like to see here - adding additional providers is pretty trivial.

Get started today by checking out the setup instructions, and let me know if you run into any issues!

[dthyresson]

Nice work!

Could you explain the different cars for using a Sign In vs a Link?

And for Sign Up how does that work or mean? Most OAuth implementations I have seen are Sign In only since you cannot create an account from one app to another.

[arimendelow]

Thanks!

Sure! So:

• Sign up: create a new account in dbAuth based on information from a provider
• Sign in: log into an existing dbAuth account via a provider
• Link: link any provider to an existing dbAuth account. This is especially useful if you’re adding this functionality to an platform where existing users have already signed up via username/password, but now want to onboard to a passwordless world. A user can link as many providers as they want, but only one account per provider.

As far as the given OAuth provider is concerned, these are all the same - you authenticate with them and they redirect you back to the application.

[dthyresson]

@arimendelow

• Sign up: create a new account in dbAuth based on information from a provider

I see. So my flow would be:

1. First time I want to your a Google account with App 1 I “sign up with Google”
2. Then subsequently, I sign in.
3. If I then also want to have GitHub auth for my same account on App 1 I and then sign up with GitHub
4. Then later I can either sign in with Google or GitHub if I choose

But if I in step 2.5 tried to Sign In with GitHub before doing 3 Sign Up, it would fail?

I think I have seen providers like Supabase to auto account create and linking just on the Sign In, but I can see the distinction.

[arimendelow]

Sort of, but if you want to have GitHub auth for the same account you instead do Link GitHub - if you do Sign up, you’ll just create a second account.

And yeah, if you try to do Sign in with GitHub before you’ve either Signed up or Linked, it’ll return an error (this is the default but all error messages are configurable as with dbAuth):

It was an intentional design choice to make these 3 options (link, signup, login) distinct - I find that when auth providers do an auto-signup, it’s way too easy to accidentally create an account that now needs to be deleted. For example, if I sign up with Google, and then come back to your app a few months later and forget which I used, and try to sign in with GitHub, the last thing that I want is for it to create a whole new account - especially because now, unless that app has an easy way to delete accounts, my GitHub login is occupied by this account that I didn’t even mean to create.

[dthyresson]

@arimendelow

Sort of, but if you want to have GitHub auth for the same account you instead do Link GitHub - if you do Sign up, you’ll just create a second account.

But that is another OAuth account or another User? Meaning if I sign up twice, might it be easy to lose related records on the … well, I should look at the data model I suppose before asking :).

And if I have two GitHub accounts, when I Sign In, which one do I get signed in with?

[arimendelow]

Ha yeah, take a look at the data model I have a reference Redwood app in that repo, so you can check out the schema here: https://github.com/spoonjoy/redwoodjs-dbauth-oauth/blob/df3e759b06838c782e68234594e3d213cdc0e118/sample-oauth-project/api/db/schema.prisma#L35

I’m not sure what happens if you have two GitHub accounts - are you able to be signed in to two GitHub accounts at once? I know that for Google, if you’re logged into multiple, it’ll ask you which you want to use.

This is also why the username associated with that provider is stored, so that we can show it to the user - for example, on the screenshot above, how it says “Unlink arimendelow” instead of just “Unlink GitHub”.

[matbgn]

Hi @arimendelow, what a great job!

Regarding your question:

This v1 currently includes a limited number of providers (Apple, GitHub and Google), so let me know what else you’d like to see here - adding additional providers is pretty trivial.

When are you thinking of adding generic OIDC providers like Keycloak or Authentik?

[arimendelow]

Hey @matbgn! I’ve actually never heard of those, but as far as I can tell, they seem more like alternative auth providers (ie, alternative to dbAuth, 0Auth, Clerk) than OAuth2/OIDC providers.

If that’s the case, and you want to use those, your best bet is to create your own integration - Custom Authentication | RedwoodJS Docs

If I’m misunderstanding, can you give me some more information? I’d love to add support for more providers!

[matbgn]

Keycloak is certainly the leading open source solution for the standard protocols OpenID Connect, OAuth 2.0 and SAML 2.0. It’s backed by Redhat and really stable.

Authentik is more than just an IAM and also provides LDAP right out of the box.

You can deploy both locally on your machine using Docker and test it right away. We use Keycloak in the office so I could give you some limited insight if you decide to test it locally.

So to summarise, if you want to release your plugin to the open source community I’d encourage you to do it with Keycloak, it’s really the key player there.

More info here: https://www.keycloak.org

[arimendelow]

Ahhh got it - this plugin isn’t meant to be an IAM or LDAP, it’s only meant to be used with dbAuth, which handles all user management. My understanding is that Keycloak already has this functionality built in.

Are you using dbAuth?

[matbgn]

It’s a connector for OIDC protocol, I know… I know… You have maybe to read some stuff before, but at the end it’s like interfacing Github or Google but with the Keycloak endpoint

[arimendelow]

It’s not only OIDC (GitHub, for example, doesn’t support OIDC), but yeah.

How do you see this working with Keycloak? Some kind of plug-in to make Keycloak work with dbAuth feels like it would make more sense to me.

[matbgn]

Since Keycloak provides an auto-discovering endpoint with a single URL, the idea would be to infer from that what you think of it:

http://keycloakhost:keycloakport/auth/realms/{realm}/.well-known/openid-configuration

This will return all the endpoints you need

{
    "issuer": "http://localhost:8080/auth/realms/demo",
    "authorization_endpoint": "http://localhost:8080/auth/realms/demo/protocol/openid-connect/auth",
    "token_endpoint": "http://localhost:8080/auth/realms/demo/protocol/openid-connect/token",
    "userinfo_endpoint": "http://localhost:8080/auth/realms/demo/protocol/openid-connect/userinfo",
    "end_session_endpoint": "http://localhost:8080/auth/realms/demo/protocol/openid-connect/logout",
    "jwks_uri": "http://localhost:8080/auth/realms/demo/protocol/openid-connect/certs",
    "grant_types_supported": [
        "authorization_code",
        "refresh_token",
        "password"
    ],
    "response_types_supported": [
        "code"
    ],
    "subject_types_supported": [
        "public"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ],
    "response_modes_supported": [
        "query"
    ]
}

As explained here: What are Keycloak's OAuth2 / OpenID Connect endpoints? - Stack Overflow

And documented here: Securing Applications and Services Guide

This will make the setup much easier for the end user, as they will only have to provide this URL and everything will work out-of-the-box from there.

[arimendelow]

Thanks for sharing! Can you explain to me the use case you’re imagining from the users perspective? I’m still a little confused.

[matbgn]

This is THE open source single sign-on solution to unify the UX across multiple hosted services or applications.

In other words, if you’re developing or hosting applications and you want to provide SSO across all applications and you don’t want to depend on external services like Github, Facebook and so on, you need to choose a solution like Keycloak, Authentik or whatever, you name it…

[arimendelow]

Sure, but if you’re doing that, you’re also not using dbAuth, so I’m confused about your proposed use case here.

Unless you’re saying that you want to be able to use Keycloak as your cross-platform admin portal, and additionally use dbAuth + this plugin to authenticate users using SSO with Keycloak?

That sounds pretty cool - but why would you want to do that instead of just using Keycloak as your auth provider for your RedwoodJS app? It looks like if you’re already set up with Keycloak it would be pretty trivial to create a custom auth solution for Redwood.

If this is a feature that you would use, I’m happy to build it for you (or help you build it, my plugin is open source after all!), I just need some help understanding the use case.

[matbgn]

We are not familiar with dbAuth so far, full migration to RedwoodJS is an ongoing process, but managing a complete user and headless fleet is much more convenient with an Identity Manager or even more with an LDAP.

As far as we have designed so far, our intention was in fact to bridge dbAuth with Keycloak in some way, and as I understand it, your plugin was already ready for this, and the implementation was really straightforward but maybe I’m missing some part here.

[arimendelow]

Aha so let me lay out your options, as I see it:

1. Create a custom auth provider for Keycloak by following this guide: Custom Authentication | RedwoodJS Docs
   • If you do this, you can publish it in the same way I did this plugin, and if there’s enough demand it can be made into an official RW integration
   • This feels to me like the best option for you, as you’re already set up with Keycloak
   • The RW team and this forum are fantastic places to get help with this if/when needed
2. Use Keycloak solely as an OAuth2/OIDC provider, and then use dbAuth as your IAM+LDAP, using this plugin to handle that connection
   • With this option, you’ll have user info duplicated across the database being used by your RW app and the database you’re using for Keycloak

The whole purpose of dbAuth is to make it really easy to own your own auth, but if you’re already using Keycloak, then you already have that benefit. I don’t see any obvious advantages to using dbAuth on top of Keycloak, and it would complicate your auth stack.

Let me know if I’m missing anything! I think a RW+Keycloak integration could be a really cool alternative to dbAuth for people that want to own their own auth but have more enterprise/SSO needs.

[arimendelow]

Hey @matbgn what’d you end up going with?