# Rauthy: A Rust SSO Provider for OIDC, OAuth 2, PAM and Passkeys

> Rauthy is a Rust-based identity provider for teams that need OpenID Connect, OAuth 2, PAM and passwordless login with a small operational footprint. Its embedded Hiqlite database and optional Postgres mode make deployment choices explicit, while passkey requirements and client compatibility need checking before adoption.

**sebadob/rauthy** — Single Sign-On Identity & Access Management via OpenID Connect, OAuth 2, PAM

- Repository: https://github.com/sebadob/rauthy
- Website: https://sebadob.github.io/rauthy/
- Stars: 1,396 · Forks: 150
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/sebadob-rauthy

## Rauthy identity provider scope and deployment audience

Rauthy addresses the operational problem of running a centralized identity and access layer for applications, services, CLI tools and devices. Its documented protocols are OpenID Connect, OAuth 2 and PAM. The repository describes it as a Single Sign-On Identity & Access Management provider, with additional support for FIDO 2 and WebAuthn passkeys, MFA, events, auditing, client branding and an administrative interface. This makes it relevant to platform teams, homelab operators, small infrastructure groups and organizations that want to control authentication services directly instead of depending on a hosted identity provider.

The intended workload is broader than ordinary web login. Rauthy explicitly mentions IoT and headless CLI use cases, and it includes PAM support. The README says users can manage account values, passwords and passkeys through an account dashboard, while administrators can use the Admin UI for operations across the application and its users. The README does not document a complete application integration catalog, so the exact suitability for a particular service must be established against that service's OIDC or OAuth 2 requirements.

Rauthy is written in Rust, and the project says this choice supports memory efficiency, security and speed. Its documented resource figures are deployment-dependent rather than universal: approximately 40 MB for a single Hiqlite instance, approximately 65 MB for a Hiqlite high-availability cluster and approximately 35 MB for a Postgres-based setup. SwaggerUI and the embedded IPGeo DB can consume considerably more idle memory. Those figures describe resource orientation, not a guarantee for every installation.

## Rauthy persistence, caching and authentication flow

Rauthy has two documented database choices. The default is embedded Hiqlite, which provides persistence without requiring an external database. Postgres is available as an alternative when an existing instance is already part of the deployment. The repository also states that Rauthy relies heavily on caching across the authentication chain, with many cached values retained for several hours and special handling for eviction and invalidation. This design favors small deployments and headless systems, but it also means cache behavior and persistence configuration belong in capacity and recovery planning.

For OIDC clients, the README identifies defaults that can affect compatibility. A newly created client uses `ed25519` for token signing and the S256 PKCE flow. Both are documented choices rather than universal requirements. The README says older clients may not support them and can be configured accordingly. A client can therefore support OpenID Connect yet still fail against Rauthy's default signing or proof-key settings.

Passkey login has two documented paths. In the first, a user authenticates with a username and password on a new client, receives an encrypted cookie, and can subsequently log in without a password using a registered FIDO compliant passkey. The second is a passkey-only account. The user enters an email address and authenticates with a passkey, without having a password. This mode is restricted to passkeys capable of User Verification, or UV, because the README says the account must retain at least two-factor security. Discoverable credentials, which occupy a storage slot on the device, are optional because they can brick some older hardware keys. That choice needs to be presented during registration rather than hidden behind a global setting.

## Rauthy installation and first local environment

The repository provides a development setup recipe in `justfile`. It installs frontend dependencies, installs `wasm-pack`, `mdbook` and `mdbook-admonish`, builds WebAssembly modules and fetches the FIDO MDS dataset. The recipe assumes `npm`, Cargo tooling and the repository's `just` tasks are available. The `justfile` describes `setup` as the command for a fresh clone.

The `setup` recipe starts by installing frontend packages and the supporting Rust documentation and WebAssembly tools.

For local backend dependencies, the `justfile` defines a task that starts MailCrab and Postgres containers. It does not define the complete application launch sequence, so a reader should consult the Rauthy documentation for the remaining local startup commands rather than infer them.

The container image gives a separate deployment path. Its base is `gcr.io/distroless/cc-debian12:nonroot`, it copies the compiled Rauthy binary, sets `ENTRYPOINT` to `/app/rauthy`, and provides `serve` as the default command:

```dockerfile
ENTRYPOINT ["/app/rauthy"]
CMD ["serve"]
```

That image is built around the compiled binary and `config-local-test.toml`. Production deployment still requires the relevant configuration, persistence, TLS material and secrets. The README does not present a complete production deployment sequence in this section.

## Rauthy administration, observability and protection controls

The Admin UI is the central control surface for users, clients, blacklisting and other administrative operations. The account dashboard provides a user-facing area for self-service values, passwords and passkeys. Client branding is available at the login page, including per-client colors, logos and browser favicons. The default `rauthy` client supplies the theme and logo used for the Account and Admin pages according to the README.

Rauthy includes event and alerting functions. Events can be delivered by email, Matrix or Slack, with delivery depending on severity and configured levels. Administrators can view events in the Admin UI in real time, and the event stream can be subscribed so an external system can handle events according to its own logic. This can support account and incident workflows, but the README does not specify event schemas, delivery guarantees or retry behavior.

The login endpoint includes brute-force, credential-stuffing and basic denial-of-service protections. After enough invalid logins, Rauthy adds an artificial delay and automatically blacklists addresses that exceed the configured threshold. Blacklist entries expire automatically, and administrators can also add addresses manually. Geolocation blocking can use a custom header supplied by a CDN or a Maxmind database configured in Rauthy. These controls add operational dependencies. A custom header is only useful if the trusted upstream supplies it, while Maxmind configuration introduces an account, database download and data availability considerations.

## Rauthy HA mode, security defaults and upgrade considerations

High availability is supported with external dependencies, and the README says a Hiqlite cluster includes its own embedded HA cache and persistence layer. Postgres-based high availability is also possible. Rauthy therefore supports two different operational models: a small embedded deployment and a deployment tied to an external relational database. The choice affects backups, node coordination, failure handling and upgrade procedures, although the README does not document those procedures in detail.

The security defaults are intentionally restrictive. New OIDC clients default to `ed25519` and S256 PKCE. Passkey-only accounts require UV-capable credentials. The README records an independent security audit by Radically Open Security as part of NGI Zero Core funding. Findings were addressed in `v0.32.1`, and the README links to the full report. That audit is useful context, but it does not replace reviewing the current configuration and release notes for the version being deployed.

Repository activity is current. The last push was on 2026-10-15, and recent releases include `v0.37.1` on 2026-10-07 and `v0.37.0` on 2026-10-03. The repository is not archived. The Apache-2.0 license permits use and modification under its terms, but operators must review the license text and their own compliance obligations. Upgrade planning should include database format or migration changes, client algorithm settings, passkey compatibility and changes to configuration variables. The repository contains `migrations/`, `CHANGELOG.md`, `env_vars_migration.md` and `config.toml`, but the README does not specify the exact upgrade sequence.

## Rauthy limitations and alternative identity-provider approaches

Rauthy is a poor fit when a deployment needs a fully documented turnkey migration from a large existing identity system. Its defaults can also be too strict for legacy clients. The README explicitly says that `ed25519` and S256 PKCE will not work with clients lacking support for those choices. A second constraint is the passkey-only flow, which is limited to credentials that provide UV. Older hardware keys may also fail when discoverable credentials are enabled, which is why that behavior is opt-in.

The embedded database is a convenience, not a universal replacement for every database operating model. Operators who require a managed relational database, existing database backup procedures or a particular deployment integration can use Postgres instead. Choosing Postgres does not remove the need to configure the identity provider, clients, TLS, keys and event handling.

A real alternative approach is to use a larger, externally managed identity platform and keep its database, administration, protocol compatibility and high-availability operations as a separate service. Rauthy instead centers the identity provider in a Rust binary with embedded persistence as its default and optional Postgres. The practical choice is between a compact, self-contained deployment with configurable modern OIDC defaults and a service-oriented platform whose operating model may fit established organizational processes better. The README does not provide a formal feature matrix against any specific alternative, so compatibility and operating requirements should be compared directly.

## Conclusion

Adopt Rauthy when the requirement is a self-hosted identity provider with OIDC, passkeys, MFA and a Rust deployment footprint, especially on constrained hardware. Do not choose it solely from the feature list if existing clients require algorithms or authentication flows disabled by its defaults. Verify client compatibility, the selected persistence mode, TLS and secret configuration, HA requirements, and the documented deployment procedure before putting it on an application trust boundary.

## FAQ

### Does Rauthy require Postgres?

No. The default is embedded Hiqlite, while Postgres is available as an optional database when an existing instance is already available.

### Can Rauthy provide passwordless login with passkeys?

Yes. Rauthy supports passkey-only accounts, but this flow is restricted to passkeys that provide User Verification. It also supports passwordless login on a client through an encrypted cookie after an initial password and passkey registration.

### What OIDC settings can make client compatibility difficult?

New clients default to `ed25519` token signing and S256 PKCE. The README says clients that do not support these choices will not work with the defaults, so configuration may need adjustment for older systems.

## Sources

- [License: Apache-2.0](https://github.com/sebadob/rauthy/blob/main/LICENSE)
- [Project website](https://sebadob.github.io/rauthy/)
- [README](https://github.com/sebadob/rauthy/blob/main/README.md)
- [Releases](https://github.com/sebadob/rauthy/releases)
- [sebadob/rauthy on GitHub](https://github.com/sebadob/rauthy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sebadob-rauthy