Questions people ask about Nauthera

What it has: an OAuth 2.0 and OpenID Connect provider whose organizations are each their own issuer, hosted sign-in pages, an admin dashboard and API, and a hash-chained audit log. Users sign in with a password or, where allowed, a passkey alone; through an external OpenID Connect provider or GitHub; or with an LDAP or Active Directory password. The second factor is TOTP, a passkey or, where an operator opts in, an emailed code.

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. 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. Keycloak vs Nauthera says when Keycloak is the better choice today.

Passwords cannot be imported as hashes, and tokens carry scopes and Nauthera's own admin roles, not the old provider's groups, so moving users means invitations, password resets or federation. Migration walks through it one application at a time.

Keycloak can stay where it is: Nauthera can sit between your applications and an existing OpenID Connect provider, as their issuer. That provider's discovery document, token endpoint and keys must be on public addresses: the server refuses private ones, and an HTTPS_PROXY on a private address too.

Keycloak's operator manages clients as custom resources too, a preview since Keycloak 26.8.0, with a secret you supply (Managing clients). In Nauthera the OIDCClient resource is the main interface: the server generates the secret and the operator writes it into a Kubernetes Secret.

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.

Users sign in with a password or, where allowed, a passkey alone; through an external OpenID Connect provider or GitHub; or with an LDAP or Active Directory password. The second factor is TOTP, a passkey or, where an operator opts in, an emailed code. Passkeys are WebAuthn credentials; attestation statements are not verified.

Without SCIM, accounts are created over the admin API, by invitation, by self-service sign-up, or at a first sign-in through an external provider or an LDAP directory that allows sign-up.

It runs on PostgreSQL, with Redis for any production issuer, and sends no telemetry. There are no update checks. The default captcha is a built-in proof-of-work that calls no third party, and the breached-password lookup is off by default and can point at a self-hosted mirror.

What you can switch on calls out: an external identity provider's discovery document, token endpoint and keys (GitHub sign-in calls github.com and api.github.com), a client's jwks_uri, back-channel logout to relying parties, a hosted captcha, an SMTP relay, an OpenTelemetry collector and LDAP servers.

In a network where everything has a private address, mind one rule: the server refuses to fetch an identity provider's endpoints or a client's jwks_uri on a loopback, private, link-local or shared address, and checks the resolved address again when it dials. Behind an HTTPS_PROXY that check sees the proxy, so a proxy on a private address is refused too. Back-channel logout refuses a relying party on such an address, with or without a proxy.

The server and operator images and the OCI Helm chart can be mirrored into a private registry (image.repository, image.digest, imagePullSecrets); verifying their cosign signatures needs Sigstore, which is online.

Air-gapped identity puts it together: mirrored images and chart, DNS and the issuer URL, keys and certificates, and the federation limits. It is drawn from the code and the docs; no installation in a disconnected network has been validated.

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.

The server, the operator and the Helm chart are built and tested in nauthera-server's CI. Each version tag publishes both images and the chart, scanned and signed with cosign, to the GitHub Container Registry, where anyone can pull them without a login; Downloads lists every version.

The operator's resources are nauthera.io/v1alpha1, the only API version so far, and the docs follow nauthera-server's main branch, so APIs and features can change before 1.0.

Apply for a design-partner seat to pilot it with direct support, or join the waitlist for one email when the operator ships.

The source repository is private and carries no license file. The Helm chart's Artifact Hub annotation already names Apache-2.0, the license planned for the core.

The plan: the core free to self-host, with enterprise features and support paid. There are no prices yet.

Argo CD sign-in covers argocd-cm, argocd-rbac-cm and the argocd CLI; Grafana sign-in covers generic OAuth with the client secret from the operator's Secret. The Quick Start's Docker Compose stack signs in to Grafana through Nauthera, with PKCE required. GitOps & Argo CD proposes a repository layout, sync waves and health checks for delivering the server and each OIDCClient with Argo CD.

Each guide names the version of the tool it was checked against; neither records an end-to-end run against the running tool. Argo CD sends PKCE only with enablePKCEAuthentication: true in oidc.config (Argo CD 3.6 user management), and then sends no client secret (argo-cd#23773, open), so under the default PKCE policy its OIDCClient is a public client (tokenEndpointAuthMethod: none). A client with a secret needs pkcePolicy: optional, and Argo CD reads a $secret:key reference only from a Secret labeled app.kubernetes.io/part-of: argocd, which the operator does not set: it labels its Secret only app.kubernetes.io/managed-by.

Tokens carry no groups claim, so Argo CD RBAC and Grafana role mapping by group cannot be driven from Nauthera today: map by email or subject instead.

Dex is a released project with connectors for LDAP, GitHub, Google, Microsoft and other providers (Dex v2.46.1). Its clients are declared in its configuration file or created through its gRPC API, and its custom resources are its storage, which its docs say admins should not edit except while debugging.

Nauthera keeps accounts, passwords, passkeys and TOTP, organizations that are each their own issuer, an admin dashboard and a hash-chained audit log, and federates too. Its operator turns an OIDCClient manifest into a registered client, writes the generated secret into a Secret and reports status on the resource.

Choose Dex when you only need to federate existing identities and want a small component past its 1.0: Nauthera is pre-1.0, in a design-partner program.

The standards page lists, spec by spec, what the server implements, what only in part and what not at all, each checked against its code and tests. That is a statement of support, not a certification.

The discovery document advertises only what the server serves: a test fails the build when an advertised endpoint, grant or capability has no handler behind it.