Keep the decoupled-policy model. Lose the external tuple store and the hot-path hop.
OpenFGA brings Google-Zanzibar relationship-based authorization to the open-source world, with a .NET SDK. Decoupling authorization logic from code is a genuinely good idea. But OpenFGA requires copying authorization data into an external tuple store and calling out to it on the hot path. B5 keeps the decoupled-policy benefit and co-locates the decision and its enforcement in-process — no store to sync, no round trip.
Framing: Embrace the decoupled-policy idea. Deliver it as a native .NET attribute, enforced in-process — no external store.OpenFGA is B5’s nearest technical neighbor — and it’s a good one.
OpenFGA (CNCF, Zanzibar/ReBAC) is well-engineered and genuinely advances the field: authorization modeled as relationships, decoupled from application code, with a real .NET SDK. B5 embraces that idea rather than fighting it. The difference is operational locus. OpenFGA externalizes the decision to a tuple store you must populate, sync, and keep consistent, and calls out to it per check; B5 evaluates the decoupled policy in-process at the call site — the same modeling benefit without the external store or the hot-path network hop.
Borrow this, don’t fight it
- Open-source, CNCF, Zanzibar-grounded relationship-based authorization
- A clean modeling language for relationships and a .NET SDK
- Decouples authorization logic from application code — the right instinct
- Active community and a vendor-neutral governance model
Decoupled policy, but an external store to feed and a hop to make
- Requires copying authorization data to an external tuple store — sync and consistency overhead
- Each check is a call-out to the OpenFGA service on the hot path
- A standing service and store is operational surface to run and secure
- B5 keeps relationships and policy decoupled but evaluates them in-process — no store, no hop
OpenFGA decides. B5 enforces — at the line of code.
| OpenFGA | B5 Secure | |
|---|---|---|
| Locus of enforcement | External authorization service / synced tuple store | In-process, at the call site |
| New live attack surface | Yes — service + store | No added service or endpoint |
| Authorization data leaves your boundary | Varies — managed syncs tuples; self-hosted stays in your infra | No — evaluated in-process |
| New sub-processor for the customer | Varies (managed vs. self-hosted) | No |
| .NET integration | Generic SDK (.NET SDK available) | Idiomatic [Permission] attributes & middleware |
| Agent identity model | Resource-scoped (relationship-based) | First-class + in-process enforcement today; agent OBO + ephemeral scope is a Q4 2026 roadmap extension |
| Best role in your architecture | Model relationships & decisions | Enforce the decision where it executes |
Capability status. In-process [Permission] enforcement Generally Available Agent OBO delegation, ephemeral SPIFFE-compatible agent identity and CAEP/SSF signal ingestion are Q4 2026 roadmap extensions Preview.
The questions a buyer actually asks
We like ReBAC — isn’t OpenFGA the standard?
ReBAC is a strong model and B5 supports relationship- and attribute-aware decisions. The question is operational: do you want to maintain an external tuple store and call out per check, or evaluate the same decoupled policy in-process? B5 gives you the model without the store-sync problem.
Can’t we just use the OpenFGA .NET SDK?
You can — and you’ll still be making a network call to an external service for each authorization decision, plus keeping its store in sync with your data. B5 removes both: the decision is evaluated where the method runs, every call, with no replication.
Is B5 just RBAC, then?
No — attribute- and relationship-aware, context-evaluated per action, with OBO delegation and ephemeral agent scopes on the roadmap on the roadmap. RBAC is the floor, not the ceiling. The differentiator is in-process enforcement, not a weaker model.
Complementary, not competitive.
Model where you like; enforce in .NET with B5.
If you’ve invested in an OpenFGA model, B5 doesn’t throw it away — it can consume external decisions as policy inputs while enforcing in-process at the .NET call site. But for most .NET teams, B5’s native attribute model removes the external store entirely. Keep the decoupled-policy idea; drop the data-sync and the hot-path hop.
The decoupled-policy benefit — without the external tuple store.
Bring your architecture to a B5 architect. We’ll show you exactly where OpenFGA ends and where in-process enforcement begins — and the Trust Center a library, not a platform, gets to publish.
See enforcement at the record. Live.
Thirty minutes with a B5 engineer: your stack, the B1–B5 pipeline, and a data-element authorization decision you can watch happen — for humans, services, and AI agents alike.