Support Navidrome behind a OIDC protected reverse proxy

[enticedwanderer]

Expected Behavior

Feishin can login/connect to a Navidrome instance that is OIDC protected.

Current Behavior

Feishin currently is unable to login at all to a OIDC protected Navidrome (sitting behind Traefik/Authentik). Sonixd on the other hand works fine with the same setup. This is similar to #16 except this deals with the OAuth/OIDC delegation which makes it slightly worse.

From the logs in the web console, Feishin will issue 2 requests:

1. Post to https://navidrome.home.lan/auth/login. This is protected by the OIDC layer and gets bounced to Authentik.
2. Feishin cannot finish the flow there of course and I believe it bails out.
3. It then attempts to ping the subsonic ping endpoint but it never provides the u/p/t parameters for auth. Those are NOT protected by OIDC and rely on in protocol auth.

Calls from Feishin in web console:

POST https://navidrome.home.lan/auth/login => 302 Found
GET https://authentik.home.lan/application/o/authorize/?client_id=oqlu7Ew75YBLwnGk3owzqSxt3t0jeAk87YX9rEXZ&redirect_uri=https%3A%2F%2Fauthentik.home.lan%2Foutpost.goauthentik.io%2Fcallback%3FX-authentik-auth-callback%3Dtrue&response_type=code&scope=openid+email+profile+ak_proxy&state=oHnTidB1hMEtO17mksP7qycqC7P_7H4bglPunRiM4S4 => 302 Found
GET https://authentik.home.lan/flows/-/default/authentication/?next=/application/o/authorize/%3Fclient_id%3Doqlu7Ew75YBLwnGk3owzqSxt3t0jeAk87YX9rEXZ%26redirect_uri%3Dhttps%253A%252F%252Fauthentik.home.lan%252Foutpost.goauthentik.io%252Fcallback%253FX-authentik-auth-callback%253Dtrue%26response_type%3Dcode%26scope%3Dopenid%2Bemail%2Bprofile%2Bak_proxy%26state%3DoHnTidB1hMEtO17mksP7qycqC7P_7H4bglPunRiM4S4 => 302 Found
GET https://authentik.home.lan/if/flow/default-authentication-flow/?next=%2Fapplication%2Fo%2Fauthorize%2F%3Fclient_id%3Doqlu7Ew75YBLwnGk3owzqSxt3t0jeAk87YX9rEXZ%26redirect_uri%3Dhttps%253A%252F%252Fauthentik.home.lan%252Foutpost.goauthentik.io%252Fcallback%253FX-authentik-auth-callback%253Dtrue%26response_type%3Dcode%26scope%3Dopenid%2Bemail%2Bprofile%2Bak_proxy%26state%3DoHnTidB1hMEtO17mksP7qycqC7P_7H4bglPunRiM4S4 => 200 OK
GET https://navidrome.home.lan/rest/ping.view?c=Feishin&f=json&v=1.13.0&s=undefined&t=undefined => 200 OK
GET https://navidrome.home.lan/rest/getOpenSubsonicExtensions.view?c=Feishin&f=json&v=1.13.0&s=undefined&t=undefined => 200 OK

Logs from navidrome container:

navidrome  | time="2024-04-01T20:21:13Z" level=warning msg="missing parameter: 'u'" requestId=ad19e3d7519c/l98hQoKPvs-161619
navidrome  | time="2024-04-01T20:21:13Z" level=warning msg="API: Failed response" endpoint=/rest/ping.view error=10 message="missing parameter: 'u'" requestId=ad19e3d7519c/l98hQoKPvs-161619
navidrome  | time="2024-04-01T20:21:13Z" level=warning msg="missing parameter: 'u'" requestId=ad19e3d7519c/l98hQoKPvs-161620
navidrome  | time="2024-04-01T20:21:13Z" level=warning msg="API: Failed response" endpoint=/rest/getOpenSubsonicExtensions.view error=10 message="missing parameter: 'u'" requestId=ad19e3d7519c/l98hQoKPvs-161620

Navidrome expects url params u=username and t=jwttoken or p=password on its subsonic API calls. My guess is that unlike Sonixd, Feishin tries to call the auth/login entrypoint to get the jwt token instead of using the password directly. If so, it doesn't conform to what Navidrome expects when delegating auth to an BasicAuth or OAuth/OIDC 3rd party provider provider.

Steps to Reproduce

1. Set up navidrome with any OIDC solution and delegate auth to it.
2. Allowlist navidrome's rest/* endpoints for direct auth bypassing OIDC.
3. Try to connect from Feishin.

Possible Solution (Not obligatory)

Simplest solution would be to remove the need to fetch a jwt token and use the password directly as a URL param, or make it optional/configurable through a flag.

Another potential workaround would be to allow auth/login endpoint in navidrome to be bypassed in OIDC but then other clients may break and a user might get presented with a native login screen from navidrome.

Context

Trying to migrate from Sonixd to Feishin. Blocker since it can't even connect.

Your Environment

• Application version (e.g. v0.1.0) : 0.6.1-1
• Operating System and version (e.g. Windows 10) : Arch Linux
• Server and version (e.g. Navidrome v0.48.0) : Navidrome v0.51.1
• Node version (if developing locally) : N/A

[kgarner7]

I was trying this a while ago, and it is unlikely to come about in the desktop app as there are a few annoying requirements:

1. You need to detect (for every request) whether you are hitting a captive portal/other auth timeout (this could be 401 permission denied, or some redirect to new page). This is feasible, but not particularly clean
2. You need to detect the redirect (if it exists) and actually go through the login. This requires opening a new tab to login to your reverse proxy service. This is also doable, but even less clean
3. You need to save all the possible credentials from this authentication. Since different services may use cookie-based or header-based authentication, you would basically need to capture and intercept all of them (a prospect I'm not too fond of).

This can be bypassed in the browser (just host Feishin on the same domain on a subpath) without any extra work.

All in all, while I was able to get it (sort of) to work, I cannot endorse this as a practical solution. Unfortunately for the desktop it'll have to wait for #419.

If you have questions about how to setup the web version in the meantime to work with reverse proxy authentication, feel free to add on here, but otherwise I'll probably close this issue.

[enticedwanderer]

Oh I thought feishin already supported subsonic directly. I didn't realize you were using direct navidrome APIs. In that case yeah, I'll just wait until #419 is ready. Thanks! Yeah I agree it's likely not worth going through the hoops you mentioned above.

[kgarner7]

Yeah, it's a pain point for me as well (I can't use the desktop app on my work device), but I know that to properly support Subsonic in the current scheme would require more rework (that I'm personally not comfortable taking over). If you like the webapp I would still suggest giving it a shot. I appreciate the understanding

[pr0927]

@enticedwanderer apologies for bumping this old thread, but I was wondering how you even got OIDC working with Navidrome -to my knowledge it's not supported yet? I'm using Authentik. Did you switch to a proxy provider by any chance, and if so, does that work with Feishin?

[enticedwanderer]

@pr0927 I'm using reverse proxy approach via Authentik yeah. It is in the docs and supported (for web usage, clients still need username/password of course). It does work now with Feishin (after #419 was done), you just have to make sure to register your navidrome instance as a subsonic server and not a navidrome instance (otherwise it will still try to use the native navidrome APIs protected by the reverse proxy).

[pr0927]

@pr0927 I'm using reverse proxy approach via Authentik yeah. It is in the docs and supported (for web usage, clients still need username/password of course). It does work now with Feishin (after #419 was done), you just have to make sure to register your navidrome instance as a subsonic server and not a navidrome instance (otherwise it will still try to use the native navidrome APIs protected by the reverse proxy).

Oh interesting - do you mind sharing how you have your Authentik and Navidrome config setup?

I'm running Navidrome as a Docker container, behind NPMplus.

If you have "ND_REVERSEPROXYUSERHEADER" - what do you have it set to?

[qoh]

you just have to make sure to register your navidrome instance as a subsonic server and not a navidrome instance (otherwise it will still try to use the native navidrome APIs protected by the reverse proxy)

@pr0927 Oh interesting - do you mind sharing how you have your Authentik and Navidrome config setup?

I'm running Navidrome as a Docker container, behind NPMplus.

If you have "ND_REVERSEPROXYUSERHEADER" - what do you have it set to?

Different person and using Authelia instead of Authentik, but in my case, I just don't apply the auth checks to the Subsonic API which is at /rest/, and instead rely on its own authentication for that. This does mean that I have to set user passwords in Navidrome itself to be able to use the Subsonic API, but that's not the worst thing either as I can do so for some users only, and set different passwords only used for the Subsonic API.

nginx setup something like:

location / {
  proxy_pass http://navidrome;
  include <authelia proxy config>;
  include <authelia auth request config>;
}
location /rest {
  proxy_pass http://navidrome;
}

Some more details on Navidrome's Security Considerations page's reverse proxy auth section.

[enticedwanderer]

Exactly. I'm doing the same thing as qoh but with Authentik.

1. Setup the proxy provider in Authentik for forward auth
2. Integrate authentik proxy with your NPM+.
3. Configure navidrome to expect the authenticated user to be in the X-authentik-username header and trusted

   ND_REVERSEPROXYUSERHEADER: "X-authentik-username"
   ND_REVERSEPROXYWHITELIST: "172.20.0.0/16"
   

4. In authentik allowlist the/rest/* endpoints to bypass auth and fallback to username/password as specified in documentation. This is done by updating the list in the proxy provider for "Unauthenticated URLs" under Advanced settings. I use domain level forward proxy so I have a bunch of entries in there one of which is:

   https://navidrome.home.lan/rest/.*
   

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.