Introduction

Nauthera is a Kubernetes-native authentication operator that brings first-class OIDC and OAuth2 support directly into your cluster. Just as ingress-nginx deploys nginx and watches Ingress resources, Nauthera deploys an auth server and watches OidcClient and AuthPolicy resources. No standalone identity service required — Nauthera lives inside Kubernetes and speaks its language.

#What is Nauthera?

Authentication infrastructure is often the last thing to be "cloud-native." Many teams still rely on externally hosted identity providers that are configured through UIs, require manual secret rotation, and sit entirely outside the GitOps workflow that governs the rest of their platform.

Nauthera closes that gap. With Nauthera you can:

• Declare auth as code — OidcClients and AuthPolicies are Kubernetes resources managed in YAML and version-controlled alongside your application manifests.
• Enforce policies via GitOps — Changes to auth configuration go through pull requests, code review, and CI/CD, just like everything else.
• Namespace-isolated clients — Application teams register their own OidcClient resources in their own namespaces, with no access to the cluster-wide configuration.
• Policy-driven access control — No implicit access is granted. All token issuance is governed by explicit ClusterAuthPolicy and AuthPolicy rules.

#Key Concepts

#OidcClient

An OidcClient registers an OAuth2/OIDC application with the Nauthera operator. Each client lives in the namespace of the application it belongs to. Application teams own their own clients — the operator handles registration and credential provisioning automatically.

apiVersion: auth.nauthera.io/v1alpha1
kind: OidcClient
metadata:
  name: my-webapp
  namespace: my-app-dev

Full OidcClient reference →

#ServiceAccount

A ServiceAccount provisions OAuth2 client credentials for machine-to-machine authentication. Unlike an OidcClient, a ServiceAccount has no redirect URIs and no login flow — it exclusively uses the client_credentials grant. The operator generates credentials and projects them into a Kubernetes Secret automatically.

apiVersion: auth.nauthera.io/v1alpha1
kind: ServiceAccount
metadata:
  name: payment-service
  namespace: payments-prod

Full ServiceAccount reference →

#ClusterAuthPolicy & AuthPolicy

Two CRDs manage policy — ClusterAuthPolicy for cluster-wide defaults and AuthPolicy for namespace-scoped overrides. ClusterAuthPolicy resources are cluster-scoped and define the baseline rules for token issuance. AuthPolicy resources are namespaced and override specific settings for OidcClients and ServiceAccounts within a given namespace.

apiVersion: auth.nauthera.io/v1alpha1
kind: ClusterAuthPolicy
metadata:
  name: standard-web-policy

Full AuthPolicy reference →

#How It Fits Together

The Nauthera operator is the central piece. It runs the auth server, applies ClusterAuthPolicy and AuthPolicy rules to token issuance, and provisions OIDC credentials for each OidcClient and ServiceAccount. User storage (PostgreSQL) and optional session management (Redis, for HA deployments) are configured via Helm values at install time.

Roadmap: Future releases will add support for alternative user storage methods (LDAP, external IdPs) and OAuth2 social login/sign-up.

#Getting Started

If you are new to Nauthera, follow this path:

1. Installation — Install the Nauthera operator into your cluster using Helm.
2. Quick Start — Create your first policy, client, and user — then get a working token.
3. Architecture — Understand the operator pattern, CRD relationships, and the reconciliation loop.
4. Endpoints — Full reference for all OAuth2/OIDC HTTP endpoints.
5. CRD References — Deep-dive into each resource: OidcClient, ServiceAccount, AuthPolicy.
6. User Management — Create and manage user accounts via the admin API.
7. Login Experience — Customize the login page and consent screen.