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

[Binvention]

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:

[advplyr]

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

[Binvention]

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

[advplyr]

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

[nichwall]

Are you using forward authentication?

[Binvention]

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)

[Sapd]

@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.)

[Binvention]

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]

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.

[Sapd]

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.