Authentication Header Stripped in Requests via Unauthenticated Paths

[FirbyKirby]

Describe the bug
The authentication header appears to be erroneously stripped or rewritten in requests communicated via paths defined in a provider's unauthenticated paths field.

To Reproduce
Steps to reproduce the behavior:

1. Set up a service that requires API access authenticated via the authentication header. For my issue, I set up the docker service Miniflux. This application uses the Google Reader API which employs a custom authentication header auth scheme.
2. Set up a forward auth (single application) proxy provider for the service in Authentik.
3. Add the Google Reader API required paths to the unauthenticated paths field when setting up the authentik provider (for Miniflux, it would be ^/accounts/ClientLogin.* and ^/reader/api/.*
4. Attempt to communicate with the service via the unauthenticated paths. For miniflux, you can do the following steps:
5. Set up a Google Reader API username and password in Miniflux's integrations settings.
6. Execute the following command: curl -div 'https://<your service's URL>/accounts/ClientLogin?Email=&Passwd='
7. Get the "Auth" token from the previous command's response and edit the following command with it and then execute it:
   curl -iv -H "Authorization: GoogleLogin auth=" 'https://<your service's URL>/reader/api/0/user-info?output=json'
8. Observe the response. It should be an unauthorized response. You can also check the logs in Miniflux and you will see the error "No token provided."

Expected behavior
API access should work via unauthenticated paths, even if they send an authentication header. In the case of my example using Miniflux, the server should provide a response to the last command denoting information about the user.

Screenshots

Logs
Authentik logs show no change when executing the curl commands above. Miniflux shows the following (with personal info sanitized using template.)

06/03/2023 11:19:52 PM
[2023-06-03T23:19:52] [INFO] [GoogleReader][Login] [ClientIP=<myIP>] User authenticated: <user>
06/03/2023 11:19:52 PM
[2023-06-03T23:19:52] [INFO] [GoogleReader][Login] [ClientIP=<myIP>] Created token: <user>/<token>
06/03/2023 11:20:05 PM
[2023-06-03T23:20:05] [DEBUG] [HTTPS] <myIP> GET /reader/api/0/user-info?output=json
06/03/2023 11:20:05 PM
[2023-06-03T23:20:05] [ERROR] [GoogleReader][Auth] [ClientIP=<myIP>] No token provided
06/03/2023 11:20:05 PM
[2023-06-03T23:20:05] [ERROR] [HTTP:Unauthorized] /reader/api/0/user-info?output=json

Version and Deployment (please complete the following information):

• authentik version: 2023.5.3
• Deployment: Unraid via Docker (not docker-compose)

Additional context
If I remove the authentication header from the authResponseHeaders in my reverse proxy (Traefik,) the API exposed on the unauthenticated paths starts working (in this case, Google Reader API.) Adding the header back into the authResponseHeaders causes the issue to return.

This issue was first opened in the Authentik discord and additional information can be found there.

[authentik-automation]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[FirbyKirby]

I'd like to keep this open. It remains a bug I can't overcome.

[BeryJu]

Under the authentication settings of the provider you can disable this toggle

Also this behaviour should only occur when there is a session, and that toggle is enabled, and accessing an unauthorized path, when there is no session then the header is not changed, even with the toggle enabled