Authentik is an identity provider that provides centralized user authentication. This allows me to support SSO and centralized user management.

Authentik can be installed on Docker Compose by following the instructions here. This involves setting a few environment variables (password, secret key, ports, etc.) and downloading the latest Docker Compose file from their website. The guide includes instructions for configuring all environment variables; however, the config I use (with secrets redacted) can be found here.

After initial installation and admin user setup (per the guide), Caddy can be redirected to point to the Authentik server as normal (see the example Caddyfile). This allows Authentik to be accessed via reverse proxy.

Authentik can be used along with a reverse proxy (in this case, Caddy) to protect sites that don't have any other form of authentication (or to add an additional layer). This is done with a mechanism called "forward auth" where authentication and authorization is delegated to a trusted third party, in this case Authentik.

This can be setup by adding the following to a site block in Caddy:

# Always forward outpost path to actual outpost
reverse_proxy /outpost.goauthentik.io/* <internal_ip:port>

# Forward authentication to outpost
forward_auth <internal_ip:port> {
    uri /outpost.goauthentik.io/auth/caddy

    # Capitalization of the headers is important, otherwise they will be empty
    copy_headers X-Authentik-Username X-Authentik-Groups X-Authentik-Email X-Authentik-Name X-Authentik-Uid X-Authentik-Jwt X-Authentik-Meta-Jwks X-Authentik-Meta-Outpost X-Authentik-Meta-Provider X-Authentik-Meta-App X-Authentik-Meta-Version

    trusted_proxies <internal_ip>
}

Note that the <internal_ip:port> and <internal_ip> should be the internal IP and/or port of the Authentik server/outpost and not the address through the reverse proxy. For example, it could be 10.10.10.10:9000 if that is where Authentik is running. Also note that a Caddy snippet can be used to set this up once and then import for each site that you would like to password protect. This reduces repeated config and makes it easier to change the Authentik IP in the future. See my Caddyfile for an example. Make sure the Caddyfile is reloaded after making these changes.

With the Caddy config updated, an Application and a Provider need to be created in the Authentik admin interface. These have a 1:1 mapping so can be created together. Do this by going to Applications > Applications in the left navigation bar and clicking Create With Wizard. The Name and Slug on the first page can be whatever descriptive name you would like. You can also set the Policy engine mode here to your preference.

On the next page (Provider Type), select Forward Auth (Single Application). Click Next and then select your desired Authentication flow and Authentication flow (default and explicit consent, respectively, are good options), and type the address of the host that you would like to protect with Authentik in the External host field. This will be the address that goes through your reverse proxy. For me, this is something like https://test.brew.foo. With this filled out, you can click Submit.

Not go to Applications > Outposts in the side panel and click the edit icon next to the embedded outpost. Highlight all of the Applications you'd like to use in the Available Applications column and use the right arrow button to transfer them to the Selected Applications (or hit the double arrow to add all of them without needing to select). These applications should now be enabled on this outpost and have check marks next to them. Before clicking Update, expand the Advanced settings and change the authentik_host field to the name of the Authentik host through your reverse proxy (see my Caddyfile for an example of putting Authentik behind the reverse proxy). For me, this looks like authentik_host: https://authentik.brew.foo. This should have the same domain name as the site(s) being protected. Now you can click Update.

At this point, you should be able to visit the site being protected and be redirected to a login page (it is easiest to test this in an Incognito window so you don't have to sign out of Authentik first). Login with the akadmin credentials and you should be taken to your application after providing explicit consent for the application.

Additional users can be created under Directory > Users > Create. After creating a user, expand the dropdown next to it and click the Set Password button to set an initial password and enable login. Groups can then be created under Directory > Groups > Create. Click on the group name after creating it and go to Users at the top in order to add users to that group.

By default, all users can access all apps. If you'd like to setup more specific permissions, you can do that by going to Applications > Applications and clicking on the name of the application you want to modify. Click on Policy / Group / User Bindings at the top and then click Create Binding. Select the appropriate type (User or Group) in the resulting dialog and then select the user or group you'd like to allow. Then click Create.

In order to setup email transport using Gmail, the following should be appended to your .env file:

# Email configuration
AUTHENTIK_EMAIL__HOST=smtp.gmail.com
AUTHENTIK_EMAIL__PORT=465
[email protected]
AUTHENTIK_EMAIL__PASSWORD=<redacted>
# Use StartTLS
AUTHENTIK_EMAIL__USE_TLS=false
# Use SSL
AUTHENTIK_EMAIL__USE_SSL=true
AUTHENTIK_EMAIL__TIMEOUT=10
# To change the sender's display name, use a format like `Name <account@domain>`
AUTHENTIK_EMAIL__FROM=Authentik <[email protected]>

With [email protected] replaced with your email address and <redacted> replaced with an app password.

After these changes are made, the Docker compose stack should be restarted and the following command can be used from the Docker host to send a test email to ensure that everything was configured correctly:

docker compose exec worker ak test_email [email protected]

The test email can also be sent using the Test button (looks like a test tube) next to the default-email-transport under Events > Notification Transports in the Admin Interface of the web UI. Before sending a test via the UI, the logged-in user's email address must be set under Directory> Users.

This is useful for email-based flows (such as password resets) and for setting up notifications.