[ffk]

On the first point, OPA is much older than OpenFGA. To really illustrate the point, OPA became a graduated project about a year before OpenFGA had their first code drop in the public GitHub repo. The OpenFGA people are aware of OPA and I'm sure they learned from the tradeoffs OPA made.

To the main point, what you described reflects the current trends of authorization. Define a data model, define data that adheres to that model, write declarative rules that consume that model, make a decision based on those rules.

Where things really start to differ is the kind of data that they bind against and how do you write rules. E.g. OPA is often used for either ABAC (Attribute) or RBAC (Roles) while OpenFGA is looking at ReBAC (Relationships). Each has their complexity tradeoffs, depending on the system being implemented. How easy or difficult a system makes these kinds of checks has a significant impact on how you write policies.

Hope this helps!

[shriek]

Yeah, that's what I've noticed too. Conceptually, they're more or less same giving an option of RBAC, ABAC or ReBAC and each offer their own DSLs (e.g. Oso, Ory Keto etc) and deployment strategies. It's been a bit harder to pick one honestly but I guess I'll just have to just use them to find which one fits for me.

[ogazitt]

If you want to try Topaz (which supports all three), check it out here [0]. We'd love to help you solve your authorization scenario :)

[0] https://github.com/aserto-dev/topaz

[andyroid]

Not sure why that matters, but OpenFGA is an implementation of Zanzibar, which isn't exactly new. There are many similar implementations to choose from should one want to model authorization via a graph database.