Frauthy

Put the two halves side by side and the gap is obvious: OIDC ends with a verified subject; the ReBAC store begins with a relationship. Nothing standard connects them — and the connection must hold across databases and services that don't trust each other by default.

The database

Row-level securityDatabaseEnforcing access per row inside the database via SQL policies. Clean for one service; it can't express or share relationships that span services. pushes authorization into the database — elegant for one service, a trap for many. The policy now lives in SQL, against columns, invisible to other services, unable to reason about a relationship that spans systems ("can edit because they manage the owner's team"). Two services on two databases can't share a row-level policy; they re-derive it, differently.

Microservices & token exchange

A request crosses five services. The token was minted for the first. By the third you're deep in OAuth's harder machinery — token exchangeOAuth · RFC 8693Swapping one token for another scoped to the next service, so identity can travel inward across microservices without over-granting., audience restriction, on-behalf-of flows — just to carry identity inward without over-granting. Each hop must independently turn "this token" into "this permission," and each hop is a place the mapping drifts.

The glue tax

So every team writes the same layer: claims → relationships, a Check helper per language, sync jobs to keep the store current, and — almost always — no tracing across the authn/authz boundary, so a denied request is a mystery. Swap the identity provider and the layer is rewritten. Add a language and it's ported. Switch SpiceDB for Keto and it's redone. This is the recurring cost Frauthy deletes.

// per service, per language — brittle and untraced
async function authorize(req) {
  const claims = await verifyJwt(req.token)        // authn — ok
  const orgId  = lookupOrgForEmail(claims.email)    // bespoke mapping
  await spicedb.write(`org:${orgId}#member@user:${claims.sub}`) // hope it's fresh
  const ok = await spicedb.check(`doc:${req.id}#view@user:${claims.sub}`)
  if (!ok) throw new Forbidden()              // why? no trace. good luck.
}

Frauthy is a single, stable contract over the whole stack. Your app talks to one interface — identity · permission — and Frauthy owns everything underneath: which authn implementation issues the identity, how that identity becomes a relationship, which Zanzibar store resolves the Check, and how every step is traced. You write the app-layer path once. The implementation is swappable beneath it.

$ frauthy init --provider betterauth --store spicedb

  ✓ provider wired (OIDC discovery + token verification)
  ✓ store provisioned (schema applied, ZedToken consistency on)
  ✓ claim → relationship mapping generated
  ✓ SDKs emitted · TS · Rust · Go · Python
  ✓ tracing exported to OTLP

# everything below is now one call at the app layer:
await frauthy.can("access", portal)   // → true / false, fully traced

Underneath that one call, a request runs a fixed lifecycle — the violet half is authentication, the coral half is authorization, and Frauthy owns the handoff between them — the work that Where delegation breaks left to you:

Discoverability — the marketplace

An auth setup that's swappable and standardized is also shareable. Frauthy publishes configurations, schemas and identity domains to an auth marketplace, so a working setup can be discovered and adopted rather than rebuilt. Every listing carries one of four visibility tiers:

Those tiers aren't just labels — each is a different way the same listing#discover permission resolves through Frauthy's own ReBAC graph. The diagram reads as object → rule → who it admits:

The payoff lands here: because the app layer is fixed and the implementation is swappable, a listing can change what runs underneath — a different issuer, an added domain, a revised schema, even SpiceDB for Keto — and every adopter inherits it without touching their code.