caddy-security is an authentication, authorization, and accounting (AAA) app and plugin for Caddy v2 that implements form-based, basic, local, LDAP, OpenID Connect, OAuth 2.0 and SAML sign-in together with JWT and PASETO request authorization, and it is aimed at operators and security teams who terminate HTTP traffic with Caddy and want identity enforcement to happen inside the web server itself.

What it is

caddy-security is a Go project, licensed under Apache-2.0, that extends Caddy v2 with three cooperating plugins: an authentication plugin, an authorization plugin, and a credentials plugin. The authentication plugin covers form-based, basic, local, LDAP, OpenID Connect, OAuth 2.0 (including Github, Google, Facebook and Okta) and SAML authentication. The authorization plugin makes HTTP request authorization decisions based on JWT or PASETO tokens, and the credentials plugin manages the credentials required by the various integrations. The project supports both portals and direct OAuth policies without a portal, and it links against a go-authcrunch version that can be displayed by running bin/authcrunch security version.

The ecosystem it lives in is Caddy v2, and the specific thing it replaces is the separate AAA component that would otherwise be deployed alongside or in front of the web server: this project performs that work as a Caddy app and plugin set rather than as an external service. The concrete problem it solves is identity at the edge. A site fronted by Caddy commonly needs to accept users from more than one identity provider, distinguish external OAuth providers from directory-backed LDAP or SAML sources, enforce multi-factor authentication, and then make per-request authorization decisions that survive a restart. caddy-security addresses each of those needs through configuration, and sessions and generated signing keys can be retained across restarts when persistent runtime state is enabled.

Key capabilities

• Authentication across form-based, basic, local, LDAP, OpenID Connect, OAuth 2.0 (Github, Google, Facebook, Okta and others) and SAML methods.
• Multi-factor and two-factor authentication with app authenticators and Yubico, with WebAuthn also listed among the project topics.
• HTTP request authorization driven by JWT and PASETO tokens.
• A credentials plugin that manages credentials for the various integrations.
• Portal-based access alongside direct OAuth policies that run without a portal.
• Persistent runtime state that retains sessions and generated signing keys across restarts.
• A standalone caddy-authenticator command-line tool for portal login with named profiles, with release archives for Linux, macOS and Windows on amd64 and arm64.

Who uses it and how

• Teams that already terminate HTTP with Caddy v2 and need single sign-on across Github, Google, Facebook, Okta, LDAP or SAML without writing and maintaining their own middleware.
• Security and platform engineers, reflected in the secops and secdevops topics, who want access-control and ACL decisions made per request from JWT or PASETO tokens.
• Organisations that require multi-factor authentication through app authenticators or Yubico hardware keys before users reach protected endpoints.
• Operators of persistent deployments, who must plan a complete stop and start: overlapping reload is rejected, and runtimes that share the same local identity file cannot overlap, with request draining and failed-replacement cleanup part of that lifecycle.
• Command-line users who need portal login with named profiles through the standalone caddy-authenticator binary rather than through a browser session.

Getting started

The documented installation route is to download Caddy with the plugins enabled, with windows/amd64 and linux/amd64 builds called out in the README. For local work, make dep downloads module dependencies and resolves the pinned tested tool, make test runs race-enabled Go tests with coverage written to .coverage/index.html, and make ci-check runs version checks, automation fixtures, the full Go suite and the Caddy binary build.

How it compares

No list of paid products that this project replaces is provided, and the facts name no comparable AAA tool for Caddy, so caddy-security stands alone in this registry as an AAA app and plugin for Caddy v2 rather than one product among a field of alternatives. Its closest named relationship is internal: the linked go-authcrunch version it depends on, reported by bin/authcrunch security version.

When to use it — and when not to

A self-hoster takes on the operational discipline of Caddy itself: persistent runtime state must be enabled to retain sessions and signing keys, and persistent deployments require a complete stop and start rather than an overlapping reload. Anyone not running Caddy v2, or unwilling to accept that downtime pattern for configuration changes, should look elsewhere. The documentation is also in transition, having moved from docs.authcrunch.com to skill-based material under .codex/skills, so expect to read the repository as closely as any published guide.