You'd have FusionAuth issue the tokens through an authentication event (typically the authorization code grant for interactive sessions). Lots of flows with sequence diagrams outlined here [0].

Then store the tokens on the client. For browsers dealing with first party apps (everything under the same domain) we recommend cookie storage of these tokens [1].

Then have Caddy examine the tokens provided by the browser. Here's an example Caddy config I put together for a workshop [2].

Finally, depending on your security posture, you might want to verify tokens both in app and at the proxy.

0: https://fusionauth.io/articles/login-authentication-workflow...

1: https://fusionauth.io/articles/oauth/oauth-token-storage

2: https://github.com/FusionAuth/fusionauth-example-php-api-wor...

Hey one of the Authelia developers here. Authelia works out of the box with Caddy's forward auth directive. In fact I helped Caddy develop and test the feature to ensure it had feature parity with an existing implementation/spec.

You have very granular options to customize the experience allowing multiple sites to have the same or different rules, which can alter the authentication requirements based on remote ip, users, groups, paths, domains, etc.