Issuerd: a Keycloak-compatible IAM in Rust — one binary, 3,907 OIDC conformance checks, zero failures

If you've operated Keycloak in production, you know the tax: a JVM that wants gigabytes before it serves a single login, container startup measured in tens of seconds, and clustering that means Infinispan whether you like it or not. It's a great IAM — arguably the de-facto open-source standard — but the operational profile is the price you pay on every deploy.

For the past three months I've been building issuerd: an identity and access management server that keeps the Keycloak model — realms, clients, roles, client scopes, protocol mappers, authentication flows, Admin REST API — and drops the operational tax. It's written in Rust, ships as one self-contained binary (the admin console, account console, and login pages are embedded), and it's open source under Apache-2.0.

This is the launch post. I'll try to lead with proof rather than promises.

Proof point 1: conformance, measured by the official suite

Anyone can claim "OIDC compliant". issuerd runs the official OpenID Foundation Conformance Suite (release v5.2.4) in CI, the way it's meant to be run:

• 3,907 conditions verified across the Basic OP, Form Post OP, and Config OP profiles — zero failures, zero warnings.
• The suite runs pristine (unpatched JAR built in-docker from the pinned tag) in a hermetic TLS environment: isolated network, own root CA, no internet.
• Per-module results are checked into the repo, and the full evidence bundle is attached to every release.

The discovery document advertises exactly what is implemented and tested — nothing more. If issuerd doesn't do something, it says so instead of failing creatively at runtime.

Proof point 2: Keycloak compatibility as a test target, not a slogan

"Compatible" is easy to write in a README. issuerd treats a live Keycloak 24.0 container as a test oracle: a dual-target suite runs the same protocol assertions against issuerd and Keycloak — JSON shapes, Admin API responses, error behavior — and every deliberate difference is documented. Existing OIDC clients and Keycloak-hardened operational knowledge transfer directly.

To be clear: issuerd is not a rewrite or a fork. It's an independent implementation that uses Keycloak as the reference baseline.

Proof point 3: the operational numbers

• Up to 7.8× throughput, ~6× less memory, 8.7× smaller image vs Keycloak 26.7 in our benchmarks (methodology and the k6 stack are in docs/PERFORMANCE.md — reproducible, not a slide).
• 100,003 users synced from a live Active Directory in ~30 seconds (~3,300 users/s), with group-membership reconciliation.
• Access-token validation is stateless — no database lookup on the hot path. Signing keys are shared cluster-wide through PostgreSQL, transient coordination state lives in Redis. No sticky sessions: any number of nodes behind any load balancer.

The engineering under it

• ~152k lines of Rust across a workspace of 9 library crates + 1 binary — ~131k of it in the crates, ~20k in tests — with a strictly acyclic dependency graph. Each crate compiles independently.
• #![forbid(unsafe_code)] everywhere — zero unsafe by construction.
• Typestate markers make invalid authentication-state transitions fail at compile time, not at runtime.
• 3,300+ automated tests; every public function is testable without network or database.

Built for the agent era

AI agents acting on behalf of users break the assumptions bearer tokens were designed around. issuerd already ships the three standards the industry has converged on:

• DPoP (RFC 9449) — access tokens cryptographically bound to their holder's key; a stolen token is scrap metal.
• RFC 8693 token exchange — each tool call mints a fresh, audience-narrowed, scope-attenuated token. Scope can only ever shrink across an exchange.
• CIBA (poll mode) — human-in-the-loop step-up approval for dangerous actions, with a binding message.

There's a runnable end-to-end demo in the repo (examples/agentic-mcp/): a scripted chat agent → MCP server → PostgreSQL row-level security, including the attacks (prompt injection, stolen-token replay, unapproved refund) and the refusals.

Honest scope

This is v0.1. What's deliberately not in scope today: SAML, UMA, FGAP, Organizations. If you need those, Keycloak is the right answer today, and I'd rather say that here than in a GitHub issue six weeks from now.

What is in scope: SSO, MFA and passkeys, user federation (LDAP / Kerberos / SPNEGO against Samba AD, OpenLDAP, MS AD), social login and OIDC identity brokering, themable login pages, per-realm i18n with localized emails, declarative YAML provisioning, one-command OpenAPI export, Prometheus metrics, health/readiness probes, TLS.

Try it

git clone https://github.com/issuerd/issuerd && cd issuerd
docker compose up   # pulls issuerd/issuerd:latest — no build tools needed

• Admin console: http://localhost:8080/admin/console (admin/admin)
• Demo realm myrealm: alice/changeme

Pre-built binaries (Linux x86_64/aarch64, Windows, macOS arm64) with SBOMs and the conformance-evidence bundle are on the releases page; also on Docker Hub and crates.io. Docs: issuerd.org.

What's next

OIDF certification (the open-source track — the suite already passes, it's mostly paperwork), a v0.2.0 in a few weeks, and comparison/benchmark deep-dives. If you try the quickstart and hit friction, I want to know — issues and discussions are open, and there are a few good first issue tickets if you'd like to contribute.

I'm the author. Ask me anything — including the uncomfortable questions.