Forward Authentication & Redirect

[Javex]

Hi! I'm new to Authentik and have been setting it up in my homelab over the last few days. Integrating applications via OIDC has been a breeze, but I've been struggling with forward authentication. My goal is put some of my applications on the internet, but require authentication before a user can even see the page. Because I don't require any information about the user at this stage, domain-based forward authentication seemed like the right choice here.

I did manage to set this up in Authentik by creating a Proxy Provider called "Caddy" (my reverse proxy) and selecting domain level forward auth. I've set the cookie domain to be the TLD for the applications I want to expose. This all works quite well, but I realised that the redirect_uri is always Authentik itself, e.g. auth.example.com when I try to access app1.example.com.

Because this seems like a limitation of domain level forward auth, I switched to single application forward auth by creating a new provider called "Caddy for App 1". This allowed me to set a redirect URL. I then associated my application with this provider and re-enabled it in the outpost (which seems to be by-provider, not application).

However, now Authentik reports a 404 for https://auth.example.com/outpost.goauthentik.io/auth/caddy. I've experimented with various setups, but I cannot fix the 404 unless I go back to the old domain level provider and fix the outpost config again. From the docs it is not clear whether the /caddy value at the end is fixed or depends on the provider name.

Here is my Caddy config:

@app1 host app1.example.com
handle @app1 {
        # directive execution order is only as stated if enclosed with route.
        route {
	        # always forward outpost path to actual outpost
	        reverse_proxy /outpost.goauthentik.io/* https://auth.example.com {
		        header_up Host {http.reverse_proxy.upstream.host}
	        }
        
	        # forward authentication to outpost
	        forward_auth https://auth.example.com {
		        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
        
		        # optional, in this config trust all private ranges, should probably be set to the outposts IP
		        trusted_proxies private_ranges
	        }
        }

	# actual site configuration
	reverse_proxy app1:3000
}

My configuration in Authentik:

• One application "App 1"
• Two providers
  • "Caddy" which is a domain level forward proxy
  • "Caddy for App 1" which is a single app forward proxy
• Integrated Outpost with "App 1" enabled

Here's what I've tried:

• Changed the slug on "App 1" to "caddy" (no effect)
• Moved "App 1" between providers (it only works if associated with "Caddy")
• Renamed the endpoint for the outpost to "/caddy-for-app-1" trying to guess a slug

None of these things help and I'm a bit stuck. What am I doing wrong?

[Marcus1Pierce]

Is the error you experienced when logging into the website like this?

If so, I also experienced the same thing. And the method that worked for me to overcome it was changing the Caddy config from:

app.company {
    # directive execution order is only as stated if enclosed with route.
    route {
        # always forward outpost path to actual outpost
        reverse_proxy /outpost.goauthentik.io/* https://sso.domain.tld {
            header_up Host {http.reverse_proxy.upstream.hostport}
        }

        # forward authentication to outpost
        forward_auth http://authentik:9000 {
            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

            # optional, in this config trust all private ranges, should probably be set to the outposts IP
            trusted_proxies private_ranges
        }

        # actual site configuration below, for example
        reverse_proxy 100.111.126.34:8080
    }
}

to:

app.company {
        # always forward outpost path to actual outpost
        reverse_proxy /outpost.goauthentik.io/* https://sso.domain.tld {
            header_up Host {http.reverse_proxy.upstream.hostport}
        }

        # forward authentication to outpost
        forward_auth http://authentik:9000 {
            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

            # optional, in this config trust all private ranges, should probably be set to the outposts IP
            trusted_proxies private_ranges
        }

        # actual site configuration below, for example
        reverse_proxy 100.111.126.34:8080
}

I deleted the route and everything ran normally. But I'm not sure if there will be any security issues or not after deleting that route.

[Javex]

The docs say route is there to enforce ordering. That is, if you don't have this parameter Caddy is free to reorder your routes in the way it thinks is best. This could mean that the forward_auth block gets processed after the reverse_proxy statement. I'm no expert on this topic, but this does seem like a security risk.

[Marcus1Pierce]

You're right. The reverse_proxy can be bypassed without going through the forward_auth first. Lucky for me, I only allow IPs from the VPN. It's like something is missing or wrong with the docs, but I'm not sure what it is.

[Marcus1Pierce]

Oh I forgot to mention. Another config that worked, aside from removing the route, is the following:

app.company {
    # directive execution order is only as stated if enclosed with route.
    route {
        # always forward outpost path to actual outpost
        reverse_proxy /outpost.goauthentik.io/* http://authentik:9000 {
            header_up Host {http.reverse_proxy.upstream.hostport}
        }

        # forward authentication to outpost
        forward_auth http://authentik:9000 {
            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

            # optional, in this config trust all private ranges, should probably be set to the outposts IP
            trusted_proxies private_ranges
        }

        # actual site configuration below, for example
        reverse_proxy 100.111.126.34:8080
    }
}

If the reverse proxy set to http://authentik:9000 , the website can be opened normally.