AuthBox is the identity and authorization server for organisations that hand out access by need-to-know. A certificate says who you are; a mission says why you are here; a marking says what may leave.
It plugs into the enterprise you already run — a corporate directory over LDAP, provisioning over SCIM, single sign-on over SAML and OIDC, a certificate authority of your own — or stands up a new organisation in a box. One box runs alone or airgapped; many chain into a federation where each keeps deciding for itself. Every decision is denied by default and signed.
An identity is the (issuer, subject) pair on a certificate — nothing else. The example is fictional: O=example.
Most of what makes AuthBox trustworthy is what it declines to do, and each refusal below is pinned by a test.
Mutual TLS is the only login. A client without a certificate this deployment issued or trusts never completes the handshake.
Nothing reaches out to us — not for updates, not for revocation, not for a typeface. The only addresses it dials are ones you configured.
An operation that declares no requirement denies everybody. A mission that does not exist is refused exactly like one the caller may not know exists.
A partner's certificate can complete a handshake and still be refused at authorization. Handshake is not entitlement.
Ten deployments, each a topology this repository stands up and proves. One rule runs through all of them: a door per authority, never a door per process.
Who decides, and where the door goes →
For a service that knows nothing about certificates and cannot be changed to learn. The caller's identity arrives verified, and every request carries a receipt: a signed record of the decision that let it through.
Read the scenario →
One AuthBox in the middle, proxies and read-only replicas at the edges. Each edge decides from the bundle it holds, so an outage at the centre is not one at the door.
Read the scenario →
For a team that wants its own certificates and has no public key infrastructure. The first boot stands up the authority, and the root never leaves the host. It also asks for your own vocabulary, the companion processes you want beside it and the corporate services you connect to — with or without a browser.
Read the scenario →
Organisations that must work together and cannot merge their directories. Each keeps its own authority, and every record carries its origin.
Read the scenario →
An organisation that already has a directory, a PKI and a mail relay. AuthBox adopts what they say and owns none of it.
Read the scenario →
For a feed with two destinations cleared to different levels. The door decides on each record's label alone, and never opens one.
Read the scenario →
For an application whose records are not all for one audience. It labels every answer, and the door refuses whole what the caller is not cleared for.
Read the scenario →
For records that must stay classified after they leave you. Anybody can copy one and nobody can read it: a door holds the key.
Read the scenario →
Who may log in to which machine, and as which account, is this deployment's own policy. No key is copied anywhere.
Read the scenario →
For a web server, a test site or a mission’s API. The project owns the identity; the key is born where it is used and never handed over.
Read the scenario →The same binary on a laptop with the cable out, on one host, in compose, or across a cluster.
Read the scenario →Every capability below is in the binary today, each proven by a named test. Nothing here is a roadmap.
People, services and projects. A mission is a named job someone holds, and authorization is membership intersected with a mission intersected with attributes. A mission or a record you are not cleared for is absent rather than forbidden.
Issues, renews, rotates and revokes. A partner's root is appended to the trust pool, its data never adopted.
Snapshots published on a cadence, each with a freshness budget, and origin that survives every hop.
Every page works with JavaScript off. WCAG 2.1 AA and Section 508, checked rather than asserted.
For the people the console is not for: their own missions, requests and agreements.
Brokered through approvers, granted for a window, live only once the requester accepts with their own key.
Standing conditions — training currency, a signed MOU — reported across a group as a fleet.
Every permit and every deny in a hash-chained, countersigned log, with the clause that decided it.
Each is in the binary, switched on by a setting, and proven by a named test. What your systems send is verified before it is read; what AuthBox decides never leaves as a claim.
Your web applications log people in with the certificate they already hold. An OpenID Connect provider with PKCE and certificate-bound tokens; a SAML 2.0 identity provider for the applications that speak nothing newer. SAML, explained →
Joiners and leavers arrive from the system that already knows them: a SCIM 2.0 adapter pulling from a directory or taking a push from Okta or Entra, an LDAP connector for Active Directory. Each runs outside and produces one signed bundle, all AuthBox takes in.
Enrol servers over ACME with device attestation, or devices over EST. Revocation over OCSP and CRLs. Keys in a PKCS#11 hardware module, and post-quantum ML-DSA certificates beside the classical set.
Ask the decision as an API (OpenID AuthZEN), export the policy as Rego or Cedar for the engine you run, and let your other systems learn of revocations and lapses as shared signals (CAEP). Or take those answers in your own API's shape, from your OpenAPI document and a mapping proved at load.
Classified responses labelled per request and sealed to a key access service that releases a data key only to a caller cleared for it; NATO confidentiality labels translated at the seam rather than re-modelled.
A separate add-on that holds the files so AuthBox never does. A bucket is a mission ↓
An SSH certificate authority for your hosts and cluster nodes, SSH through the door by name, an ingress mode that follows your Kubernetes Services, and authoritative DNS with DNSSEC for a federation's names. SSH, explained →
Metrics in Prometheus form, structured logs, a signed audit export your SIEM can prove it received, a transparency log, and a store on files, PostgreSQL or MySQL.
Every setting behind these, and the test that proves each one, is in the support matrix.
An S3-compatible store that holds the files, so AuthBox never does. Its own binary and image, deployed beside the box.
A level, a project, a mission — read off the address, not out of a policy written beside it.
Author one in the portal and its storage exists, held by exactly its holders. The general shelves are seeded missions, held by everyone this authority holds.
An object at a sealed level is ciphertext, opened by the key access door only for a holder of that mission. A copied volume opens for nobody.
Mutual TLS only, no presigned links, one bound per object — and the store never writes a mission.
Filing a file → How a sealed file travels →
Each is the better tool for the job it was built for, and this replaces none of them. The difference is the axis above: what can be proved afterwards, by somebody who was not there.
How it compares, one by one →AuthBox is built for the people who sign the authorization to operate. Every normative decision is a numbered ruling in a register with the test that enforces it, so a rule refactored away fails the build.
In the FIPS build: Go's native FIPS module, CMVP certificate #5247, under fips140=only. Non-approved algorithms cannot be selected.
Numbered requirements, each enforced by a named test; 805 declared mutations, applied by the gate to prove they bite.
By default, everywhere. An undeclared operation denies everybody, so nothing is permitted by omission.
The control catalogue as a component for a FedRAMP-shaped system security plan.
The evidence register, capability by capability →
Everything a deployment changes is data →
The FIPS build is the default: its mode is compiled in, and the process refuses to start under any other. The open build is the same product without that claim; the operator guide's two postures page says which to take.
A release says how it was built, and the media verifies itself. A signed in-toto statement carrying SLSA Provenance v1 rides with the artifacts, sealed by one offline key, and the verifier on the media checks it offline.
Nothing is fetched while it builds, and every piece of somebody else's code carries its licence and a reason in a register the gate checks.
One command brings up the reference deployment and walks it with a live smoke, on a laptop with no network. Start at apps.<your domain>: the front door's directory.
Production ships as a static binary, or as systemd, compose and Kubernetes manifests. An airgapped install copies it in by hand — which is the point.
AuthBox