caddy-security v1.2.1

This release adds an OpenID Connect provider, renewable login sessions, a
standalone authentication client, and conditional authentication policies. It
also improves credential handling, authorization, portal usability, and Caddy
configuration validation.

These notes cover caddy-security v1.1.64 → v1.2.1, including the embedded
go-authcrunch upgrade from v1.1.41 to v1.3.3.

New authentication and identity features

• Use your portal as an OpenID Connect provider. Downstream applications can
  authenticate local users through discovery, authorization code flow with S256
  PKCE, consent, ID tokens, UserInfo, and revocation. Supported capabilities
  include query and form-post responses, public and confidential clients,
  signed RS256 Request Objects, authentication-context mappings, and profile,
  email, address, and phone claims. OIDC refresh tokens rotate and require
  explicit offline-access consent. Native public clients support dynamic ports
  on literal IPv4/IPv6 loopback callbacks.
  Provider configuration.

• Provision named OAuth applications and persistent signing keys. New
  oauth application, oauth registration store, and portal oidc provider
  configuration works with the security oauth and security oidc commands.
  Create credentials once, persist them privately, and explicitly rotate client
  secrets or provider signing keys. Normal adaptation and startup load existing
  credentials instead of silently generating replacements.
  Provisioning guide.

• Keep local-user sessions active with rotating refresh credentials. The
  opt-in token refresh block adds bounded session lifetimes, replay detection,
  family revocation, and session-capacity controls. Browser support coordinates
  refresh and logout across tabs and provides a continuation flow after access
  tokens expire. Native clients can explicitly opt into body-based refresh.
  Portal refresh and OIDC refresh grants are separate mechanisms.
  Refresh configuration.

• Choose authentication steps based on enrolled factors. Conditional
  policies support ordered alternatives and password, TOTP-only, or
  WebAuthn-only flows. Static local users can carry ordered challenge rules;
  portal transforms can select a flow while existing require rules remain
  additive. Profile APIs expose registered methods, effective challenges, and
  policy sources, and support validated policy replacement or reset. Issued
  amr claims describe factors actually verified during authentication.
  Authentication flow guide.

• Discover public signing keys and use Ed25519. Portals publish asymmetric
  access-token signing keys at <portal-base>/.well-known/jwks.json. Ed25519
  signing and verification support both EdDSA and Ed25519 algorithm labels,
  including verification of upstream OAuth tokens. Private signing-key export
  is available only through authenticated admin access with an additional,
  independently enabled export setting.
  Key discovery and export.

• Updated portal and OIDC pages. Consent, continuation, and browser error
  pages now share portal branding and custom-template support. The embedded UI
  adds SVG branding, responsive phone layouts, clearer controls and keyboard
  focus, and a QR view that restores the previous form and focus when closed.
  API error responses retain their JSON contract.

Caddy tools and configuration

• New caddy-authenticator CLI. Log in with named profiles using passwords,
  TOTP, or API keys, without requiring the portal admin API. The client stores
  credentials privately, reuses cached access tokens, supports native refresh,
  and provides explicit interactive and forced-login modes. Separate archives
  target Linux, macOS, and Windows on amd64 and arm64; Go installation is also
  supported. Browser SSO and WebAuthn assertions are outside this client's scope.
  Installation and usage.

• Local-user administration from the Caddy binary. security local adds
  login, realm/user inspection, account creation and deletion, account status,
  password resets, role changes, and challenge-policy management through the
  running portal's admin API. Offline commands generate bcrypt password hashes
  and API keys with Caddyfile output.
  Local administration guide.

• Dependency diagnostics. security version reports the linked
  go-authcrunch version, including local replacement information.

• More complete Caddyfile support. Shared parsers bring consistent cookie,
  OAuth, admin API, refresh, and transform handling. OAuth providers gain explicit
  issuer and access-token audience settings. Transforms support field-existence
  matching, typed and nested custom claims, and claim deletion. Runtime
  environment/secret resolution preserves argument boundaries.

• Build custom claims from the user logging in. Caddy resolves environment
  variables and secret references when loading the configuration, while leaving
  {claims.*} placeholders in transform actions for AuthCrunch to evaluate
  against each user's claims during login. Previously, these placeholders could
  fail configuration loading because Caddy tried to resolve them before a user
  identity was available. For example, inside an authentication portal:

  transform user {
      match realm local
      add label "{env.MEMBER_LABEL} {claims.sub}" as string
  }

  With MEMBER_LABEL=Member, configuration loading preserves the value as
  Member {claims.sub}. When a user whose sub claim is alice logs in, the
  action adds "label": "Member alice" to their claims. This supports per-user
  labels and application identifiers from one configuration. Expansion applies
  to supported transform action values; matcher values remain literal, and
  this does not enable {claims.*} placeholders throughout the Caddyfile.

Fixes and security improvements

The go-authcrunch fixes below are included in the Caddy integration through the
v1.3.3 dependency upgrade.

• Password and account handling: equalize bcrypt work across known,
  missing, and disabled identities; prevent duplicate plaintext-password
  records; fix same-password resets and credential revocation; and preserve
  working credentials when reset input is rejected. Password-attempt limits
  apply across portal transports and fresh login sandboxes.
• MFA and profile protection: consume TOTP codes atomically, preserve
  replay/lockout state across database aliases, and bind WebAuthn enrollment
  and login to server challenges, identity, and origin. Profile operations and
  renewal check the current canonical identity and credentials. MFA changes now
  lead to a fresh login instead of a broken refresh-page navigation.
• Policy enforcement: Basic/API-key login, System API authentication,
  refresh, and OIDC reevaluate applicable challenge policies. Transformed claims
  cannot redirect profile operations to another local account. Malformed Basic
  credentials, identity claims, and nested transform values fail safely.
• Authorization boundaries: reject ambiguous encoded or backslash paths,
  malformed UTF-8, and excessive decoding, including for cached identities.
  JWT path grants treat punctuation literally apart from supported wildcards.
  Configured identity headers are cleared before authorization, accepted token
  stripping is honored, and authorization responses use no-store.
• OAuth, SAML, and redirects: bind callbacks to their initiating browser
  transactions, enforce configured SAML signing certificates, reject unsafe
  redirect composition, and recheck OIDC callback destinations before responding.
  Caddy now applies its trusted-proxy decision before passing forwarded metadata
  to AuthCrunch.
• JWKS and key rotation: tolerate unsupported keys when usable keys are
  available, install configured static verification keys, replace remote key
  snapshots safely, remove retired remote keys after successful refresh, and
  preserve request cancellation errors.
• Cookies and session recovery: preserve security attributes and scope when
  deleting reserved-prefix cookies, remove duplicate insecure return-cookie
  deletion headers, honor per-domain stripping, and coordinate explicit names
  with cookie prefixes. Refresh fixes cover account switching, capacity recovery,
  and uncertain responses without weakening replay detection.
• Runtime and parser reliability: drain in-flight authentication and
  authorization requests before disposing Caddy security runtimes, clean up
  failed replacements, and keep the active service after rejected configuration.
  Fix dropped LDAP fallback roles, transform actions containing the word
  match, malformed redirect-trust input, and multiline native-JSON instructions
  that could discard later policy statements.
• Cryptography and rendering: use cryptographic randomness without weak
  fallbacks or biased character selection, adopt maintained OpenPGP parsing,
  and correct MFA URI encoding and browser fragment handling.

Upgrade notes and operational limits

• Source builds require Go 1.26 or newer. CI and release builds select
  Go 1.26.8. The Caddy dependency remains v2.11.4.
• SAML login must start at the portal. SP-initiated login is now required;
  unsolicited IdP-initiated responses are rejected. Preserve the browser-binding
  cookie when configuring cross-site SAML callbacks.
• Plan local-file runtime replacements. A live replacement that reuses an
  active local identity file or registration dropbox is rejected, leaving the
  old deployment running. Stop the owning runtime before replacing it with one
  using the same file. Share one named store across portals instead of declaring
  multiple stores for the same file.
  Lifecycle restrictions.
• Refresh and OIDC state are process-local. These features currently use
  local identity stores and bounded in-memory sessions/grants. Restart, runtime
  replacement, or identity-store reload can require fresh authentication;
  active/active session sharing is not supported. Persisted application
  registrations and signing keys are separate from this volatile state.
  Revoking renewal evidence does not instantly invalidate every previously
  issued access JWT; those tokens retain their configured lifetime.
• Use explicit realm matchers with renewable or System API authentication.
  match any transforms are rejected when portal refresh or OIDC is enabled,
  or a portal key has System API usage, because of a go-authcrunch v1.3.3
  compatibility limitation. Replace them with an appropriate explicit matcher,
  such as match realm local.
  Compatibility details.
• Review client and customization assumptions. Custom access/session cookie
  names must be coordinated with authorization policies. Profile API mutations
  require JSON and fresh authentication after credential or policy changes.
  Review JWT path grants that relied on regex punctuation, and preserve the
  embedded session coordinator when using custom refresh-aware templates.
  WebAuthn-only flows remain account-first, not discoverable accountless login.
• Provision OIDC explicitly. Use one redirect_uri directive per callback.
  Keep provider signing keys separate from portal access-token keys. Private
  registration and provider-key storage currently require supported Unix
  ownership/permission checks; those storage paths fail closed on other
  platforms.

Additional go-authcrunch tools

• Standalone authdb server: go-authcrunch adds its own HTTP/2 and TLS
  server for portals, profile/admin APIs, refresh, and OIDC using JSON
  configuration and graceful shutdown. This is distributed by go-authcrunch
  separately from caddy-security's authcrunch and caddy-authenticator
  executables.
  AuthDB guide.
• Reusable authentication client and CLI fixes: pkg/authclient exposes
  password, TOTP, and API-key login for Go applications, with opt-in delivery
  and storage of native refresh credentials. Renewal remains the caller's
  responsibility; caddy-authenticator implements it. authdbctl fixes include
  piped input, terminal restoration on timeout, JSON escaping, conflicting
  updates, and false-success responses.

Validation and release tooling

The repositories add race-enabled tests and broader real Caddy/TLS/browser
coverage for authentication, refresh, OIDC, key rotation, authorization, and
reloads. Test reports retain failures and use versioned artifact names.
An opt-in OpenID Foundation conformance workflow exports readable reports and
complete evidence; OpenID certification is not claimed. Recorded
qualification also retains security findings and manual protocol-review
outcomes; see the qualification notes
for their tested revisions and limits.

For maintainers, make release and make minor-release run the local quality
gate before atomic branch/tag publication. make fast-release and
make fast-minor-release skip that local gate while preserving version/Git
checks; GitHub release validation still runs before publication of binaries.

Acknowledgments

Thank you to @openai Daybreak Blue agents for auditing the caddy-security and
go-authcrunch codebases for vulnerabilities.

Full changes: caddy-security v1.1.64…v1.2.1,
go-authcrunch v1.1.41…v1.3.3.