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.
You can encode capabilities/permissions as scopes in distributed tokens (e.g. OAuth) but this can start to break down if you have very granular, fine-grained permissions (e.g. user:1 has 'editor' access to 1000s of documents/objects). This is similar to the problem that Carta ran into while building out their permissions[1].
In addition, yes - validating permissions on each request makes it so that you can revoke privilege(s) with immediate effect without needing a token to be invalidated.
What we're building at Warrant (https://warrant.dev/) might work for a lot of what you mentioned including APIs to build and manage multi-tenancy, groups, users, orgs/tenants.
Note - Warrant is an authz engine so it doesn't handle authn/identity/SSO but can plug-in with any authn system.
They might not be the exact same concept but they're definitely related. I'd argue feature flags, authorization, and pricing tiers/entitlements all make up modern 'access control' and 'access management'.
It used to be that authz was just roles and permissions assigned to users, or feature flags & entitlements just booleans, but sophisticated systems allow for all kinds of permutations and rules based on attributes, relationships and environment such that the lines between them are blurred and implementations are likely similar.
As others have said, the differences still come down to a handful of factors like correctness, tolerance for error and performance.
(Disclaimer: I'm a founder in this space and spend a lot of time thinking about it at Warrant - https://warrant.dev/ )
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