fx-auth · Identity & Access

Every new application brings its own login.
It doesn't have to.

fx-auth is an authentication server you host yourself: set it up once, connect all applications. Ten login methods from password to passkey, one signed token, one permission model — and your identities stay where they are.

The problem

Login sprawl costs you three times over

Built three times over

Login, password reset, 2FA — redeveloped in every project. And with it, every time: a separate user table, separate password rules, a separate vulnerability.

Identities in four silos

Active Directory, customer database, Google accounts, machine tokens — the same person exists four times, permissions drift apart.

Retrofitting is a project

MFA, passkeys, SSO, audit evidence: what is missing today gets retrofitted expensively later — per application, again and again.

The solution

One server between your identity sources and your applications

1 · Ten ways in, one token

Password, passkey/Face ID, OIDC, NFC token, service accounts — every path ends in the same signed JWT with the same permission model.

2 · Your users stay where they are

A central login usually means: migrate all accounts. With fx-auth it means: write a plugin. AD, your own database, legacy systems — connect instead of relocate.

3 · Your API doesn't ask — it verifies

Token validation runs locally inside your application, with no round trip to the auth server. Permissions you can show in an audit: one typed triple model for everything.

Built like a product, not like a project

Substance you can count

10login methods → one signed JWT
94API endpoints, OpenAPI-documented
210automated tests on 88,000 lines of Rust
1binary — no app server, no session database

Standards instead of homegrown solutions: WebAuthn/FIDO2, OIDC, OAuth2 + PKCE, JWT ES256/RS256, Argon2, refresh token rotation with theft detection.

The Keycloak question

Powerful is good. Operable is better.

Keycloak can do almost everything — and is its own operations project in return. If your team needs a login and not an identity department, that is the wrong order of magnitude.

Typical enterprise IAM stack

  • JVM, cluster, external session database
  • Dedicated operations know-how required
  • Customization via themes and SPIs
  • Account migration on a deadline

fx-auth

  • One binary, one configuration file, memory in the MB range
  • Container, RPM or npm — from zero to signed in within minutes
  • Ready-made login UI: one HTML tag, and the login stands
  • Plugin instead of migration — your sources remain yours

Self-hosted with source code, no per-user pricing, no vendor lock-in.

Next step

How many logins do you maintain today?

Sign-in is the moment your users trust you for the first time. Let's walk through how your logins become one in an architecture call — answer within one business day.