Integrating with external authelia by forward_auth

[idavollen]

https://caddyserver.com/docs/caddyfile/directives/forward_auth as well as the Expand Form

# Serve the authentication gateway itself
auth.example.com {
	reverse_proxy authelia:9091
}

# Serve your app
app1.example.com {
	forward_auth authelia:9091 {
		uri /api/verify?rd=https://auth.example.com
		copy_headers Remote-User Remote-Groups Remote-Name Remote-Email
	}

	reverse_proxy app1:8080
}

This directive makes a GET request to the configured upstream with the uri rewritten:

If the upstream responds with a 2xx status code, then access is granted and the header fields in copy_headers are copied to the original request, and handling continues.
Otherwise, if the upstream responds with any other status code, then the upstream's response is copied back to the client. This response should typically involve a redirect to login page of the authentication gateway.

The above mentioned documentation is a bit absurb or difficult to understand. If the upstream responds with a 2xx status code, what is the mentioned upstream here? if it is the auth.example.com, its index page showing the Sign-in Web GUI page has already returned 200 as following:

Request URL:
https://authelia.example.com/?rd=https%3A%2F%2Ftraefik.example.com%2Frest%2Fhallos&rm=GET
Request Method:
GET
Status Code:
200 OK
Remote Address:
127.0.0.1:443
Referrer Policy:
strict-origin-when-cross-origin

Or if the upstream is the app1:8080, what if the app1:8080 backend doesn't well follow the security principle, implicit-deny or even has bad access control implementation? I'm looking forward to a clearly technical elaberation!

[francislavoie]

If the upstream responds with a 2xx status code, what is the mentioned upstream here?

I don't understand the question. What do you mean?

Caddy makes a virtual request behind the scenes to the forward auth server, asking it "is this user already authenticated or not?" a 2xx status means "yes already authenticated" so Caddy can move on with its HTTP handling to the next thing (e.g. reverse_proxy), and anything else (3xx, 4xx, 5xx) causes Caddy to serve that response as is, which is typically going to be a redirect to auth.example.com or whatever to display the login page.

Please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests. Don't forget to fill out the thread template so we can help you!

[idavollen]

Which particular URL will Caddy check the 2xx status? Which security mechanism is agreed between Caddy and Authelia for informing the concerned user is authenticated? via REMOTE-USER response header? Is it possible to bypass it or impersonate another one by a threat actor to manipulate these kind of REMOTE-XXXX headers? Any effective countermeasures?