Selfhosted

yes, it can do that, assuming you are using LDAP or have set up users/groups in the Authelia config. you don't need to set it up in the caddyfile though, you can handle everything from Authelia's end. for example, here is a typical protected item from my caddyfile.

# this is a bit of code at the top that I use for every protected item, and call it each time to save space
(protected) {
	tls /ssl/home-cert.pem /ssl/home-key.pem
	forward_auth :4100 {
		uri /api/verify?rd=https://auth.myurl.xyz/
		copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
		header_up Host {upstream_hostport}
	}
	encode gzip
}

# UptimeKuma
uptime.myurl.xyz {
    # now to call the code above for this item
	import protected *
	reverse_proxy :4000
}

that's all I need in my caddyfile, just the bits that forward the information about the user to each site to log them in. I can then handle all the auth rules like saying which sites are only for admins or users in the Authelia config. since I use LDAP, I can set up the groups in that, then just specify which sites are DENY or TWO_FACTOR for each group in the Authelia config. or even in the apps themselves, if they support LDAP like Jellyfin and Forgejo.

I don’t think you could do that directly in the Caddyfile, but you can create those groups/policies inside VoidAuth and assign them to users there.

The steps would be to (in VoidAuth) create the access group/policy, create the ProxyAuth Domain (protected.example.com/*) with the allowed group(s), make sure the user(s) have that group, then in Caddy add the forward_auth directive to the same route you want to protect.

Then when you go to access that route in a browser it will redirect you to VoidAuth login, or if you pass an Authentication header with Basic Auth (like when using an API) it will use that.

Yeah, I believe you don’t need to extend Caddy at all for that.

Add a properly-formatted Authorization header to any requests you make to the server and it’ll work. See Wikipedia page for header string format:

https://en.wikipedia.org/wiki/Basic_access_authentication

On the webpage side, I’d have the login form make a POST to your login endpoint using a basic auth header to pull a JWT that acts as a “real” auth key for other pages.

This is all assuming you want to stick with basic auth as opposed to a more heavyweight option.