What Nauthera is for
Nauthera is a self-hosted OAuth 2.0 and OpenID Connect identity provider for Kubernetes, written in Go. Applications on your clusters sign their users in through it: web applications with the authorization code flow and PKCE, single-page and native apps as public clients, APIs that validate its access tokens, and platform tools such as Argo CD and Grafana.
What sets it apart is where the clients live. An application's OAuth client is an
OIDCClient manifest beside its Deployment, reviewed and released with it. The operator
registers it with the server and writes the generated client secret into a Kubernetes
Secret in the application's namespace, so nobody copies a secret out of a console.
Why an operator explains the approach.
What it brings
- An issuer per organization. Each organization has its own discovery document, signing keys, users, sessions and audit log.
- Sign-in people already use. Passwords, passkeys and TOTP on hosted pages in English, German and French, and sign-in through OpenID Connect providers, GitHub or an LDAP directory or Active Directory.
- A tamper-evident audit log. Records are hash-chained, with signed checkpoints.
- Safe defaults that hold. PKCE with S256 is required by default, and unsafe settings for a production issuer stop the server at startup.
Where it stands
Nauthera is pre-1.0, in a design-partner program: its signed server and operator images and its Helm chart are public on the GitHub Container Registry, and teams can apply for one of five design-partner seats to pilot it with direct support. The source is private. If your team wants to shape it, apply for a design-partner seat at the end of the page.
Outside its scope
Nauthera signs people in to applications. kubectl and the Kubernetes API server's own OIDC login, and Vault's Kubernetes auth method and other workload identity where the cluster is the issuer, are outside its scope: it emits no groups claim for Kubernetes RBAC to bind, and Kubernetes OIDC, end to end explains the difference. It does not serve SAML, SCIM provisioning, user import or token exchange (RFC 8693); users sign in through OpenID Connect providers, GitHub, LDAP or Active Directory, or with an account of its own. Standards lists what it implements, spec by spec.