Keycloak and Nauthera, side by side.

Keycloak is the identity provider most Kubernetes teams already know, and its operator can manage single clients as custom resources too, a preview since 26.8.0. This page puts it beside Nauthera, one criterion at a time, and says when each is the better choice.

Checked against: Keycloak 26.8.1, the latest release on November 4, 2026, and its documentation on keycloak.org read that day; for Nauthera, the main branch of nauthera-server and its OIDCClient definition.

#At a glance

#Deployment footprint

Keycloak is a Java server. Its sizing guide plans memory from a base of 1,250 MB per pod with 10,000 cached sessions, and CPU at one vCPU per 15 password logins a second (sizing). It runs on a wide choice of databases, which you provision: "The Keycloak Operator does not manage the database" (basic deployment).

Nauthera is two static Go binaries, the server and the operator, each in a scratch image. Its only database is PostgreSQL, and it needs Redis as well for any issuer that is not on loopback. Its chart sets resource requests and limits, quoted above, and its repository carries a k6 load-test harness, but no results have been published, so there is no sizing guide to set against Keycloak's.

#Protocols

Both serve OAuth 2.0 and OpenID Connect to applications. Keycloak also serves SAML 2.0, and Nauthera does not: an application that only speaks SAML needs Keycloak, or another provider beside Nauthera. 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 Nauthera implements, specification by specification, including what it implements only in part.

#Federation

Keycloak brokers to OpenID Connect and SAML providers, federates users from LDAP and Active Directory, and can sign users in with a Kerberos ticket (server admin guide); Nauthera has no SAML or Kerberos sign-in.

Nauthera signs users in through upstream OpenID Connect providers and GitHub, each an IdentityProvider, and checks passwords against LDAP or Active Directory with an LDAPDirectory. It fetches an upstream provider's documents only from public addresses, so a provider on a private network cannot be one; Air-gapped identity has the details.

#Administration

Keycloak's Admin Console configures every realm, client, flow and mapper, and its Account Console lets users manage their own sign-in methods and sessions (server admin guide).

Nauthera's admin dashboard shows an organization's clients, identity providers, users, sessions, audit log and threat signals, and manages users (create, invite, suspend, block, delete, password resets), their roles and their sessions. Clients are not edited there: they are declared as resources. Users change their password, and enroll passkeys and TOTP, on the hosted sign-in pages as they sign in; there is no account console.

#GitOps and reconciliation

Keycloak offers several declarative paths, each with its own limits:

• KeycloakRealmImport creates a realm and stops there: "The Realm Import CR only supports creation of new realms and does not update or delete those" (realm import).
• KeycloakOIDCClient and KeycloakSAMLClient, experimental in 26.7.0 and a preview since 26.8.0 (release notes), create, update and delete single clients. The guide says it "is describing a feature which is currently in preview". They need the client-admin-api:v2 feature on the server and a <keycloak-cr-name>-admin Secret with master-realm client credentials, which "must be created manually". The resource holds "the complete desired client configuration", and anyone who can edit one "will have the full ability to create or edit clients that the admin credentials provide" (Managing clients).
• Terraform, Crossplane and keycloak-config-cli drive Keycloak's admin API: Terraform from wherever it runs, Crossplane from a provider running in a cluster, and keycloak-config-cli from a container or Job. Keycloak with Terraform, or an operator follows one client through that workflow.

The same confidential client in each, Keycloak's from its guide and Nauthera's as an OIDCClient:

# Keycloak 26.8.1, from "Managing clients"
apiVersion: k8s.keycloak.org/v2alpha1
kind: KeycloakOIDCClient
metadata:
  name: my-confidential-app
spec:
  keycloakCRName: example-kc
  realm: my-realm
  client:
    auth:
      method: client-secret
      secretRef:
        name: my-app-credentials   # a Secret you create, labeled
        key: client-secret-key     # operator.keycloak.org/kind: KeycloakOIDCClient

# Nauthera
apiVersion: nauthera.io/v1alpha1
kind: OIDCClient
metadata:
  name: my-confidential-app
  namespace: my-app
spec:
  clientId: my-confidential-app
  displayName: My app
  redirectUris:
    - https://my-app.example.com/callback
  grantTypes: [authorization_code]
  responseTypes: [code]
  scopes: [openid, profile, email]
  tokenEndpointAuthMethod: client_secret_basic
  pkcePolicy: required_s256
  secret:
    generate: true   # the operator writes Secret my-app/my-confidential-app

Three differences follow from the two resources:

• Who holds the secret. Keycloak's operator reads the secret from a Secret you create and keep. Nauthera's server mints it, returns it once and keeps only a hash; the operator writes it into a Secret under client-id, client-secret and issuer. Deleting that Secret rotates the credential.
• Changes made elsewhere. Keycloak's guide says not to modify operator-managed clients through the Admin UI or API, since the operator "does not detect external changes and will overwrite them". Nauthera's operator watches for a client changed outside it, reports it as Drifted, and leaves it until the manifest changes or the resource is annotated nauthera.io/restore; the audit log says who made the change. See Changes made outside the operator.
• Deletion. Keycloak's operator deletes the client before it removes the resource, and a client whose Keycloak resource went first "will remain on the Keycloak server" (Managing clients). Nauthera's deletionPolicy defaults to Retain, which leaves the client registered so that deleting a namespace cannot take a live client with it; Delete removes it.

Who may register clients also differs. A Nauthera organization admits namespaces, and an OIDCClient configures the organization that admits its namespace, so a team's namespace is the boundary of what it can register (Which organization a resource configures).

#Extending it

Keycloak's Service Provider Interfaces let you add authentication flows, user federation providers, protocol mappers and more, and themes restyle its pages (server admin guide). Groups and roles reach its tokens through protocol mappers.

Nauthera has no plugin, hook or scripting interface. Its tokens carry a fixed set of claims, with no groups claim, so an application maps roles by email or another claim it does emit, as the Argo CD and Grafana pages do. Branding resources set the hosted pages' look per client, and the admin REST API, described by OpenAPI, is what you automate against.

#Release maturity

Keycloak has shipped four minor releases a year since its October 2024 policy, with a major release every two to three years (release updates), and has been an incubating project of the Cloud Native Computing Foundation since April 10, 2023 (cncf.io).

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. Its custom resources are at v1alpha1, the only version served.

#Migrating from Keycloak

Move one application at a time: an OIDCClient keeps the application's client ID, and Keycloak can stay upstream as an OpenID Connect provider, its multi-factor sign-in standing in for Nauthera's second factor, while you move. The Migration guide keeps both providers running until the last application has moved; no Keycloak migration has been recorded in a test yet. For Keycloak that means:

• Clients. Write an OIDCClient per Keycloak client, keeping its client ID and redirect URIs. Client secrets always change, because Nauthera generates them and you cannot set one.
• Users. Keycloak exports realms and their users to JSON with kc.sh export, run while the server is stopped (import and export). Nauthera takes each user's email, username and attributes through its admin API, not their password hashes: users set a new password, accept an invitation, or keep signing in through Keycloak as an upstream provider. TOTP and passkeys are enrolled again.
• Groups and roles. They do not carry over, and Nauthera has no groups claim. Map what each application checks to scopes, or to the user's email.
• SAML clients cannot move. They stay on Keycloak.

Keeping Keycloak as an upstream IdentityProvider moves no accounts at all; it has to be reachable at a public HTTPS address. See Existing identity providers.

#When Nauthera is the better choice

• Each client should ship, be reviewed and be deleted with its application, as a manifest beside the Deployment.
• Nobody should supply or copy a client secret: the server generates it and the operator writes it into a Secret.
• A change made elsewhere should be reported as Drifted, not overwritten.
• Each tenant should be an issuer of its own, with its own signing keys, users and audit log.

#When Keycloak is the better choice today

For production before Nauthera's 1.0, Keycloak. After that, it stays the better choice when you need any of these:

• SAML 2.0, Kerberos or SCIM, none of which Nauthera supports, or LDAP or Active Directory federation with synchronization (server admin guide; release notes).
• Groups or custom claims in tokens, for Kubernetes RBAC, Argo CD projects or Grafana teams, through protocol mappers.
• Fine-grained authorization services (authorization services) or extensions of your own through its Service Provider Interfaces.
• An account console for users, or an admin console that edits everything.
• A project with years of releases, a published cadence and the governance of the Cloud Native Computing Foundation.