I think this is interesting but I’m missing something. To me at least this doesn’t sound simpler than just using oauth to authenticate and then having a roles table etc on the backend to authorize. What would you say is the killer feature that would change my mind about this?
Thanks for the question! A couple of things that we think are killer features of Warrant:
- The flexible access control modeling. Implementing a basic RBAC scheme isn't too difficult with a couple extra database tables, but going further than that (fine-grained access control, inheriting access, etc.) is quite a bit of effort. With Warrant, you can model anything from RBAC to fine-grained access control and everything in between.
- End-to-end SDK support. There are many authorization libraries out there, but all of them seem to forget about the frontend. Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
> Warrant provides SDKs for authorizing access to your backend as well as a React SDK to make it easy to show/hide pages and components in your React app.
This actually sounds really cool. It’s always a pain recreating JWT and setting up security between the backend and frontend. Doing this as a framework and an api seems like a good approach. Thanks for sharing.
I think its a service that acts as your roles table. So your service would query warrant with a user and an action and it would return whether that's authorized? I'm also a bit confused why someone wouldn't use something like Ory[0] at any scale where modularizing this out was important.
That’s correct, Warrant would act as your authorization service, where you can store access rules for your system and check against them at runtime to protect access to your application. Roles are a common access control model, but you can model much more complex use-cases like fine-grained access control as well.
Keto + Oathkeeper together seem to be similar to what Warrant provides. One of our main focuses is providing great developer experience. We're continuing to build out the tooling around this, so stay tuned!
If you sell to a midmarket or enterprise customer base, they regularly need custom stuff.
eg group X of employees cannot see group 1 of customers' data. Or to use a more concrete example: US employees cannot see EU customer data because of GDPR. But it's never that simple: more fine grained, or with other exceptions.
This stuff took up way more eng time than I mentally budgeted; I could see a use case for a service.
Thanks for the response. I agree! That's exactly what we saw first hand at previous roles. Access control usually starts simple, but quickly evolves in complexity.
