Warrant

Warrant is a centralized, fine-grained authorization service built around the same relationship-based access control (ReBAC) model Google described in its Zanzibar paper. Rather than forcing a team to pick between RBAC, ABAC, or ReBAC, Warrant models permissions as a graph of relationship tuples — warrants like document:docA#editor@user:1 — and lets a single check engine enforce role-based rules, attribute-based conditions, and arbitrary relationship chains (“is an editor of a document that belongs to a team the user manages”) through the same API. Object types and their inheritance rules (owner implies editor implies viewer, and so on) are defined declaratively as JSON schemas, and access decisions come back with an optional decision path showing exactly which tuples produced the result.

Under the hood, Warrant’s Go server exposes HTTP APIs for managing objects, warrants, roles, permissions, tenants, features, and pricing tiers, plus a real-time check endpoint tuned for runtime authorization decisions. It ships with SDKs for Node.js, Go, Python, Ruby, PHP, Java, React, Angular, and Vue, and supports MySQL, Postgres, or SQLite as its backing store, making it straightforward to self-host via Docker or Kubernetes. The project also implements Zanzibar-style consistency tokens (“wookies”) to route reads to a primary datastore when strong consistency is required, and an ABAC-style policy language (built on the expr expression engine) for conditional grants such as time-bound access.

Warrant the company was acquired by WorkOS, whose hosted, horizontally-scaled successor is now marketed as WorkOS FGA. The warrant-dev/warrant repository remains open source under Apache-2.0, is not archived, and continues to receive commits from WorkOS (the NOTICE file lists WorkOS, Inc. as copyright holder). The README is explicit that this self-hosted version is best suited to proof-of-concepts, dev/test environments, and low-to-moderate throughput production use, since the fully distributed, low-latency deployment story lives in WorkOS’s commercial offering rather than in this repo.

What You Get

• A relationship-based access control (ReBAC) engine that stores permissions as object#relation@subject tuples (“warrants”) and can express RBAC, ABAC, and ReBAC patterns through the same model
• Declarative object-type schemas that define relation inheritance rules (owner implies editor implies viewer, group membership, tupleset traversal across related objects) without custom authorization code
• A real-time, concurrent check API that returns not just an allow/deny decision but the decision path — the exact chain of tuples that granted or denied access — for debugging and auditing
• An ABAC policy layer built on the expr expression engine, supporting conditional grants such as attribute comparisons and time-bound access via a built-in expiresIn() function
• Built-in primitives for common SaaS authorization needs: roles, permissions, tenants, features, and pricing tiers, so multi-tenant RBAC doesn’t have to be built from scratch
• A choice of MySQL, Postgres, or SQLite as the backing datastore, with self-hosting instructions and Docker/Kubernetes deployment guidance
• Official SDKs for Node.js, Go, Python, Ruby, PHP, Java, React, Angular, and Vue, plus a query DSL for listing objects/subjects that satisfy a given relation

Common Use Cases

• Adding customer-facing role-based access control to a SaaS product, letting customers self-manage roles and permissions for their own tenant
• Implementing object/resource-level, Google-Docs-style sharing and permissioning (“user X is an editor of document Y”) in a document or collaboration tool
• Gating SaaS features and functionality based on a customer’s pricing tier or subscription plan
• Centralizing and auditing access control for internal tools and admin panels, including approval-flow patterns (request access, admin approves)
• Meeting authorization auditability requirements for compliance frameworks like SOC2, HIPAA, GDPR, and CCPA by centralizing access decisions and their audit trail

Under The Hood

Architecture

Warrant’s Go server boots from a single entry point that loads configuration, connects to exactly one configured datastore, and manually wires up a set of domain services (objects, object types, warrants, checks, queries, roles, permissions, tenants, features, pricing tiers) — each following a consistent repository-service-handler layering with no dependency-injection framework involved. Routing goes through gorilla/mux behind a fixed middleware chain (structured logging, request stats, consistency-token handling, API key/JWT auth), with handlers registered through a generics-based route wrapper that avoids reflection. The centerpiece is the check engine: a concurrent, recursive graph walk bounded by configurable semaphores that evaluates direct tuple matches, group/indirect membership, and rule-based relation inheritance (including tupleset traversal across related objects) in parallel, returning both a decision and, optionally, the exact chain of tuples that produced it. A companion consistency-token mechanism (“wookies”, Zanzibar’s “zookies”) routes specific reads to the primary datastore instead of a replica when strong consistency is required. This is a genuinely well-organized implementation of a hard distributed-systems problem, with the caveat — stated candidly in the project’s own documentation — that fully distributed, low-latency operation at scale sits outside this open-source server’s current design.

Tech Stack

The project is a Go 1.23 module built on a deliberately lean, mature dependency set: gorilla/mux for HTTP routing, jmoiron/sqlx for SQL access (not a full ORM), golang-migrate for schema migrations, spf13/viper for YAML/env configuration, rs/zerolog for structured logging, golang-jwt for bearer-token verification, go-playground/validator for request validation, antonmedv/expr as the ABAC policy engine, and alecthomas/participle to parse its own small query DSL. Database support spans MySQL, Postgres, and SQLite through a shared interface with per-engine repository implementations and connection-pool-level read/write routing; SQLite specifically is opt-in via a Go build tag since its driver requires cgo. Nothing here is exotic — it’s a conservative, well-chosen toolkit for a request-driven authorization service.

Code Quality

Unit-level Go tests are sparse — only four _test.go files exist in the whole repository, concentrated around the policy engine and consistency-token logic — so anyone extending the core check algorithm has limited safety net at the unit level. That gap is meaningfully offset by an extensive API/integration test suite: dozens of declarative JSON fixtures exercised through a companion tool against every CRUD endpoint and dedicated authorization-semantics scenarios (policy evaluation, wildcards, queries), run through GitHub Actions workflows that spin up real MySQL, Postgres, and SQLite instances and exercise the compiled binary end-to-end on every change. Linting is stricter than typical for a Go project, with most available linters enabled and a license-header check enforced on every file. Error handling is consistent throughout via wrapped errors, and naming/structure follow a uniform pattern across domains. Overall: comprehensive black-box coverage and rigorous CI compensate for thin white-box unit testing of the trickier concurrent logic.

What Makes It Unique

Warrant is a rare open-source implementation of the Google Zanzibar authorization model that goes beyond a toy demo: it implements real tupleset traversal, userset rewrites, and Zanzibar-style consistency tokens, while also folding in an ABAC policy layer with time-bound conditional grants and exposing a decision path for every check so developers can see exactly why access was granted or denied. That combination — unifying RBAC, ABAC, and ReBAC behind one engine with built-in explainability — differentiates it from simpler policy libraries that only handle one authorization paradigm at a time.

Self-Hosting

Licensing Model

Warrant is licensed entirely under Apache License 2.0, a permissive open-source license with no dual-licensing or source-available carve-outs. A repository-wide search for common license-gating patterns (license_check, requiresLicense, isPro, isEnterprise, enterprise, cloud only, paywall) returned zero matches — there is no enterprise tier, feature flag, or gated code path anywhere in the codebase.

Self-Hosting Restrictions

There are no license-level restrictions on self-hosting. Anyone can clone, build, and deploy the full feature set under the Apache-2.0 grant. The one caveat is architectural rather than licensing: the project’s own README states this open-source version is best suited to proof-of-concepts, development/test environments, and low-to-moderate throughput production use, since achieving low-latency access checks at high scale requires operating Warrant as a distributed service using its consistency-token mechanism — a deployment pattern the OSS repo doesn’t fully productionize on its own.

Enterprise Features

None are gated behind a paid tier in this repository. Every capability described in the documentation — RBAC/ABAC/ReBAC, multi-tenant primitives, pricing-tier feature gating, audit-friendly decision paths — ships in the open-source build.

Cloud vs Self-Hosted

Warrant (the company) was acquired by WorkOS, and the README now points prominently to WorkOS FGA as the hosted, horizontally-scaled successor product, with the open-source repository positioned as the self-hostable core rather than a feature-limited version of the hosted offering. The NOTICE file confirms WorkOS, Inc. as the current copyright holder, and the repository is not archived — it continues to receive commits (most recently in late 2025) under WorkOS’s stewardship, though at a noticeably slower pace than during Warrant’s independent, venture-backed period.

License Key Required

No. No API key, license key, or account is required to build or run the open-source server; it only requires you to configure an internal API key used to authenticate requests to your own self-hosted instance.