Skip to main content

Start here

AuthCrunch adds authentication and authorization to Caddy through the caddy-security module. It can give users a place to sign in and check whether their identity allows them to reach an application.

Authentication answers “Who is this user?” Authorization answers “May this user access this resource?” A successful login does not automatically grant access to every application.

Build your first setup​

Start with two local users and a protected page. You do not need a domain, an external identity provider, or another application server. By the end, you will have tested a successful login, allowed access, denied access, and logout.

  1. Install and verify. Get a Caddy build that includes AuthCrunch.
  2. Protect your first app. Run a local portal and connect it to an access policy.
  3. Verify access. Check what happens for each user, including a user who must be denied.
  4. Choose your next step. Connect a provider or prepare a deployment.

The walkthrough is tested with the published caddy-security v1.3.0 bundle, which includes go-authcrunch v1.3.8. These are different version numbers: the first identifies the Caddy integration; the second identifies its AuthCrunch library. See the release and dependency declaration.

Understand the moving parts​

PartWhat it doesName in the walkthrough
securityDefines the stores, portals, and policies in Caddy's global optionsOne shared block
Identity storeHolds users and checks their credentialslocaldb
Authentication portalProvides login pages and issues an access tokenmyportal at /auth/
Authorization policyVerifies the token and evaluates access rulesapppolicy
Protected routeRuns the policy before serving the application/app

An external identity provider can replace the local login source. The application still needs an authorization decision before its response reaches the user.

Choose a login model​

Use the portal model for the learning path. The other models serve different integration needs; their session and configuration settings are not interchangeable.

ModelUse it when…How access works
Portal and token policyYou want a login portal, local users, or portal MFA and profile pagesThe portal issues a token; a policy checks the token on the protected route
Direct OAuth policyYou want an application's policy to send users directly to an external providerThe policy handles the provider callback and creates its own session; portal user transforms do not apply
AuthCrunch as an OIDC providerYour application is an OIDC client and needs AuthCrunch to supply identityThe application participates in an OIDC authorization flow; this is a separate integration from putting a policy in front of a route

Begin with Install and verify. If you already have a working deployment, browse the guides by topic or go to the reference.