Nauthera next to the identity providers you know.

#Nauthera's difference

Nauthera's difference is where the client lives: its operator turns an OIDCClient manifest into a registered client, delivers a secret the server generated and keeps only as a digest, and reports a client changed elsewhere as Drifted instead of overwriting it. 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 tools below are past their 1.0; for a production deployment before Nauthera's, pick one of them.

Each row about another tool names the release that was current on November 4, 2026, and links where the fact was read that day; a link to a repository's default branch is that branch as it was on that day. Two pages go further: Keycloak and Nauthera, criterion by criterion, and Keycloak with Terraform, or an operator, one client through both workflows.

#Prior art, and where Nauthera differs

The client resource is part of the provider itself, not an add-on to one; the server generates each secret, keeps only its digest, and the operator writes it into a Secret, so no secret is supplied by hand or kept in a state file; and a client changed outside the operator is reported as Drifted and left alone until someone restores it.

Others declare clients as custom resources too:

• Ory Hydra Maester watches oauth2clients.hydra.ory.sh/v1alpha1 resources and writes each client's ID and secret into a Secret. Its README says it "is developed by the Ory community and is not actively maintained by Ory core maintainers" (README; latest tag v0.0.42, May 25, 2026).
• Crossplane provider-keycloak manages Keycloak clients as openidclient.keycloak.crossplane.io resources, generated with Upjet from the Keycloak Terraform provider (README; v3.2.3, October 19, 2026).
• truvity/zitadel-operator, a third-party operator for Zitadel, declares OIDCApp resources and writes client_id and client_secret into a Secret (pkg.go.dev; v0.21.0, September 6, 2026).
• Keycloak's own operator added KeycloakOIDCClient and KeycloakSAMLClient resources as an experimental feature in 26.7.0 and promoted them to preview in 26.8.0 (release notes, Managing clients; Keycloak 26.8.1).

#Side by side

#Runtime and database

#Protocols

#Where users sign in from

#Administration

#OAuth clients as Kubernetes resources

#License

#Release and project

#When Nauthera fits best

• Your apps ship as manifests (Helm, Argo CD, Flux), and each team owns its clients beside its Deployment.
• No client secret in Git or a state file: the server generates it and keeps a digest, and the operator writes the Secret.
• A tenant per issuer: each organization has its own discovery document, keys, users, sessions and audit log.
• Current OAuth security without plugins: DPoP, pushed authorization requests, signed request objects, and PKCE with S256 required by default.
• A small, auditable footprint: one static Go binary in a scratch image, and a hash-chained audit log with signed checkpoints.

#When another tool is the better choice

The operator page compares the approach with Terraform and Ansible in general: Why a Kubernetes operator.

#Where Nauthera stands

What its code has today: OAuth 2.0 and OpenID Connect with PKCE, pushed authorization requests and DPoP-bound tokens; organizations, each its own issuer; sign-in with passkeys, TOTP, upstream OpenID Connect providers, GitHub and LDAP or Active Directory; a hash-chained audit log with signed checkpoints; an admin dashboard; and the operator, which reconciles OIDCClient, Organization, IdentityProvider, Branding, LDAPDirectory and BrokerMembership. It emits no groups claim, so applications map roles by email or another claim it does emit. Standards lists every specification, and Existing identity providers covers running it beside the provider you have.