Who are you, and what are you doing here?

There is a question that every computer system must ask, millions of times a day, to every user, every application, every service trying to access a resource.

Who are you? And what are you allowed to do here?

A deceptively simple question. But behind it lies an entire discipline, one that underpins the security, scalability, and reliability of almost every modern application: Identity & Access Management, or IAM.

The problem, put simply

Picture a large company. Hundreds of employees. Dozens of applications — accounting, HR, CRM, dev tooling, production servers. Every morning, people log in. Every evening, they log out. In between, they access data, trigger processes, read documents.

Now, a few simple questions:

How do you make sure the accountant can’t access the production servers?
How do you ensure a developer who leaves the company instantly loses all their access?
How do you let an external partner reach one API without touching anything else?
How do you know, six months later, who changed what and when?

The naive answer doesn't scale

Without a dedicated system, the answer to each of these questions is a patchwork of scripts, user tables duplicated across every app, passwords shared in Slack, and sleepless nights before security audits.

IAM is the structured answer to that chaos.

What an IAM system actually does

An IAM system is the centralized gatekeeper of your infrastructure. It plays several roles at once.

Why it’s hard to get right

IAM sounds simple. It’s just a users table with a password_hash, right?

It's never just a users table

Managing identities seriously means dealing with dozens of problems that stack up fast: secret rotation, token revocation, session expiration, service accounts, multi-tenancy, MFA strategies, webhooks, tamper-proof audit logs…

And all of this has to hold under load. An IAM is a mandatory chokepoint — every authenticated request goes through it. If it’s slow or goes down, your entire infrastructure stops.

That’s why large enterprises pay fortunes for solutions like Okta, Auth0, or Azure AD. On the open source side, Keycloak has been around for a long time and does the job, but it carries significant configuration complexity and a JVM footprint that doesn’t suit everyone.

FerrisKey doesn’t claim to be the definitive solution. It’s an alternative, with different trade-offs: Rust instead of Java, a hexagonal architecture designed for clarity and maintainability, and an ambition to stay simple to operate.

Welcome to FerrisKey

FerrisKey is an open source IAM system, built in Rust, with a hexagonal architecture.

Why Rust?

Performance and reliability are non-negotiable for a component this critical. Rust delivers C-level speed without the pitfalls — no garbage collector, no data races, no memory surprises. For a service handling millions of authentications, that’s exactly what you want.

The hexagonal architecture ensures that business logic stays pure and decoupled from infrastructure. The database can change, the HTTP framework can evolve — the domain core stays stable and testable.

What a decoded OIDC ID token looks like when FerrisKey issues it:

{
  "sub": "user_01HZ93BKGZ7Y3QPFMJ4E5RW0X",
  "iss": "https://auth.example.com/realms/acme",
  "aud": "my-app",
  "exp": 1718100000,
  "iat": 1718096400,
  "email": "alice@example.com",
  "realm_access": {
    "roles": ["developer", "read:billing"]
  }
}

In practice, FerrisKey gives you:

Realms

Fully isolated spaces. Each organization, project, or environment gets its own realm — its own users, roles, and clients. No cross-contamination possible.

OAuth2 & OIDC

The web’s standards, implemented correctly, so your apps can delegate authentication without friction.

Trident — MFA

FerrisKey’s MFA module: TOTP, WebAuthn (hardware keys, passkeys), magic links, and recovery codes.

SeaWatch — Audit

A complete audit system, queryable from the console, tracing every security event across your realms.

Webhooks

Connect FerrisKey to your existing systems and react to lifecycle events — user creation, access revocation, and more.

Cloud-native

An official Helm chart, Kubernetes Operator, and Docker Compose support for frictionless deployment at any scale.

Apache 2.0 — fully open

No paywall. No “enterprise” tier hiding critical features behind a contact form. The code is open, the community is here.

Who is it for?

SaaS teams

Building a platform and want robust auth without starting from scratch — or paying per monthly active user.

Platform engineers

Looking to centralize identity management across services without depending on a proprietary vendor.

Curious developers

Who want to understand how IAM really works by reading clean, well-structured Rust code.

FerrisKey is not Okta yet. But it is serious, actively developed, and built on the right foundations to get there.

What’s next

In upcoming posts, we’ll go deeper: how OAuth2 and OIDC work under the hood, how to model permissions with a role system, how to deploy FerrisKey on Kubernetes, and much more.

Try it out

The repo is on GitHub. Star it, clone it, run it locally.

Read the docs

Everything you need to get started is at docs.ferriskey.io.

Join the community

Discussions are open on GitHub. Contributions, bug reports, and ideas are all welcome.

IAM is a problem that has been solved a thousand times, in a thousand proprietary silos. It was time to solve it properly, once, in the open.

That’s what FerrisKey is here to do.