Documentation embedded in this build.

AuthBox next to a service mesh, an identity provider and an ingress controller

Everybody asks this, usually in the first half hour: how is this different from what we already run? The honest answer is four different answers, because the three things people mean by "what we already run" solve three different problems, and none of them is quite this one.

This page is written under three rules, and it is fairer to state them than to let you work them out.

The other product gets described first, in its own terms. A comparison that beats up a straw man is worth less than no comparison at all, and you probably know these products better than we do. Each section says what the thing is for and where it is the better tool, before it says anything else.

There are no performance claims anywhere on this page. Not "faster", not "lower overhead", not "negligible". This repository has deliberately not measured AuthBox's request rate or latency yet, and the rule the whole site is written under is that a claim without a test is not made. When those numbers are measured they will be published as a committed baseline with the same load run through another proxy for a ratio rather than an opinion. Until then the gap here is a gap on purpose; please do not fill it with a guess in either direction.

The comparison is on what each one can prove afterwards. That is the axis that is actually different, and it is the one that survives contact with an auditor, an incident review or a customer's questionnaire. Everything else — where the process runs, what the configuration looks like — is a detail by comparison.

One thing to define before the four sections, because the whole axis rests on it. A receipt here is a signed record of one decision: who was asking, what they asked for, what was decided, and which rule decided it. It is signed by the thing that decided, it travels with the request, and anyone holding the public key can check it later without asking AuthBox anything at all — with AuthBox switched off, in fact. "What it can prove afterwards" means: what evidence is left over, once the request is long finished.

A door, used below, is the AuthBox process that stands in a request's path, checks the caller's certificate and decides whether the request goes on. Its own page is Who decides, and where AuthBox goes.

A service mesh

By this category we mean Istio, Linkerd, Consul Connect and the like — usually with Envoy as the thing actually handling the traffic.

What it is for

A mesh solves a problem that is genuinely hard and genuinely not ours: making every hop between your own services mutually authenticated and encrypted, without asking the teams who wrote those services to do anything. It issues a short-lived identity to every workload, rotates it automatically, puts a proxy beside each one, and gives the platform team retries, timeouts, traffic splitting and a uniform view of service-to-service traffic. The workload identity model behind most of this — SPIFFE — is a good one, and the fact that the application developers do not have to participate is the whole point.

Where it is the better tool: if what you need is transparent mutual TLS between hundreds of internal services, with automatic rotation and no application changes, run a mesh. AuthBox does not do that and is not trying to. It will not wrap your service-to-service traffic for you.

What it does that AuthBox does not

Every hop, transparently, with no participation from the workload. Per-workload identity issued and rotated by the platform. Traffic management — retries, circuit breaking, splitting, mirroring — which AuthBox has none of. Federated workload identity across trust domains: AuthBox is compatible with SPIFFE-style identifiers but holds a single resolver, and per-route admission of a federated trust domain is not shipped.

What AuthBox does that it does not

A mesh answers which workload called. That is a real fact and a useful one, and it is not the fact most compliance questions are about. It cannot tell you which person was behind that call, what they were cleared for, or which rule allowed it, because by the time the request reaches the second service the person is several hops upstream and the mesh's own credential says nothing about them.

AuthBox decides whether a named person or organisation may reach a particular route, against a signed dataset it can verify with the network down, and hands back a receipt for that decision. Afterwards, a mesh can prove two workloads were authenticated to each other. AuthBox can prove that this person, holding this standing, was allowed this thing by this rule at this moment, to somebody who does not trust either of us.

The second difference is about what travels. AuthBox never lets its own answers travel as claims: what an application receives is an identity and a decision it can verify, not a bag of assertions it must take on faith.

When you would run both

Frequently, and they compose cleanly, because they are answering different questions at different boundaries. The mesh does what it is good at inside the cluster. The AuthBox door sits at the boundary where a person or another organisation arrives, decides whether that caller may have this route, and emits the receipt. The mesh proves which workload; AuthBox proves who was behind it; only one of the two produces evidence a third party can check.

If you already run Envoy — under Istio or on its own — there is a designed integration in which AuthBox answers Envoy's external authorization call, so the decision and its receipt come from the same engine rather than from a second evaluator you would then have to keep in step. It is designed and recorded, waiting for a deployment that wants it, and it is not shipped today; the honest position is that it is a plan rather than a feature.

An identity provider

By this category we mean Okta, Microsoft Entra ID, Ping and Keycloak — the thing your people sign in to.

What it is for

An identity provider is the front of your organisation's login. It holds the accounts, runs the sign-in, does multi-factor, and federates the several hundred applications you have already bought so that people have one password instead of three hundred. That catalogue of ready-made application integrations is a genuine asset built over years, and it is the reason replacing an identity provider is usually a bad idea.

Where it is the better tool: signing people in to software you did not write. If the question is "how do our people get into the expenses system", the answer is your identity provider, and AuthBox is not a candidate. This repository has also deliberately not chased identity-provider feature breadth — self-service password reset, lifecycle workflows, a thousand-application catalogue — and says so rather than pretending the gap is a design choice about focus alone. It is both.

What it does that AuthBox does not

The catalogue. Password-based sign-in and its whole surrounding apparatus. Being the place your workforce accounts live. AuthBox also does not consume somebody else's login as proof of identity: it will not sit behind your corporate identity provider and accept its assertion as authentication. Identity here begins with a certificate.

What AuthBox does that it does not

Start with the confusing part: AuthBox is an identity provider too, for two protocols. It speaks OpenID Connect, and it signs SAML assertions for applications that can do neither mutual TLS nor OpenID Connect. So the difference is not that one of us speaks these protocols. See Login with AuthBox and Login with AuthBox, for an application that speaks SAML.

The difference is what happens after the login. An identity provider answers who is this once, at the start of a session, and then stops: the token it issued is good for its lifetime, and what you do with it afterwards is between you and the application. AuthBox keeps deciding, per request, for as long as the caller keeps asking — and the thing it decides against is a signed dataset with the organisation's rules in it, not a token minted an hour ago.

And one rule that is easy to miss and matters more than it sounds: what AuthBox decides never travels as a claim. What is already in the subject's own name may go into a token or an assertion; the engine's answers may not. An application that receives an AuthBox token learns who the person is, and must still ask — or verify a receipt — to learn what they may do. This is deliberate, because a decision that travels as a claim is a decision that keeps being true after it has stopped being true.

Afterwards: an identity provider can prove somebody signed in, once, and usually how. It cannot prove what they then did or which rule permitted it. AuthBox can produce, for any individual request, the decision and the clause behind it.

When you would run both

This is the normal case, and the split is clean. Your identity provider stays the front of your workforce login and keeps its catalogue. AuthBox decides access to the things where per-request authorization, classification levels or evidence actually matter, and where the facts your identity provider holds are needed they arrive as signed statements from their owner rather than as a live token AuthBox has to trust at request time. Nobody rips anything out.

An ingress controller

By this category we mean the NGINX ingress controller, Traefik, HAProxy and Envoy Gateway — the thing that terminates TLS at the edge of your cluster and routes by host and path.

What it is for

Getting traffic from outside into the cluster, to the right service, reliably. Terminating TLS, obtaining and renewing the certificates, matching on host and path, rewriting, splitting traffic between versions, rate limiting, and doing it through an annotation or a custom resource that fits the rest of your Kubernetes configuration. It is mature infrastructure with a large plugin ecosystem, and people have been running it for years.

Where it is the better tool: traffic shaping and the breadth of the edge feature surface. Canary releases, mirroring, request rewriting, the module you already depend on — AuthBox's door does not chase any of that and will not grow it on request.

What it does that AuthBox does not

All of the above. Also the thing a large ecosystem gives you for free: somebody has already solved your odd case and written it down.

What AuthBox does that it does not

This is the closest of the four in shape — both sit at the edge and route by name — and the furthest in purpose.

An ingress controller forwards. Where it does authenticate, it usually does so by calling something else and then forwarding the answer as a header, which is exactly the shape where a decision and its evidence come apart. Afterwards, an ingress controller can prove almost nothing: there is an access log saying a request arrived and a status code went back, which is a record of traffic and not of a decision.

In AuthBox the routing decision and the authorization decision are the same decision, taken against a dataset that was signed somewhere else and can be verified with the network down, with no call to any other service at request time. A route that does not admit you is not a route you were refused at; it is a route that did not match. And the request that was allowed leaves a receipt.

It also decides things an ingress controller has no concept of. Responses carry a classification label and are refused to a caller not cleared for them — see Marked data — and the same decision is taken per frame on a long-lived stream rather than once at the start. That is a large part of why this proxy is its own program and not a plugin: those behaviours do not fit inside a "call out and get yes or no" hook, which is the shape every edge product offers.

When you would run both

Often, and the order matters: ingress first for what it is good at, then the AuthBox door in front of the applications whose access has to be decided and evidenced. Or the other way round, if the door is your outer edge. AuthBox can also run as a Kubernetes ingress itself, discovering what it fronts from an annotation on a Service; Who decides, and where AuthBox goes works that shape through.

A policy engine, or a decision point

By this category we mean Open Policy Agent, Cedar and AWS Verified Permissions, and the relationship-based engines in the Zanzibar family such as OpenFGA and SpiceDB.

What it is for

Taking the authorization rules out of the application and putting them somewhere they can be written, reviewed, versioned and tested on their own. The application asks "may this subject do this to this resource", something else answers, and the rules stop being scattered through handlers written by people who did not know there was a decision to make. The relationship-based engines solve a different shape of the same problem — permission that follows from who owns, shares or is a member of what, at a scale where listing it would be hopeless.

Where it is the better tool: rich in-application authorization. If your question is which fields of a document this user may edit, or whose shared folder this file is in, that is what these engines are for and AuthBox does not model it.

What it does that AuthBox does not

Expressive, general-purpose rule languages, and a relationship graph AuthBox has no equivalent of. This repository's position on relationship-based access control is written down and has not moved: a different model for a different problem, interoperated with, never replaced.

What AuthBox does that it does not

The honest answer here is that AuthBox interoperates rather than competes, and it does so in a specific way rather than in principle. It exports its own requirements as both Rego and Cedar, so the rules it enforces can be run by the engine you already have and compared against what AuthBox itself does. And it answers the standard authorization API, so an application that already asks a decision point can ask this one.

What it adds is at the other end. A policy engine answers the question you ask it; it does not stand in the path, does not hold the identity the question was about, and does not produce evidence about the request that a third party can check later. AuthBox is the enforcement point, the identity source and the evidence producer at once, and it is that combination — not the rule language — that is the product.

When you would run both

Whenever the application's internal authorization is genuinely rich. Let the engine decide inside the application; let AuthBox decide at the boundary, with its per-request receipt, and export its own rules into your engine so that the two are provably saying the same thing rather than separately hoping.

The short version

Nothing in that table is a criticism of the first four rows. Each is proving the thing it was built to prove. The point of the table is that if what you need is the last row, none of the first four gets you there, and running all of them does not add up to it either.

Read on

• Who decides, and where AuthBox goes — where the doors go, and who is allowed to write the rules they enforce.
• How policy and missions fit together — what a rule looks like.
• Marked data — deciding the response, not just the request.
• Logging in to a machine — the same "decide, then prove it" idea applied to SSH, and a plain statement of what this is not: a certificate authority for SSH, not a bastion, a jump host or a session recorder.
• Integrations and protocols — everything this deployment speaks, in one generated list.