I think one major difference between the Zanzibar implementations that are out there is support for the 'zookie' consistency token (as mentioned in the original paper). OpenFGA afaik doesn't implement zookies yet[1]. With zookies, each permission write generates a unique token that represents that particular write. Clients can store that token (per resource) and optionally provide it during runtime checks to ensure checks are consistent up to that write. It also helps the system guard against the 'new-enemy problem' (incorrect permissions checks due to permissions changes being read out of order) by ordering writes.
I'd argue that it also unlocks a variety of caching implementations on the Zanzibar server while still allowing clients to specify desired consistency on a per-request/per-resource level. In other words, a Zanzibar implementation with support for zookies can guarantee consistency at a much higher throughput than one that relies on time (second, millisecond delay). This is important for generic 'read after write' scenarios.
Disclaimer: I'm a former founder of Warrant[2] which was recently acquired by WorkOS. Our team has spent a ton of time building our Zanzibar-based authorization service (WorkOS FGA[3]) which supports zookies[4] and other Zanzibar concepts.
The specific challenge with authz in the app layer is that different apps can have different access models with varying complexity, especially the more granular you get (e.g. implementing fine grained access to specific objects/resources - like Google Docs).
Personally, I think a rebac (relationship/graph based) approach works best for apps because permissions in applications are mostly relational and/or hierarchical (levels of groups). There are authz systems out there such as Warrant https://warrant.dev/ (I'm a founder) in which you can define a custom access model as a schema and enforce it in your app.
I'd argue that it also unlocks a variety of caching implementations on the Zanzibar server while still allowing clients to specify desired consistency on a per-request/per-resource level. In other words, a Zanzibar implementation with support for zookies can guarantee consistency at a much higher throughput than one that relies on time (second, millisecond delay). This is important for generic 'read after write' scenarios.
Disclaimer: I'm a former founder of Warrant[2] which was recently acquired by WorkOS. Our team has spent a ton of time building our Zanzibar-based authorization service (WorkOS FGA[3]) which supports zookies[4] and other Zanzibar concepts.
[1] https://openfga.dev/docs/interacting/consistency#future-work
[2] https://warrant.dev/
[3] https://workos.com/docs/fga
[4] https://workos.com/docs/fga/warrant-tokens