Skip to main content
Version: Next

Nauthilus 4.0.0-alpha.1

v4.0.0-alpha.1 is published from Nauthilus commit 0afd1d3ac5e5dc937609482ba93e921d166dc927 as the first v4 prerelease. Publication does not imply production readiness: validate configuration, data, clients, plugins, browser flows, and external integrations against the exact artifact before rollout.

Breaking Changes​

  • The Go module identity is github.com/croessner/nauthilus/v4; builds use Go 1.27 and GOEXPERIMENT=runtimesecret.
  • Native Go plugins must be rebuilt against the exact v4 host build environment. pluginapi/v1 contract compatibility does not make a mismatched Go .so load-compatible.
  • Top-level policy is the sole production configuration and runtime authority for authentication, IdP, backchannel, Policy HTTP, and Policy gRPC decisions.
  • The v3 auth.policy root, mixed roots, unqualified standard_auth, rule/check stage, and check config_ref are rejected. Migration is manual; there is no converter or compatibility window.
  • Browser state uses one opaque v1 envelope and typed Redis stores. There is no legacy read/write fallback, and a browser-serving pool must not mix v3.1 and v4 replicas.
  • The old session-cookie /api/v1/mfa/* management routes are retired. The interactive portal uses /mfa/*; the scoped cookie-free /api/v1/mfa-backchannel/* family remains distinct.
  • Policy and backchannel credentials have separate exact audiences and must be issued, cached, rotated, and presented independently.

Identity and Browser Flows​

  • Restricted RFC 7591 Dynamic Client Registration supports public native clients with exact redirect validation, RFC 8252 loopback handling, PKCE S256, bounded metadata, rate limits, and no secret issuance. See the DCR guide.
  • The direct MFA self-service portal starts at /mfa/register/home[/lang], authenticates with the normal first factor, rotates the browser session, and supports TOTP, WebAuthn, and recovery-code management under explicit enrollment and freshness gates.
  • OIDC, SAML, login, consent, logout, MFA, and WebAuthn operations use typed, revisioned, expiring Redis records owned by one opaque browser-session anchor. Existing v3.1 records are inert rather than migrated. See the session migration contract.

Generic Policy API and Runtime​

  • POST /api/v1/policy/decisions and gRPC /nauthilus.policy.v1.PolicyDecisionService/Evaluate expose the same protected unary evaluation contract.
  • Caller profiles bind credentials to targets, schemas, fact allowlists, diagnostics, mTLS, request bounds, rates, and concurrency. Policy Basic and Policy Bearer never fall back to management or backchannel credentials.
  • Values are strictly typed. Ordered record lists are schema-defined, bounded, non-recursive, and distinguish missing from empty. any/all evaluation cannot turn a malformed or absent collection into a vacuous permit.
  • Decisions are permit, deny, not_applicable, or indeterminate; obligations, advice, diagnostics, and failure behavior are bounded and closed by configuration.
  • Candidate generations compile atomically. Required-provider failure, schema/provenance violations, effect outcomes, timeouts, rejected post-action scheduling, metrics, logs, and traces have explicit fail-closed semantics.
  • Native DecisionFactProvider and DecisionEffectProvider interfaces replace the stale Policy plugin surface. Restricted generic Lua providers can contribute declared facts and execute only selected effects.

See Operating the Generic Policy API, Policy configuration, and the updated native plugin Policy API.

Public APIs and DKIM2 Integration​

Public protobuf sources now live consistently below api/auth/v1, api/common/v1, api/identity/v1, and api/policy/v1. Go imports use the v4 module. Protobuf package names, service/method names, field numbers, wire types, and unchanged HTTP paths retain their wire meaning; generated Go source identity does not. See Public protobuf APIs.

The source-level DKIM2 reputation provider demonstrates the generic native provider model for dkim2/accept-message-instance. DKIM2 v0.1.22 publishes the aligned Rspamd adapter with strict echoed request_id correlation and the complete DMARC signal mapping. Its neutral Rspamd/Nauthilus/Milter harness passes the adapter, retry-cache, TLS, Generic Policy, and native-provider path, but intentionally stubs the real dkim2d process endpoint. A live-daemon verifier PASS through real DNS and message-wire handling therefore remains a separate operator acceptance gate before production enforcement. See the DKIM2/Rspamd integration contract.

Migration Entry Point​

Follow the v4 migration checklist and validate the complete deployment candidate in a non-production environment. The website's generated OpenAPI reference is maintained separately from these hand-written guides; use the OpenAPI artifact shipped with the exact Nauthilus build when a generated page lags the source contract.