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.
• MFA (TOTP) — Enforce two-factor authentication via AuthPolicy. Users enrol with any standard TOTP app; single-use backup codes provided for recovery.
• External IdP federation — Connect existing OIDC-compatible identity providers via the IdentityProvider CRD.
• SCIM 2.0 provisioning — Sync users and groups automatically from Okta, Entra ID, or any SCIM 2.0 directory (Business+ tier).
• Audit event log — Tamper-evident log of all authentication, token, and admin events. Configurable retention.
• Prometheus metrics — Built-in observability endpoint at /metrics for cluster-native monitoring.
• Account lockout — Automatic brute-force protection with configurable thresholds and lockout windows.

#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 →

#NautheraServiceAccount

A NautheraServiceAccount provisions OAuth2 client credentials for machine-to-machine authentication. Unlike an OidcClient, a NautheraServiceAccount 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: NautheraServiceAccount
metadata:
  name: payment-service
  namespace: payments-prod

Full NautheraServiceAccount 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 NautheraServiceAccount. User and session storage (PostgreSQL) is configured via Helm values at install time.

Roadmap: Future releases will add social login (Google, GitHub), self-service registration, and an admin dashboard UI. External IdP federation is available today via the IdentityProvider CRD; SAML federation via SamlIdentityProvider (Enterprise).

#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, NautheraServiceAccount, AuthPolicy, IdentityProvider.
6. User Management — Create and manage user accounts via the admin API.
7. Login Experience — Customize the login page and consent screen.
8. MFA — Enforce TOTP two-factor authentication.
9. SCIM 2.0 — Automate user provisioning from your enterprise directory (Business+).