Introduction

Nauthera is an OAuth 2.0 and OpenID Connect identity provider for Kubernetes, built around one goal: an application's OAuth client is a Kubernetes resource that ships with it. You declare an OIDCClient beside the app's Deployment, and the Nauthera operator registers it with the server and writes the generated client secret into a Secret the workload mounts. See Operator.

nauthera-server is a single static Go binary that serves the protocol endpoints, a hosted sign-in UI, an admin dashboard and a versioned admin API, and exposes the mutual-TLS gRPC AdminService the operator calls.

Project status: pre-1.0, not yet released. The features under What it does today are implemented and tested in the nauthera-server repository. No container image or Helm chart has been published yet (#307), and the source is private, so you can't install Nauthera yet. Join the waitlist to hear when it ships.

#What it does today

• OAuth 2.0 and OpenID Connect. Authorization code with PKCE (S256), refresh tokens that rotate on every use with reuse detection, client credentials, and the device authorization grant. Also discovery, JWKS, UserInfo, introspection, revocation, and RP-initiated, front-channel and back-channel logout.
• Sender-constrained and hardened requests. DPoP-bound tokens (RFC 9449), pushed authorization requests (RFC 9126), signed request objects (RFC 9101) and resource indicators (RFC 8707). A per-organization FAPI 2.0 mode (partial).
• Organizations. Multi-tenant realms, each its own issuer with its own discovery document, JWKS and signing keys. Sessions never cross organizations.
• Hosted sign-in UI. Sign-in, registration, password reset, email verification, consent, device-code approval, MFA and logout screens are compiled into the binary, translated into English, German and French, and themed per OAuth client.
• Email. Password reset links, email verification links and alerts about a sign-in from an unrecognized browser or network, sent through SMTP over TLS from a durable outbox, with a relay per organization if you want one.
• Kubernetes operator. Registers each OIDCClient manifest with the server, delivers the minted secret into a Secret, follows the manifest's deletion policy, reports a client changed outside it, and publishes metrics. It ships in the server's Helm chart.
• Multi-factor authentication. TOTP with recovery codes and lockout, and optional mandatory enrolment.
• Admin dashboard, admin API and audit log. A dashboard per organization for its clients, users, sessions, audit log and email settings, over a REST API that requires an OAuth scope and an RBAC permission for every call. User accounts carry a status (active, suspended, blocked) enforced at sign-in and on every token grant.
• Operations. PostgreSQL or SQLite, a Redis cache (required for any non-loopback issuer, optional for local development), Prometheus metrics, OpenTelemetry tracing, structured logs, a Helm chart for the server with cert-manager integration, and startup checks that refuse unsafe production configuration.

#What it does not do

Here is what Nauthera does not do today, with the issue that tracks it where there is one:

• The operator does not reconcile Branding yet (#404). Its resource definition exists; branding is written over the gRPC AdminService directly. See Operator.
• Passkeys / WebAuthn are planned (#200–#204). The hosted UI's passkey screens are parked until the server supports them.
• No federation or provisioning. There is no upstream or social identity provider federation, no SAML and no SCIM.
• No mutual-TLS client authentication or certificate-bound tokens (RFC 8705), and no client_secret_jwt.
• Some grants are not offered. Token exchange (RFC 8693) and the JWT bearer grant answer temporarily_unavailable and are not advertised.

See Standards for a specification-by-specification breakdown, and the roadmap for planned work.

#How it fits together

#Where to go next

The Quick Start and Installation guides assume access to the source, which is private. They will apply to everyone once a release is published (#307).

1. Operator and OIDCClient: what the operator does and the resource you declare.
2. Quick Start: run the full stack locally with Docker Compose and sign in.
3. Installation: install the Helm chart on a kind cluster, then move to a production profile.
4. Configuration: the configuration file, environment variables and secret files.
5. Architecture: the three listeners, storage, email and the control plane.
6. Organizations and Clients: tenants and how applications are registered.
7. Connect an Application: sign users in to your own app, step by step.
8. Endpoints: every HTTP endpoint the server serves.
9. Keys & Secrets and Backups & Upgrades: what to protect and how to run it over time.