Sibling teammate here!
A caveat: I haven’t had experience with any AuthZ Elixir libraries, so I can’t really compare OPA with them.
My team had a rocky start with OPA, but we have reached a point of comfort and confidence with the policies we are now defining and maintaining.
An obvious downside to using OPA, is that your team will have to learn a new language and structure for thinking about authorization. As someone with a background in imperative languages, I was certainly challenged by the declarative nature of Rego. However, I’m pleased by how clean and concise OPA can be. When done right, policies read very clearly – for example it is easy to see that a user with an administrator role is allowed certain actions in contrast with other user roles.
My team initially structured our authZ policies in a somewhat naive way. Thankfully, when pain points quickly began to arise, we were able to re-think our approach on OPA and discover better practices for defining policies. This required revisiting the (somewhat limited) OPA documentation. I also found this deep dive from KubeCon to be extremely helpful. I highly recommend it. After re-thinking and re-writing our policies, we arrived at a much better state. The false start was somewhat of a blessing in disguise, because it allowed us to see exactly what we didn’t know about OPA and then learn it quickly.
Another thing I’ll mention is testing. I don’t have any specific complaints about OPA tests, except that they aren’t ExUnit! I have become so accustomed to writing tests in ExUnit, that it’s hard to write tests outside of that framework.
Overall, my team has had a positive experience with OPA. Placing authorization policies in a different language forced as to separate our concerns from the rest of our code. I think this helped us make good decisions regarding our code organization. The declarative nature of OPA/Rego makes it very clear to us and to non-developers which types of users have which types of permissions and have access to which types of resources.
