I think that Redwood is actually in a very good position to leverage cloud native identity providers such as Keycloak and Dex. Auth0 gets way too expensive real fast and Netlify Identity is pretty lack luster especially with events. Most teams will probably consider something like Keycloak when scaling and/or thinking about more robust security especially on tenanted applications where each tenant can have thousands of users.
These ID providers would require standing up a separate db just for identity/auth related workload. Though this sounds like a pain at first, but in my opinion, as I work with Keycloak more, it is a pattern that works really well.
Just wanted to post about it to get people curious about this. And also to see if anyone has tried this with RedwoodJS (I haven’t tried it on RW yet; was going to try it this week). As a general guideline for people who haven’t used something like KC, this is how I setup the dev env with NextJS and CRA (you can find detailed tuts on google):
- Dockerize Keycloak
- Create a docker-compose.yml to standup a KC server
- Setup your realms and auth provider clients within KC
- Boiler plate KC API client in the React app
- Setup the KC Provider at the top of the app
- Usage with KC React Hooks
Note that the default auth flow is very similar to Auth0’s gateway flow (redirect to a secure page to authenticate then back to application).
I understand RedwoodJS’s mission of simplifying fullstack development, but Auth0/Netlify seriously don’t cut it for production. It’s been such a hard sell for me. And I think it might help RW adoption if there are at least robust examples of Keycloak, Dex, and even Cognito in the mix (even better if there are ID management tooling/bindings built-in).
I mean, you can imagine that even for an established infra running these OIDC providers, if RW can just plug and play, how much buy in power we could have for something like a new application in the org or some frontend refactor.