Login Doesn't allow redirect to additional authentication (authelia) #930

New Issue

2026-04-24T23:42:40+02:00

adam commented

2026-04-24 23:42:40 +02:00

Originally created by @Binvention on GitHub (Mar 27, 2024).

Steps to reproduce

Audiobookshelf server protected using authelia and nginx so that access must first be granted through authelia before accessing the server
SSO setup between authelia and audiobookshelf
attempt to login via mobile app

Expected behaviour

I expect to be redirected to the authelia login page as nginx is trying to do and then for the SSO to kick in so that I'm automatically logged into audiobookshelf
everything works as expected when accessing from the browser

Actual behaviour

Error - Server redirected to authelia.example.org

Environment data

Audiobookshelf Version: 2.8.1 docker

[x ] Android App?
iOS App?

nginx config is exact same as swag example config at
https://github.com/linuxserver/reverse-proxy-confs/blob/master/audiobookshelf.subdomain.conf.sample
with the authelia lines uncommented

Android Issue

Android version: 14

Device model: pixel 6

Stock or customized system: stock

iOS Issue

iOS Version:

iPhone model:

Originally created by @Binvention on GitHub (Mar 27, 2024). ### Steps to reproduce 1. Audiobookshelf server protected using authelia and nginx so that access must first be granted through authelia before accessing the server 2. SSO setup between authelia and audiobookshelf 3. attempt to login via mobile app ### Expected behaviour - I expect to be redirected to the authelia login page as nginx is trying to do and then for the SSO to kick in so that I'm automatically logged into audiobookshelf - everything works as expected when accessing from the browser ### Actual behaviour - Error - Server redirected to authelia.example.org ### Environment data Audiobookshelf Version: 2.8.1 docker - [x ] Android App? - [ ] iOS App? nginx config is exact same as swag example config at https://github.com/linuxserver/reverse-proxy-confs/blob/master/audiobookshelf.subdomain.conf.sample with the authelia lines uncommented #### Android Issue Android version: 14 Device model: pixel 6 Stock or customized system: stock #### iOS Issue iOS Version: iPhone model:

adam added the bug label 2026-04-24 23:42:40 +02:00

adam closed this issue

2026-04-24 23:42:41 +02:00

adam commented

2026-04-24 23:42:42 +02:00

@advplyr commented on GitHub (Mar 27, 2024):

Where are you seeing that error?

Do you have the mobile-redirect redirect URI set in Abs settings? https://www.audiobookshelf.org/guides/oidc_authentication

@advplyr commented on GitHub (Mar 27, 2024): Where are you seeing that error? Do you have the mobile-redirect redirect URI set in Abs settings? https://www.audiobookshelf.org/guides/oidc_authentication

adam commented

2026-04-24 23:42:43 +02:00

@Binvention commented on GitHub (Mar 28, 2024):

Yes I do have that setting the problem is that it never gets to the login page for authelia from the server selection page. I think the SSO option works but that requires it loading the audiobookshelf login first then redirecting to authelia. Since authelia is protecting the audiobookshelf login it requires authelia be loaded first. I'll see if I can get a screenshot

@Binvention commented on GitHub (Mar 28, 2024): Yes I do have that setting the problem is that it never gets to the login page for authelia from the server selection page. I think the SSO option works but that requires it loading the audiobookshelf login first then redirecting to authelia. Since authelia is protecting the audiobookshelf login it requires authelia be loaded first. I'll see if I can get a screenshot ![Screenshot_20240327-174708.png](https://github.com/advplyr/audiobookshelf-app/assets/16170948/0bd6a372-f7d7-44a7-802c-f66b54bee5a9)

adam commented

2026-04-24 23:42:47 +02:00

@advplyr commented on GitHub (Mar 28, 2024):

You haven't configured authelia correctly then because Abs app needs to be able to make that first request without being redirected. Abs will handle the redirecting, your setup shouldn't be doing that.

I'm not familiar with authelia so I can't give you specific setup instructions but you can share what you have setup

@advplyr commented on GitHub (Mar 28, 2024): You haven't configured authelia correctly then because Abs app needs to be able to make that first request without being redirected. Abs will handle the redirecting, your setup shouldn't be doing that. I'm not familiar with authelia so I can't give you specific setup instructions but you can share what you have setup

adam commented

2026-04-24 23:42:52 +02:00

@nichwall commented on GitHub (Mar 28, 2024):

Are you using forward authentication?

@nichwall commented on GitHub (Mar 28, 2024): Are you using forward authentication?

adam commented

2026-04-24 23:42:53 +02:00

@Binvention commented on GitHub (Mar 28, 2024):

I'm using the example configuration found in the swag documentation
https://github.com/linuxserver/reverse-proxy-confs/blob/master/audiobookshelf.subdomain.conf.sample
with the authelia portions uncommented. What urls would need to be excluded from security in order for this to work without compromising the additional security or allowing people without the proper group permissions to access the app (since audiobookshelf's openid implementation doesn't check groups)

@Binvention commented on GitHub (Mar 28, 2024): I'm using the example configuration found in the swag documentation https://github.com/linuxserver/reverse-proxy-confs/blob/master/audiobookshelf.subdomain.conf.sample with the authelia portions uncommented. What urls would need to be excluded from security in order for this to work without compromising the additional security or allowing people without the proper group permissions to access the app (since audiobookshelf's openid implementation doesn't check groups)

adam commented

2026-04-24 23:42:56 +02:00

@Sapd commented on GitHub (Apr 2, 2024):

@Binvention
You are trying to use forward auth. That will never work with a mobile app - even if you would try to adapt the app for that.

What urls would need to be excluded from security

It would not matter - even if you would remove the check. It cannot technically work, because for authentication there is always a redirect to your app provider (in this case authelia). So it would either need to:

Open the authelia website in the app itself without a browser window (because the app is browser based in theory possible)
- IONIC blocks this and its against Apples policy (app needs to be self-contained)
Open the authelia website in browser or in-app popup
- Possible, but then there is no way to transfer the resulting Cookie/Token whatever back to the app. Because the cookie is set by the reverse proxy in this pop-up browser window; there is no way to read the cookies and transfer it to the app. On OpenID it is possible, because the protocol includes a redirect to a customizable link - which then includes a token.

since audiobookshelf's openid implementation doesn't check group

ABS now includes that functionality in the latest :edge image, however you would need to use a property mapping if you don't want to use the standard group names (user, guest, admin).

Its a bit weird, checking groups functionality and property mapping is practically a standard which is supported by a lot of open id providers (keycloak, authentik, okta etc.)

@Sapd commented on GitHub (Apr 2, 2024): @Binvention You are trying to use forward auth. That will never work with a mobile app - even if you would try to adapt the app for that. > What urls would need to be excluded from security It would not matter - even if you would remove the check. It cannot technically work, because for authentication there is always a redirect to your app provider (in this case authelia). So it would either need to: - Open the authelia website in the app itself without a browser window (because the app is browser based **in theory** possible) - IONIC blocks this and its against Apples policy (app needs to be self-contained) - Open the authelia website in browser or in-app popup - Possible, but then there is no way to transfer the resulting Cookie/Token whatever back to the app. Because the cookie is set by the reverse proxy in this pop-up browser window; there is no way to read the cookies and transfer it to the app. On OpenID it is possible, because the protocol includes a redirect to a customizable link - which then includes a token. > since audiobookshelf's openid implementation doesn't check group ABS now includes that functionality in the latest :edge image, however you would need to use a property mapping if you don't want to use the standard group names (user, guest, admin). Its a bit weird, checking groups functionality and property mapping is practically a standard which is supported by a lot of open id providers (keycloak, authentik, okta etc.)

adam commented

2026-04-24 23:43:00 +02:00

@Binvention commented on GitHub (Apr 2, 2024):

It is very possible. Applications such as immich, jellyfin, and home assistant have been setup in this way (although home assistant not as cleanly). Most of them do it with some form of allowing the redirects in app which opens up the default browser for authentication and then passes an API token back to the app. Then in the proxy or authentication provider settings allow specific locations to bypass authentication (such as /API/ since it has its own security implementation that functions with the mobile app). Although I've had issues setting the other apps up in this way as well I know others have done it and audiobookshelf is the only one that flat out doesn't allow the redirect to begin with. Which I found especially odd since it's one of the few that has openid support by default. I was hoping this would allow 2FA and SSO for all my home apps but without forward authentication there's no way to ensure 2FA is enforced for audiobookshelf. The root account at minimum would not be protected by 2FA.

@Binvention commented on GitHub (Apr 2, 2024): It is very possible. Applications such as immich, jellyfin, and home assistant have been setup in this way (although home assistant not as cleanly). Most of them do it with some form of allowing the redirects in app which opens up the default browser for authentication and then passes an API token back to the app. Then in the proxy or authentication provider settings allow specific locations to bypass authentication (such as /API/ since it has its own security implementation that functions with the mobile app). Although I've had issues setting the other apps up in this way as well I know others have done it and audiobookshelf is the only one that flat out doesn't allow the redirect to begin with. Which I found especially odd since it's one of the few that has openid support by default. I was hoping this would allow 2FA and SSO for all my home apps but without forward authentication there's no way to ensure 2FA is enforced for audiobookshelf. The root account at minimum would not be protected by 2FA.

adam commented

2026-04-24 23:43:02 +02:00

@Binvention commented on GitHub (Apr 2, 2024):

I do think this would be a good option to have but for the time being I've settled on this option mentioned in a different app:

Disable forward authentication in proxy settings.
Disable password login in audiobookshelf settings (so openid is the only login option)

This does work as expected with the browser opening to handle the authentication with the desired 2FA and then returning to the app now logged in. This does mean I have to depend on the security of audiobookshelf itself more than what I would have to with forward authentication allowed.

@Binvention commented on GitHub (Apr 2, 2024): I do think this would be a good option to have but for the time being I've settled on this option mentioned in a different app: Disable forward authentication in proxy settings. Disable password login in audiobookshelf settings (so openid is the only login option) This does work as expected with the browser opening to handle the authentication with the desired 2FA and then returning to the app now logged in. This does mean I have to depend on the security of audiobookshelf itself more than what I would have to with forward authentication allowed.

adam commented

2026-04-24 23:43:03 +02:00

@Sapd commented on GitHub (Apr 2, 2024):

Applications such as immich, jellyfin, and home assistant have been setup in this way (although home assistant not as cleanly).

Can you send me link to documentation or code?
I quickly tried it with the Jellyfin App on iOS and desktop and it will directly refuse connecting when a redirect occurs - same like ABS.

For Home Assistant I googled this, which does not seem to be unproblematic and suffers of the issues Im describing below: https://github.com/BeryJu/hass-auth-header/issues/124
Also I tried point HA against a auth redirect, and it seems that it just creates an OpenID-style auth request: /auth/authorize?response_type=code&client_id=https://home-assistant.io/iOS&redirect_uri=homeassistant://auth-callback which needs heavy whitelisting and code support (see below)

Then in the proxy or authentication provider settings allow specific locations to bypass authentication (such as /API/ since it has its own security implementation that functions with the mobile app).

This does mean I have to depend on the security of audiobookshelf itself more than what I would have to with forward authentication allowed.

I understand the method which you are describing, but effectively you would have to whitelist all requests to the backend, with the only exception being the login route. And with OpenID you can disable the login form/route all together (like you mentioned and did).

Security wise you are at the same point, no matter if you use forward auth (with whitelisted backend) or OpenID. I do not really see how you can increase security by using forward auth. The only thing you would protect, is serving the ABS frontend (which one can download from GitHub anyways...), or the login route if you wouldn't restrict to OpenID.

Audiobookshelf is the only one that flat out doesn't allow the redirect to begin with. Which I found especially odd since it's one of the few that has openid support by default.

The redirect in a pop-up is not a automatic thing and is in a much different place then OpenID. Even if you would remove that check nothing would happen. You would have to replace that check with code that opens a pop-up.
Then you would need extra code which checks if there was a redirection from the idP and does a redirect back to the app similar to what OpenID does (just reinventing the wheel in a bad way).

Although I've had issues setting the other apps up in this way as well I know others have done it [...]

Problematic is, that Forward-Auth is not a standard. So it is hard to properly support it for most scenarios - thats probably why from the linked Home-Assistant issue above (at the very bottom), a commenter critiqued bugs on Android, and that HA should implement proper OpenID support.

Edit: I also noticed that Home Assistant does not have PKCE challenges in the auth request.... that is quite insecure on mobile.

@Sapd commented on GitHub (Apr 2, 2024): > Applications such as immich, jellyfin, and home assistant have been setup in this way (although home assistant not as cleanly). Can you send me link to documentation or code? I quickly tried it with the Jellyfin App on iOS and desktop and it will directly refuse connecting when a redirect occurs - same like ABS. For Home Assistant I googled this, which does not seem to be unproblematic and suffers of the issues Im describing below: https://github.com/BeryJu/hass-auth-header/issues/124 Also I tried point HA against a auth redirect, and it seems that it just creates an OpenID-style auth request: `/auth/authorize?response_type=code&client_id=https://home-assistant.io/iOS&redirect_uri=homeassistant://auth-callback` which needs heavy whitelisting and code support (see below) > Then in the proxy or authentication provider settings allow specific locations to bypass authentication (such as /API/ since it has its own security implementation that functions with the mobile app). > This does mean I have to depend on the security of audiobookshelf itself more than what I would have to with forward authentication allowed. I understand the method which you are describing, but effectively you would have to whitelist all requests to the backend, with the *only* exception being the login route. And with OpenID you can disable the login form/route all together (like you mentioned and did). Security wise you are at the same point, no matter if you use forward auth (with whitelisted backend) or OpenID. I do not really see how you can increase security by using forward auth. The only thing you would protect, is serving the ABS frontend (which one can download from GitHub anyways...), or the login route if you wouldn't restrict to OpenID. > Audiobookshelf is the only one that flat out doesn't allow the redirect to begin with. Which I found especially odd since it's one of the few that has openid support by default. The redirect in a pop-up is not a automatic thing and is in a much different place then OpenID. Even if you would remove that check nothing would happen. You would have to replace that check with code that opens a pop-up. Then you would need extra code which checks if there was a redirection from the idP and does a redirect back to the app similar to what OpenID does (just reinventing the wheel in a bad way). > Although I've had issues setting the other apps up in this way as well I know others have done it [...] Problematic is, that Forward-Auth is not a standard. So it is hard to properly support it for most scenarios - thats probably why from the linked Home-Assistant issue above (at the very bottom), a commenter critiqued bugs on Android, and that HA should implement proper OpenID support. Edit: I also noticed that Home Assistant does not have PKCE challenges in the auth request.... that is quite insecure on mobile.

adam commented

2026-04-24 23:43:07 +02:00

@skyzuma commented on GitHub (May 14, 2025):

ive tested it today and have the same error: " ... redirected somewhere else" ... i added bypass rules like this (https://docs.fossorial.io/Pangolin/bypass-rules) but not working ....

i tested rules with the tautulli android app and it works perfect (without active rule > error) ... i think its a problem with the android app but idk ... i dont readed all here, that i dont understand much, sry about that ...

@skyzuma commented on GitHub (May 14, 2025): ive tested it today and have the same error: " ... redirected somewhere else" ... i added bypass rules like this (https://docs.fossorial.io/Pangolin/bypass-rules) but not working .... i tested rules with the tautulli android app and it works perfect (without active rule > error) ... i think its a problem with the android app but idk ... i dont readed all here, that i dont understand much, sry about that ...

adam commented

2026-04-24 23:43:09 +02:00

@Al4ndil commented on GitHub (Jun 30, 2025):

ive tested it today and have the same error: " ... redirected somewhere else" ... i added bypass rules like this (https://docs.fossorial.io/Pangolin/bypass-rules) but not working ....

i tested rules with the tautulli android app and it works perfect (without active rule > error) ... i think its a problem with the android app but idk ... i dont readed all here, that i dont understand much, sry about that ...

Same thing for me with SWAG & Authelia.

@Al4ndil commented on GitHub (Jun 30, 2025): > ive tested it today and have the same error: " ... redirected somewhere else" ... i added bypass rules like this (https://docs.fossorial.io/Pangolin/bypass-rules) but not working .... > > i tested rules with the tautulli android app and it works perfect (without active rule > error) ... i think its a problem with the android app but idk ... i dont readed all here, that i dont understand much, sry about that ... Same thing for me with SWAG & Authelia.

adam commented

2026-04-24 23:43:13 +02:00

@Sapd commented on GitHub (Jun 30, 2025):

@skyzuma @Al4ndil please re-read my comment above.

You are trying to do this (picture from wikipedia https://commons.wikimedia.org/wiki/File:Gates_without_wall.jpg )

@Sapd commented on GitHub (Jun 30, 2025): @skyzuma @Al4ndil please re-read my comment above. You are trying to do this (picture from wikipedia https://commons.wikimedia.org/wiki/File:Gates_without_wall.jpg ) ![Image](https://github.com/user-attachments/assets/bdcaa275-9893-4177-a937-0ab28c85e10e)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#930