Nice idea, it was something I had in mind for a while! Technical implementation would require that Authelia sends the appropriate redirect instead, we should also create a specific react layout for the page so we can easily adjust it without affecting the main pages.

Hey! Been thinking about this for a while, would be keen to give it a crack.

Only thing I'm needing design assistance on is the networking behaviour. My thought is redirect to a 'Access Denied' page served on the same hostname as Authelia on webpage request, but on API requests still return the standard 403?

Looking for some input + opinions

I've got the front end mocked up, messy at the moment.
I've got a good idea where the redirect code belongs in the golang code (working around authelia_context.go)

Just wondering if maintainers have an idea of which direction to take? First two are relatively easy. Third one might be a bit more complicated with a react page, however probably meets the http code standards more accurately. Easy with a single html file but wheres the fun in that?

Redirected to login.example.com with basic page:

Redirected to login.example.com with

No redirect, 403 at deny.example.com:

Maybe for the sake of re-usability and translatability it would be beneficial to create a generic error path which takes an error_code in this instance the value would be error_code=access_denied which maps to the actual message itself.

The complication is always going to be how it's handled within each proxy. The flow particularly I think realistically we can redirect users in this instance to where they need to be, take a look at the more modern nginx examples for instance.

I'd originally been on the fence about doing that but sure thing

I'm not familiar with how nginx handles custom 403 pages that are more than a single html page, but I'll have a look around, I'll shout out if I need further clarification, thanks

Check out this file here: https://653ff4d88e4e120008fabca3--authelia-staging.netlify.app/integration/proxies/nginx/#authelia-authrequestconf

## Modern Method: Set the $redirection_url to the Location header of the response to the Authz endpoint.
auth_request_set $redirection_url $upstream_http_location;

## Modern Method: When there is a 401 response code from the authz endpoint redirect to the $redirection_url.
error_page 401 =302 $redirection_url;

## could be added
error_page 403 =302 $redirection_url;
``

I'm not 100% certain this will work for all proxies, but we've recently given ourselves the best chance possible to support all of them by including a separate implementation for each of them, part of the motivation was this particular use case I believe.

That's plenty for me to go on! I'm looking at the logs for the standalone suite trying to understand 401 -> 302 behaviour (so I can understand how 403 should work), Authelia logs say returning 401 but the browser is getting a 302. Good to know this is probably the proxy. I was hoping it would be a catch-all but I guess not... What's the general rule of thumb for developers supporting other proxies? If I got this working with the basic Nginx and possibly Envoy, should I also try with other suites before a PR? Just making sure I don't bite off more than I can chew...

I might take a look at my deployed Authelia logs to see what happens behind Istio/Envoy. Might be able to achieve a similar thing with an EnvoyFilter although I do see a lot of complaints about 403 status pages not being part of istio.

Kind of writing these here as public notes for later:

Possible Implementations with rewriting status codes from 403 to 302, not yet tested but to be explored:

NGINX as posted by @james-d-elliott above:

Check out this file here: https://653ff4d88e4e120008fabca3--authelia-staging.netlify.app/integration/proxies/nginx/#authelia-authrequestconf

## Modern Method: Set the $redirection_url to the Location header of the response to the Authz endpoint.
auth_request_set $redirection_url $upstream_http_location;

## Modern Method: When there is a 401 response code from the authz endpoint redirect to the $redirection_url.
error_page 401 =302 $redirection_url;

## could be added
error_page 403 =302 $redirection_url;
``

Envoy:
Using a mapper, including the Location header

Istio:
Modify the statusOnError field to be 302 and add location header to headersToDownstreamOnDeny

Caddy:
Similar to the @good status 2xx, use a @forbidden status 403 that modifies the status code and passes the location downstream.

Haven't looked into any others but figured its a good start

Regarding HAProxy: this serverfault post talks about redirecting when a 404 is received by backend. I guess this would work also for 403 and/or 401.

listen fe
  bind 0.0.0.0:82
  acl not_allowed status 403
  http-response redirect code 302 location https://google.fr if not_allowed
  server server1 127.0.0.1:80 check

I believe this needs to be modified slightly because you should be looking at the status code received from haproxy-auth-request which is stored as txn.auth_response_code.

Regarding HAProxy: this serverfault post talks about redirecting when a 404 is received by backend. I guess this would work also for 403 and/or 401.

listen fe
  bind 0.0.0.0:82
  acl not_allowed status 403
  http-response redirect code 302 location https://google.fr if not_allowed
  server server1 127.0.0.1:80 check

When you first replied it completely jumped over me that it was your issue originally,

I've got this working in the standalone (NGINX based) suite. Needs a decent amount of cleaning up before it's ready so could still be a month or two away, but I am slowly chipping away now that I've got the design + logic figured out.

I'll give the HAProxy suite a crack next since there's no istio suite to test for my environment, then I'll post and get your feedback :)