Basic Arr Auth Not Working

adamzvolanek commented 1 year ago

Describe the bug I followed the respective sonarr documentation/instructions and at a loss why it continues to prompt for username and password in a freshly cleared of history/cookies, etc. Chrome incognito browser.

Included in the screenshot section is my setup.

To Reproduce Steps to reproduce the behavior:

Sign into my Authentik instance as my user who is in the arr users group with the correct attributes.
Select Sonarr
Have browser dialog box appear prompting for username and password.

Expected behavior I expect the HTTP-Basic Username/Password Key's to be used for authentication.

Screenshots Here is my Proxy Provider

Group attributes and member account tied

Sonarr setup

Version and Deployment (please complete the following information):

authentik version: 2022.12
Deployment: docker via Unraid template

pbvdven commented 1 year ago

did you add the group to the application? i set it up for prowlarr today and it works fine.

adamzvolanek commented 1 year ago

did you add the group to the application? i set it up for prowlarr today and it works fine.

The group of an application does not tie to the groups made in the directory. Application groups are just for organization of applications.

pbvdven commented 1 year ago

No not that group on the application tab choose sonarr then there is a tab groups

BeryJu commented 1 year ago

You don't have to bind the group with these attributes to the application, however I'm not sure if it works correctly when the user logging in isn't a direct member of the group with the attributes (as the screenshot you posted it looks like you have an Admin group as part of that group)

The other thing to make sure is that you log out of the application you're making this change to, as these attributes are only transferred on login

adamzvolanek commented 1 year ago

however I'm not sure if it works correctly when the user logging in isn't a direct member of the group with the attributes (as the screenshot you posted it looks like you have an Admin group as part of that group)

I do not have an admin group assigned, it reads 'Adam'. Likewise the Arr User's group is on it's own with no parent group.

I've been testing this by restarting the sonarr docker container, entering incognito on my browser. Signing into my authentik.domain.tld, and using the dashboard to 'jump' to sonarr.

No not that group on the application tab choose sonarr then there is a tab groups

I'll be honest, I can't find that page on my Authentik setup. I've checked Applications --> Applications which is the same screenshot as above. Applications --> Providers which allows me to update the proxy provider, and lastly Applications --> Outposts... which I don't think is related, though I verified that Sonarr is selected.

I found the setting, it hasn't changed from what is shown:

adamzvolanek commented 1 year ago

I've also tried flipping between Proxy and Forward Auth in terms of providers. Sonarr does sit behind an nginx proxy, however continues to be basic auth. Currently setting the Sonarr Proxy Provider to Proxy is the only way to reach sonarr without receiving a 500 internal server error.

Can this still be achieved with only Proxy? The reason I ask is because I have to Nginx Proxy Managers, one for external access and one for internal. The internal nginx proxy manager being on a different ip address than what Authentik runs on. Perhaps this is affecting my outposts? Though I did update the Setup of Nginx Proxy Manager to include the correct IP address:

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
    proxy_pass              http://auth.domain.tld/outpost.goauthentik.io;
CHANGED TO: https://NPM_IP:Port/outpoost...
    # ensure the host of this vserver matches your external URL you've configured
    # in authentik
    proxy_set_header        Host $host;
    proxy_set_header        X-Original-URL $scheme://$http_host$request_uri;
    add_header              Set-Cookie $auth_cookie;
    auth_request_set        $auth_cookie $upstream_http_set_cookie;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
    internal;
    add_header Set-Cookie $auth_cookie;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    # For domain level, use the below error_page to redirect to your authentik server with the full redirect path
    # return 302 https://auth.domain.tld/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
CHANGED TO https://NPM_IP?outpost....
}

This change is required to allow other applications I have running to work behind Nginx.

davbay1 commented 1 year ago

I'm having the same issue. Can't seem to figure out why basic auth isn't being passed through. Any help would be appreciated.

adamzvolanek commented 1 year ago

I'm having the same issue. Can't seem to figure out why basic auth isn't being passed through. Any help would be appreciated.

If you're using traefik this may help: https://github.com/goauthentik/authentik/issues/4379#issuecomment-1374420008

davbay1 commented 1 year ago

I'm having the same issue. Can't seem to figure out why basic auth isn't being passed through. Any help would be appreciated.

If you're using traefik this may help: #4379 (comment)

Nope NPM. I just got everything else working.

I have the following setup. Reverse proxy through NPM and Cloudflare. The auth portion is working great, but can't seem to pass through basic auth.

samip5 commented 1 year ago

@adamzvolanek Which Sonarr version are you on? You do know the latest is v4 that's in beta that has better support for things like this right?

adamzvolanek commented 1 year ago

@adamzvolanek Which Sonarr version are you on? You do know the latest is v4 that's in beta that has better support for things like this right?

I did not know that, but I'll ask: why do you think it's an issue on the Sonarr end? Do you have V4 and it working for you?

I checked, my sonarr is using linuxservers flavor of it but not the develop branch (V4). I generally don't update that often for the old "if it ain't broke, don't fix it" mantra.

samip5 commented 1 year ago

@adamzvolanek Which Sonarr version are you on? You do know the latest is v4 that's in beta that has better support for things like this right?

I did not know that, but I'll ask: why do you think it's an issue on the Sonarr end? Do you have V4 and it working for you?

I checked, my sonarr is using linuxservers flavor of it but not the develop branch (V4). I generally don't update that often for the old "if it ain't broke, don't fix it" mantra.

I'm just saying to Sonarr that my auth is external and it disables its own thing and relies on my forward auth. If auth backend doesn't respond, my Traefik will just error with 500.

adamzvolanek commented 1 year ago

I tried the same credentials with radarr given it is updated to V4, and it resembles the same behavior as sonarr.

ZuluWhiskey commented 1 year ago

You look to have everything set up correctly from what I can see - Are you 100% sure you have the username and password correct for Sonarr? I just tested on my side and replicated your issue for my setup that was working flawlessly: I added an extra character to my password configured for my Sonarr group in Authentik (to make the pw incorrect), cleared my cookies on my Sonarr domain, refreshed the page and then was met with Sonarr's basic login popup.

To fix it, I changed the password back, cleared cookies, refreshed the page and got straight in as previously.

It sounds like Authentik is configured right for you as you're getting to Sonarr once authenticating via Authentik.

Check your Sonarr logs - I got this when I set the wrong password:

2023-01-20 16:11:22.3|Warn|Auth|Auth-Failure ip $IP username '$username'
2023-01-20 16:11:23.8|Info|Auth|Auth-Unauthorized ip $IP url 'http://sonarr...'

adamzvolanek commented 1 year ago

Are you 100% sure you have the username and password correct for Sonarr? I just tested on my side and replicated your issue for my setup that was working flawlessly: I added an extra character to my password configured for my Sonarr group in Authentik (to make the pw incorrect), cleared my cookies on my Sonarr domain, refreshed the page and then was met with Sonarr's basic login popup.

I went ahead and also... I would be happy to test this case, however for both sonarr (version 3) and radarr (version 4) they both stop at the same point, where the basic-auth. browser pop-up appears and nothing is 'entered'.

I changed the password to something different, cleared cookies, refreshed the page and got the same prompt.

Looking through the radarr logs I see...

2023-01-20 21:13:45.9|Info|Radarr.Http.Authentication.BasicAuthenticationHandler|Basic was not authenticated. Failure message: Authorization header missing.
2023-01-20 21:13:45.9|Info|Radarr.Http.Authentication.BasicAuthenticationHandler|AuthenticationScheme: Basic was challenged.
...
2023-01-20 21:18:27.5|Trace|Http|Res: 6738 [GET] /: 401.Unauthorized (3 ms)

Is this some browser setting? Chrome, Edge, and Firefox all give the same result in incognito.

ZuluWhiskey commented 1 year ago

Okay, interesting... In your original bug report you mention your method for accessing Sonarr is to go via Authentik > Click the link to the Sonarr application > You get the popup

What happens when you attempt to get to Sonarr via its URL without using the link in the Authentik GUI? (In incognito mode). Do you get the Authentik login prompt?

Edit: If you do get a login prompt then all good, just making sure the reverse proxy aspect is working. I can see in your Internal Host on the Proxy Provider you have set it to http://sonarr:8989 (or whatever port), do you use docker-compose? If so, is your Authentik container on the same docker network as Sonarr? If not, Authentik can't reach Sonarr via this hostname and you'll need to either set up a dedicated docker network or use your private IP address for your server (192.168.1.x:8989 or whatever)

adamzvolanek commented 1 year ago

What happens when you attempt to get to Sonarr via its URL without using the link in the Authentik GUI? (In incognito mode). Do you get the Authentik login prompt?

No, it goes directly to the container and prompts for login with the html pop-up. I did put in the authentik nginx (Proxy Manager) setup into my nginx container, modified lines 41 and 59 similar to other containers and now getting a 500 server error.

Authentik is on the same docker network, I have other containers that are redirecting properly though do not have basic-auth.

Update: I modified my Nginx DNS and now it is re-directing to authentik, however the pop-up still appears asking for password. Logs show the same:

2023-01-21 09:40:24.1|Info|Radarr.Http.Authentication.BasicAuthenticationHandler|Basic was not authenticated. Failure message: Authorization header missing.
2023-01-21 09:40:24.1|Info|Radarr.Http.Authentication.BasicAuthenticationHandler|AuthenticationScheme: Basic was challenged.

ZuluWhiskey commented 1 year ago

I have no clue then to be honest - The only other thing I would suggest is to create an app specific user group (rather than your generic Arr one) to see if that's causing any issues. That's the only thing I can think of that's different to my setup that is working

adamzvolanek commented 1 year ago

I have no clue then to be honest - The only other thing I would suggest is to create an app specific user group (rather than your generic Arr one) to see if that's causing any issues. That's the only thing I can think of that's different to my setup that is working.

It's a long shot, but would you be willing to do a Discord call to perhaps walk through my setup and let me know where I may differ?

davbay1 commented 1 year ago

I have no clue then to be honest - The only other thing I would suggest is to create an app specific user group (rather than your generic Arr one) to see if that's causing any issues. That's the only thing I can think of that's different to my setup that is working.

It's a long shot, but would you be willing to do a Discord call to perhaps walk through my setup and let me know where I may differ?

I found a workaround to get it working. The issue has something to do with the Advanced Config that needs to be entered into NPM. (No clue on what changes need to be made within the config to allow Basic Auth to work) However, we can bypass that by choosing to setup the apps in "Proxy" mode instead of "Forward Auth". Not totally sure what difference those modes really make down the line.

In proxy mode, input the local IP in the internal host field and uncheck Internal host SSL verification.

After that in NPM remove the Advanced Custom Config for the app and set the app forward port to your authentik port.

Once I did all of that, it immediately passed the authentication through.

zackchadwick commented 1 year ago

I had the same issue described here but I make use of the nginx ingress controller in Kubernetes.

I imagine a similar fix would work for you, although I haven't used NPM before. I just needed to add authorization to the list of auth response headers that was generated by the Provider config in Authentik.

nginx.ingress.kubernetes.io/auth-response-headers:
  Set-Cookie,X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,authorization

adamzvolanek commented 1 year ago

nginx.ingress.kubernetes.io/auth-response-headers: Set-Cookie,X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,authorization

I tried going down this route before, but was not sure where to put the headers in NPM. So far I haven't seen others that needed to do this, but I'd be surprised if I am the only one with a similar configuration with Authentik.

zackchadwick commented 1 year ago

I actually spoke too soon; that seemed to work for Radarr and Sonarr, both of which were seeing intermittent basic auth prompts, but Prowlarr continues to prompt even with that change.

Looking at the Prowlarr logs it appears that it's getting something as a header, but it's stating wrong username/password, even when I type it in manually at the prompt and know it's correct. If I remove the auth forwarding from my ingress it does accept it without issue. Presumably, there's something missing from the annotations for Prowlarr in particular regarding auth.

As a workaround, you can set Prowlarr to External auth mode in the config file and it won't require any prompt since it's securely behind Authentik. Personally, I'd prefer to have the basic auth working as a backup though.

Ref: https://wiki.servarr.com/prowlarr/faq#can-i-disable-forced-authentication

davbay1 commented 1 year ago

I was inspired by @zackchadwick to try figuring out the "Forward Auth" method using auth-response-headers and I found it.

@adamzvolanek Give it a go.

# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
auth_request_set $authentik_auth $upstream_http_authorization;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header Authorization $authentik_auth;
}

Add auth_request_set $authentik_auth $upstream_http_authorization; to the end of the first part. Then add proxy_set_header Authorization $authentik_auth; to the second part.

zackchadwick commented 1 year ago

Thanks, @davbay1, I'll have to see how those translate into Kubernetes ingress annotations and I'll be set as well, hopefully.

davbay1 commented 1 year ago

Thanks, @davbay1, I'll have to see how those translate into Kubernetes ingress annotations and I'll be set as well, hopefully.

I had to make one additional change for it to work in NPM. Not sure how it will apply in Kubernetes.

@adamzvolanek As a heads up, in NPM I also had to turn off "Cache Assets" in the edit proxy host popup in the details cache.

zackchadwick commented 1 year ago

I figured out how to add those extra headers and it did not solve the issue, however, it started giving me a base64 error with Prowlarr.

That led me to play around with some things and come to the conclusion that this was an issue with my Ingress configuration from the start.

The Ingress I was using has existed for quite some time and wasn't using the spec: ingressClassName: nginx format but the old annotation style. Simply removing those extra headers and defining that ingressClassName seems to have resolved the issue for me. I'm no longer receiving the pop-up when using the Authentik provided ingress configuration, and I can see successful basic auth in the Prowlarr logs.

Lesson learned!

stale[bot] commented 1 year ago

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.

romprod commented 1 year ago

I was inspired by @zackchadwick to try figuring out the "Forward Auth" method using auth-response-headers and I found it.

@adamzvolanek Give it a go.

# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
auth_request_set $authentik_auth $upstream_http_authorization;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header Authorization $authentik_auth;
}

Add auth_request_set $authentik_auth $upstream_http_authorization; to the end of the first part. Then add proxy_set_header Authorization $authentik_auth; to the second part.

I just wanted to add that this fixed it for me for radarr at least, I'll try the rest of the *arr applications shortly. I guess the NPM config bit needs updating in Authentik to include those two lines.

adamzvolanek commented 1 year ago

I was inspired by @zackchadwick to try figuring out the "Forward Auth" method using auth-response-headers and I found it.

@adamzvolanek Give it a go.
# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;
auth_request_set $authentik_auth $upstream_http_authorization;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header X-authentik-uid $authentik_uid;
proxy_set_header Authorization $authentik_auth;
}
Add auth_request_set $authentik_auth $upstream_http_authorization; to the end of the first part. Then add proxy_set_header Authorization $authentik_auth; to the second part.
I just wanted to add that this fixed it for me for radarr at least, I'll try the rest of the *arr applications shortly. I guess the NPM config bit needs updating in Authentik to include those two lines.

I'm a bad person and forgot to follow-up. My arr family of apps are working, I'll post my configuration soon (TM) so others can follow suit.

Soon being today/tomorrow.

adamzvolanek commented 1 year ago

To finally close out this thread, here is my configuration for sonarr and radarr, both using basic auth via Authentik.

At an Unraid docker scope, they are running in my docker network.

Authentik Configuration

A provider for each and an application for each.
Both enabled in the Application Outpost
Providers Configuration:
- Authorization Flow: implicit
- Forward auth
- CNAME from my domain
- Authentication Settings
- Both 'Intercept header authentication' and 'Send HTTP-Basic Authentication' are enabled/checked
- HTTP-Basic Username: sonarr_user
- HTTP-Basic Password Key: sonarr_password.
I created a Group for arr items (Directory --> Group)
- Attributes of them include: sonarr_user: username and sonarr_password: password.
- There are setup as the username and password for sonarr and radarr in this example as they are under the 'Arr User Group'
- The naming of the attribute just happens to be sonarr_user...

Nginx Proxy Manager

Replace line 48 with your Authentik's docker:port endpoint.
- proxy_pass http://outpost.company:9000/outpost.goauthentik.io; -> proxy_pass https://<docker_name>:<docker_port>/outpost.goauthentik.io;
As mentioned in https://github.com/goauthentik/authentik/issues/4381#issuecomment-1457438495 add the headers. My configuration looks appears as follows:


# translate headers from the outposts back to the actual upstream
auth_request_set $authentik_username $upstream_http_x_authentik_username;
auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
auth_request_set $authentik_email $upstream_http_x_authentik_email;
auth_request_set $authentik_name $upstream_http_x_authentik_name;
auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

Added

auth_request_set $authentik_authorization $upstream_http_authorization;

proxy_set_header X-authentik-username $authentik_username;
proxy_set_header X-authentik-groups $authentik_groups;
proxy_set_header X-authentik-email $authentik_email;
proxy_set_header X-authentik-name $authentik_name;
proxy_set_header X-authentik-uid $authentik_uid;

Added

 proxy_set_header Authorization $authentik_authorization;

}



In NPM, create a Proxy Host pointed to your respective arr family container on its basic HTTP port. **Do not** select 'Cache Assets'. Setup NPM as you would normally otherwise and paste in your modified configuration file. Repeat the steps for other arr family products, no need to modify the template.

I hope this helps everyone in the future, the issue is already closed at the time of writing, but I also type this up for my own sanity.

Supporting images:

<details><summary>Expand for images</summary>

### Application

![image](https://github.com/goauthentik/authentik/assets/80661527/910c9e6e-4ee8-4112-a960-d7855b56b88f)

### Proxy Provider

![image](https://github.com/goauthentik/authentik/assets/80661527/5d74bc46-c414-44b7-8789-057d66f74264)

### Comparison of NPM Template

![image](https://github.com/goauthentik/authentik/assets/80661527/8f4220af-1b73-4616-ba3c-6d067cc768e0)

</details>

pippobimbo commented 9 months ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

amlucent commented 8 months ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

This is the way.

https://wiki.servarr.com/prowlarr/faq#can-i-disable-forced-authentication

cpuks commented 7 months ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

But it disables auth so anyone in local network can access sonarr/radarr/prowlarr - it's not a solution TBH.

krstn420 commented 6 months ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

But it disables auth so anyone in local network can access sonarr/radarr/prowlarr - it's not a solution TBH.

you can also choose to not expose the port of *arr dockers

funkyapple commented 6 months ago

I had the same issue described here but I make use of the nginx ingress controller in Kubernetes.

I imagine a similar fix would work for you, although I haven't used NPM before. I just needed to add authorization to the list of auth response headers that was generated by the Provider config in Authentik.
nginx.ingress.kubernetes.io/auth-response-headers:
  Set-Cookie,X-authentik-username,X-authentik-groups,X-authentik-email,X-authentik-name,X-authentik-uid,authorization 

This worked for me.

mgundelfinger commented 6 months ago

I hope this helps everyone in the future, the issue is already closed at the time of writing, but I also type this up for my own sanity.

Thank you so much, this needs to be added to the documentation, and honestly also to the source code. I don't know how to go about that, but in any case, this finally made my basic auth apps work!

EphoxiaGit commented 5 months ago

I have a new problem related to this, I added the headers which seeemed to fix everyone elses issue, but for me it makes the login prompt pop up like before the fix, but this time no matter what i put it will not log in. if i try all i get is

2024-04-12 20:21:07.8|Info|Sonarr.Http.Authentication.BasicAuthenticationHandler|Basic was not authenticated. Failure message: The username or password is not correct. 2024-04-12 20:21:07.8|Info|Sonarr.Http.Authentication.BasicAuthenticationHandler|AuthenticationScheme: Basic was challenged.

I followed the config adamzvolanek posted in the comments, in my group i set arr_pw: 1937 arr_usr: admin as a test. under sonarr provider "Intercept header authentication" and "Send HTTP-Basic Authentication" is enabled and under "HTTP-Basic Username Key" and password i put "arr_usr" and "arr_pw" respectively. But sonarr logs still say username or password is not correct. If i remove the headers i can atleast login using the prompt as normal.

This is my NGINX config:

enscott89 commented 4 months ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

Thank you so much! Working after doing this and implementing adam's changes too

adamzvolanek commented 4 months ago

I followed the config adamzvolanek posted in the comments, in my group i set arr_pw: 1937 arr_usr: admin as a test. under sonarr provider "Intercept header authentication" and "Send HTTP-Basic Authentication" is enabled and under "HTTP-Basic Username Key" and password i put "arr_usr" and "arr_pw" respectively. But sonarr logs still say username or password is not correct. If i remove the headers i can atleast login using the prompt as normal.

I've since stopped hosting my arr family in a subdomain, however here is my previously working configuration under the "Advanced" tab in Nginx Proxy Manager.

# Increase buffer size for large headers
# This is needed only if you get 'upstream sent too big header while reading response
# header from upstream' error when trying to access an application protected by goauthentik
proxy_buffers 8 16k;
proxy_buffer_size 32k;

# Make sure not to redirect traffic to a port 4443
port_in_redirect off;

location / {
    # Put your proxy_pass to your application here
    proxy_pass          $forward_scheme://$server:$port;
    # Set any other headers your application might need
    # proxy_set_header Host $host;
    # proxy_set_header ...

    ##############################
    # authentik-specific config
    ##############################
    auth_request     /outpost.goauthentik.io/auth/nginx;
    error_page       401 = @goauthentik_proxy_signin;
    auth_request_set $auth_cookie $upstream_http_set_cookie;
    add_header       Set-Cookie $auth_cookie;

    # translate headers from the outposts back to the actual upstream
    auth_request_set $authentik_username $upstream_http_x_authentik_username;
    auth_request_set $authentik_groups $upstream_http_x_authentik_groups;
    auth_request_set $authentik_email $upstream_http_x_authentik_email;
    auth_request_set $authentik_name $upstream_http_x_authentik_name;
    auth_request_set $authentik_uid $upstream_http_x_authentik_uid;

## Added
    auth_request_set $authentik_authorization $upstream_http_authorization;

    proxy_set_header X-authentik-username $authentik_username;
    proxy_set_header X-authentik-groups $authentik_groups;
    proxy_set_header X-authentik-email $authentik_email;
    proxy_set_header X-authentik-name $authentik_name;
    proxy_set_header X-authentik-uid $authentik_uid;

## Added
     proxy_set_header Authorization $authentik_authorization;

}

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
    proxy_pass              https://authentik:9443/outpost.goauthentik.io;
    # ensure the host of this vserver matches your external URL you've configured
    # in authentik
    proxy_set_header        Host $host;
    proxy_set_header        X-Original-URL $scheme://$http_host$request_uri;
    add_header              Set-Cookie $auth_cookie;
    auth_request_set        $auth_cookie $upstream_http_set_cookie;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
}

# Special location for when the /auth endpoint returns a 401,
# redirect to the /start URL which initiates SSO
location @goauthentik_proxy_signin {
    internal;
    add_header Set-Cookie $auth_cookie;
    return 302 /outpost.goauthentik.io/start?rd=$request_uri;
    # For domain level, use the below error_page to redirect to your authentik server with the full redirect path
    # return 302 https://authentik.company/outpost.goauthentik.io/start?rd=$scheme://$http_host$request_uri;
}

Note my,

# all requests to /outpost.goauthentik.io must be accessible without authentication
location /outpost.goauthentik.io {
    proxy_pass              https://authentik:9443/outpost.goauthentik.io;

reads only 'authentik` since it is in the same docker network on my Unraid server.

AblabiX commented 4 months ago

with traefik+authentik i was able to work the Basic Auth only with traefik dashboard access and Bazarr the rest of the Arr all external as auth setting.

excaliburzarau commented 3 months ago

Hello guys,

I am using Caddy as a reverse proxy, Just added the Authorization header to my caddy and the issue was resolved. The credentials are passed properly, even in incognito mode.

Best Regards

speedyconzales commented 3 months ago

you are all making sure that in sonarr or whatever arr, you set the authentication to basic, not forms. Right? and surely using external... is like None. So you would not need something like authentik anyway if you plan to just skip authentication entirely. so please don't do that either

excaliburzarau commented 3 months ago

you are all making sure that in sonarr or whatever arr, you set the authentication to basic, not forms. Right? and surely using external... is like None. So you would not need something like authentik anyway if you plan to just skip authentication entirely. so please don't do that either

Hello,

I believe that is irrelevant for the concept itself. Yes, the Arr web apps do support a Basic authentication without form but i believe that the idea would Be to ensure the undersranding of the concept to other applications that behave the same way for http Basic authentication and relate the issue. It worked for my use case and it is behaving as expected. Hopefully it Will help someone else.

Cheers

jtitley commented 1 month ago

I experienced the same issue with Sonarr. Solved it using « external » as authentication method in Sonarr config file.

This seems to be the simplest and best approach.

goauthentik / authentik