OpenFGA v1.21.0 is a pattern for the question login never answers: may this technician touch this customer's object?

OpenFGA v1.21.0 is a pattern for the question login never answers: may this technician touch this customer's object?

The MSP reality is many customer tenants, technicians with different delegations per customer, and machine integrations that act on their own. After authentication, the real question is “may this subject perform this action on this object in this tenant?” A token, a group claim, or a logout event does not answer it; a decision point does. The project discussed here is a reference pattern, not a recommendation: OpenFGA, repository openfga/openfga, Apache-2.0, a CNCF Incubating project since 28 October 2025 (accepted 14 September 2022), described by its maintainers as a high-performance authorization and permission engine inspired by Google Zanzibar.

On 5 October 2026 the GitHub repository showed 5920 stars and a last push on 2 October 2026. Release v1.21.0, published on 20 September 2026, has a single listed addition, Dynamic Conditions, which the project marks experimental. A newer release, v1.22.0, followed on 6 October 2026. This article does not claim that any Altovar product uses OpenFGA.

The rest of the piece covers how relationship-based authorization maps onto MSP tenancy, the pin and supply-chain evidence on the releases, what OpenFGA is not (admission policy, network overlay, scanners), and six controls for running any central decision point. Login, logout and token validity are inputs; the entitlement is a decision made on every request.

Going by the repository's own description and topics, OpenFGA is an authorization and permission engine inspired by Google Zanzibar. The topics list relationship-based access control alongside RBAC, ABAC and policy-based access, plus “entitlements.” This article sticks to those sources: it offers no feature matrix, no throughput or latency figures, and no list of adopters.

Zanzibar-style ReBAC, in buyer language, means permissions are derived from relationships between subjects and objects—who is a member of which tenant, which site belongs to which tenant, which technician is delegated to which site—rather than from a long list of roles copied into every token. The decision walks the graph of relationships. It does not paste a role catalogue into every JWT.

Governance, per the CNCF project page read on 5 October 2026: accepted to CNCF on 14 September 2022, Incubating since 28 October 2025. Incubating is a maturity level in a foundation process. It is not a security certification and not a support contract. An MSP that treats “CNCF Incubating” as “audited for our customers” is reading a foundation label as a customer assurance it does not provide.

On 5 October 2026 the repository had 5920 GitHub stars and 511 forks. Stars are a popularity signal, not an assessment. The CNCF page shows separate LFX metrics with a different star figure; this article uses the GitHub figure and does not mix the two. The licence, as declared in the repository, is Apache-2.0.

The recent releases: v1.22.0 on 6 October 2026, v1.21.0 on 20 September 2026, v1.20.0 on 8 September 2026 and v1.19.0 on 25 August 2026. None of them is marked as a pre-release. The pin rule to repeat: run v1.21.0 or newer and nothing older, with v1.22.0 the better target for new rollouts because it adds a dependency security update. Do not track a floating latest image in a customer environment without a change ticket naming the tag.

The floor is not just “newest.” v1.20.0 carried a Security section: a toolchain CVE fix, a rebuilt health-probe dependency, and a fix for one OpenFGA advisory in the ListUsers path. Anything older than v1.20.0 misses those fixes; v1.21.0 sits on top of them. v1.22.0 adds one more Security entry, an updated gRPC library that resolves GO-2026-6443. The sentence an MSP can put in a ticket is: “v1.20.0 shipped security fixes, including one OpenFGA advisory in the ListUsers path; run ≥ v1.21.0, preferably v1.22.0.”

Dynamic Conditions needs careful wording. The v1.21.0 notes list it as “a new experimental feature”: experimental, not generally available. Customer entitlement logic should not depend on an experimental feature unless the customer explicitly accepts that risk in writing.

Release evidence an MSP can attach to a change ticket, as listed on the v1.21.0 and v1.22.0 releases: both are marked immutable, and each ships signed checksum files, an in-toto attestation, and an SBOM per binary archive. That evidence supports that the artifact you deployed matches what the project published, and that you have a component list. It is not an audit of the code or of your authorization model.

The question, written once and reused: subject · action · object · tenant. A technician, a partner account, a customer user and a machine integration are four kinds of subject. “Read”, “change”, “export” and “delete” are different actions. A device, a mailbox, a backup set are objects. Every object belongs to exactly one customer tenant. That four-part question is what a login event never answers on its own.

Relationships instead of copied roles: a tenant contains sites or orgs; resources belong to a site; a technician is related to a site by a delegation that can be time-boxed; a customer admin is related to their own tenant only. The decision point derives “may this technician change this mailbox?” by walking those relationships.

Why that helps the MSP: the entitlement leaves the token and the thousands of scattered if checks in application code and becomes one place that can be inspected, tested and logged. Revoking a technician's delegation to one customer is one relationship removed, not a token reissue across every app. The change has an owner and an audit trail in one store.

The defensive frame: deny by default, least privilege, and a check on every request (OWASP Authorization Cheat Sheet). Broken access control, including cross-tenant object access, is the class of failure this pattern is meant to reduce. A logout or a revoke signal can trigger a re-check; the decision point is where the re-check happens. That is also why a logout on its own is not a tenant revocation.

Gatekeeper and Kyverno are Kubernetes admission policy for infrastructure objects. They decide whether a manifest may enter a cluster, not whether a technician may read a customer's mailbox. Neither replaces the other. An MSP that conflates admission policy with application entitlement will write the wrong control into the wrong layer.

OpenZiti is a zero-trust network overlay. It decides which identities can reach which services on the network; it does not decide per-object application entitlements. Network reachability and object permission are different gates.

Trivy, Syft and DefectDojo are scanners, SBOM generators and finding aggregation. They describe what is in your software and what is wrong with it. They do not authorize requests.

This article does not say that Auris, or any other Altovar product, uses, embeds or integrates OpenFGA. OpenFGA is cited as an open-source reference pattern for central authorization.

Six defender controls for running any central decision point, each with what evidence looks like and what is not evidence.

First, inventory: which stores and authorization models exist, per customer or shared, and who may change them. Evidence is an exported list and an owner per model. “We use ReBAC” is not evidence. Second, pin: ≥ v1.21.0 recorded in the change ticket, with the checksum and attestation check result attached. A star count or a latest tag is not evidence.

Third, protect the decision API itself: authenticated callers only, reachable only from the application tier, admin operations limited to named operators with MFA. Fourth, model changes are code changes: reviewed, versioned, and tested with explicit cross-tenant deny cases before rollout. Evidence is a test run that shows tenant B cannot reach tenant A's object. “The model compiled” is not evidence.

Fifth, back up and restore the relationship data; rehearse a restore. A decision point with lost relationships fails either open or closed, and both are outages. Sixth, log decisions and model changes to the SIEM as operational signals, such as unexpected model edits or spikes in denies after a release. Finally, keep experimental features out of customer entitlement paths until the project marks them otherwise.

In short: Apache-2.0; CNCF Incubating since 28 October 2025; 5920 GitHub stars on 5 October 2026; pin floor v1.21.0 (20 September 2026), with v1.22.0 (6 October 2026) the better target; the v1.20.0 security fixes sit underneath; Dynamic Conditions is experimental. Gatekeeper, Kyverno, OpenZiti, Trivy, Syft and DefectDojo are not substitutes for a central application decision point. Login, logout and token validity are inputs; the entitlement is a decision made on every request.

This article does not claim that Auris uses OpenFGA. The pattern is open-source reference architecture for the MSP question that authentication never answers on its own.