Introduction
rIDM is a self-hosted, multi-tenant identity server written in Rust. It is an OpenID Connect provider and JWT issuer with user, group and role management, multi-factor authentication, passkeys and identity brokering, plus two web consoles: one for administrators and one for end users managing their own account.
A deployment is the ridm-api server, Postgres and Valkey (or Redis). Every
tenant it hosts has its own issuer, signing keys, users, clients, policies and
administrators. Applications sign users in through the standard authorization
code flow, and APIs accept the resulting access tokens by checking them
against the tenant’s published keys (or, for clients that ask for opaque access
tokens, at the tenant’s introspection endpoint).
Status:
0.4.1. Until 1.0.0 a minor version may break compatibility, and the changelog says how. The working plan lists what is done and what is still to come.
Who it is for
- Operators who want an identity provider they run themselves: on bare metal, in docker-compose, on Kubernetes or on any cloud, with the same image and nothing but environment variables to configure it.
- Application and API developers who need standard OAuth 2.0 and OpenID
Connect behaviour to integrate against, without provider-specific SDKs. A Rust
API can use the
ridm-authcrate to validate tokens; anything else uses an ordinary OIDC or JWT library. - Teams serving several customers or business units from one deployment, each as a tenant with its own login page, policies and administrators.
- Teams leaving another identity provider, who need password hashes, users and configuration to come across without forcing every user to reset.
What it deliberately does not do
rIDM implements the parts of OAuth 2.0 and OpenID Connect that current security guidance recommends and refuses the rest, so that a misconfigured client cannot fall back to a weaker flow.
- No implicit flow, no hybrid flow, no resource owner password credentials
grant.
/authorizeacceptsresponse_type=codeonly, and the password never travels to an application. Discovery advertisesresponse_types_supported: ["code"]. - No
plainPKCE. A code challenge must useS256; public clients must always send one. - No cloud-specific dependencies. The default build needs a container runtime, Postgres and Valkey and nothing else. Email goes out over SMTP or an HTTP webhook, text messages over an HTTP gateway, and secrets at rest are encrypted with a master key you supply, or held in an HSM or a cloud key management service if you choose one (Key custody).
Where something is not built yet, this book says so where you would look for it.
How this book is organised
| Section | Read it for | Starts at |
|---|---|---|
| Concepts | The model: tenants, clients, roles, tokens, keys, sessions, and why they work the way they do | Tenants and issuers |
| Quickstarts | A running server and a first integration, one scenario per page | Run rIDM locally |
| Admin guide | Day-to-day administration through the consoles, the ridm CLI and the admin API | The admin and account consoles |
| Reference | Endpoints, the admin API, token claims, environment variables, the tenant document, errors | HTTP endpoints |
| Deployment | Running rIDM in production: containers, TLS, Postgres and Valkey, scaling, observability | Deployment overview |
| Migration | Moving users and configuration from another identity provider | Migrating to rIDM |
The concepts pages explain the reasoning; the admin guide and reference hold the exhaustive lists of settings, fields and endpoints.
Where to start
Running rIDM. Start with Run rIDM locally to have a server, the consoles and a first administrator on screen, then read the Deployment overview before putting it anywhere others can reach. Tenants and issuers and Signing keys and the master key explain the two decisions you cannot easily undo later: your public URL and your master key.
Integrating an application or API. To accept rIDM tokens in an API, read Protect a Rust API with ridm-auth. To sign users in from a browser application, read Sign in from a single-page app, or Sign in from a server-side web app for an application that keeps a secret. Clients, Resource servers, scopes and permissions and Tokens explain what you are configuring.
Moving from another provider. Read Migrating to rIDM, then the page for your current provider.