Arbax

Arbax is a sign-in and permissions service that you run yourself: one account per person across all your apps, one place to decide who may do what, and your users on servers you control.

What it is

Arbax is a backend service for identity and authority. It holds the people, their login methods, their roles and the signing keys, and it issues the tokens every app trusts. It ships as one binary with its database built in, Residiuum, so there is one process to run and no separate database server to operate.

It serves any number of constellations from one deployment. A constellation is a family of apps that share their people: a shop, a customer app and a back office, for example. Each has its own users, roles, signing keys, sign-in site and mail, stored separately, and nothing crosses between them. The same email address in two constellations is two different people.

Your sign-in pages are your own. Arbax has no screens for customers to see: a login app you design talks to its API, carrying your name and your look.

What it does

Signing people in

• Passwords, stored with Argon2.
• Sign-in links by email, and registration by a six-digit emailed code.
• Google sign-in, under strict rules for linking it to an account.
• Authenticator-app second factors, with ten one-time recovery codes.
• Password reset, email verification and email change.
• Registration that is open, by invitation only, or closed, set per constellation.
• Every token states how its session was authenticated, so an app can ask for a stronger sign-in when it matters.

One account across apps

• A person signs in once, and every app in the constellation trusts that sign-in.
• The login app holds the session, and hands a person to another app with a one-time code that names who may redeem it, is spent once, and lives 60 seconds.
• Duplicate accounts merge into one: everything moves in a single write, and the old id resolves to the survivor for good.

Mobile apps

• A mobile app holds no secret. It proves itself with a one-time verifier (PKCE).
• Its session lives on the device and rotates every time it renews.
• If a rotated session is used again, Arbax sees two holders of one session and ends it for both.

Deciding who may do what

• Permissions are named namespace.resource.action, and each constellation catalogues its own.
• Roles group permissions, and bindings give roles to people and services. That is the only way authority is granted, and nobody can grant a permission they do not hold.
• Services such as a login app or an app's backend authenticate with API keys that can be rotated and revoked.
• Authority removed takes effect on the next request to Arbax, and within five minutes everywhere.

How apps verify

• Tokens are JWTs signed with each constellation's own Ed25519 key, and live five minutes.
• An app verifies a token itself, with two public documents: the signing keys and a signed role catalogue. It holds no secret and does not call Arbax on the request path.
• Any language with Ed25519 can do this. A typed Rust client and HTTP contract are included.
• Signing keys rotate without invalidating what they signed.

Running it

• Every decision is written to an audit log before it takes effect, and every operator action is tied to the certificate that made it.
• Administration is over mutual TLS only, with client certificates, on an interface never published to the internet. An operator console is included.
• The server runs sealed: its unseal key is never on the host, and everything needed to serve is.
• Each constellation has hourly ceilings on the mail it sends and the accounts it creates, so a flood of fake sign-ups stops at a limit you set.
• Mail is composed by Arbax and sent through Iris. Each constellation names itself and its own sender, and every message says which service and which account it is about.
• Readiness proves the store can read and decide atomic writes, not just that the process is up.
• Backups prove themselves: each dump is restored and its content hashes compared.
• One script installs a fresh host and adds constellations, and a constellation moves between deployments with its users, API keys and signing keys intact.

Why it matters

Sign-in is the first thing every customer touches and the door to everything they have with you. Most companies end up with one of two arrangements:

• Each product has its own sign-in. The same customer has several accounts and passwords, the same security work is done again for each app, and removing someone means finding every system they touched.
• Identity is rented from a provider. The customer list lives on someone else's servers, and the cost usually grows with every customer.

Arbax gives you the one account and the one place for access decisions, and the customer list stays yours. Because apps verify tokens themselves, sign-in does not become a bottleneck, and an app that is compromised holds nothing that can forge a token.

How it compares

In numbers

Measured in one run on a workstation, through the real HTTP API, at eight concurrent writes:

And in the product:

What it is built on

• Language: Rust.
• Storage: Residiuum, embedded in the process, Frogfish's own document engine.
• Mail: Iris, Frogfish's transactional mail service.
• Web sign-in: Crisptastic sites have a built-in login capability written for Arbax.
• Licence: official binaries are licensed by Frogfish LLC under the Frogfish Binary License 1.0.