starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Support Reverse Proxy Authentication / Forward Authentication #2545

New Issue
Open
opened 2026-04-25 00:08:14 +02:00 by adam · 3 comments
adam commented 2026-04-25 00:08:14 +02:00
Owner
Copy Link
Copy Source

Originally created by @balki on GitHub (Feb 5, 2025).

Type of Enhancement

Server Backend

Describe the Feature/Enhancement

Add a new type of authentication called Reverse Proxy Authentication.
When this type is enabled and the http request contains a header X-WEBAUTH-USER, if the user exists in abs, automatically login the user.

For ref: gitea supports this: https://docs.gitea.com/administration/authentication#reverse-proxy

Why would this be helpful?

tailscale and similar mesh networks are popular with selfhosters. In those cases the device is already authenticated with wireguard. Additional passwords or authentication is not needed. Example caddy(a reverse proxy web server) config:

audiobookshelf.example.com {
    @alice_phone client_ip 100.64.68.1
    @alice_lap client_ip 100.64.68.2
    @bob_phone client_ip 100.64.68.3

    @not_ts not client_ip 100.64.0.0/16
    
    request_header @alice_phone X-WEBAUTH-USER alice
    request_header @alice_lap X-WEBAUTH-USER alice
    request_header @bob_phone X-WEBAUTH-USER bob

   # Remove for others
    request_header @not_ts -X-WEBAUTH-USER

   reverse_proxy 127.0.0.1:5678
}

Future Implementation (Screenshot)

Just another checkbox in the list of supported authentication methods

Audiobookshelf Server Version

v2.19.0

Current Implementation (Screenshot)

I am not sure if this is already possible with OIDC or with the pull #3302 . If so, please document what is the header that needs to be set.

Originally created by @balki on GitHub (Feb 5, 2025). ### Type of Enhancement Server Backend ### Describe the Feature/Enhancement Add a new type of authentication called `Reverse Proxy Authentication`. When this type is enabled and the http request contains a header `X-WEBAUTH-USER`, if the user exists in abs, automatically login the user. For ref: gitea supports this: https://docs.gitea.com/administration/authentication#reverse-proxy ### Why would this be helpful? tailscale and similar mesh networks are popular with selfhosters. In those cases the device is already authenticated with wireguard. Additional passwords or authentication is not needed. Example [caddy](https://caddyserver.com/)(a reverse proxy web server) config: ```caddyfile audiobookshelf.example.com { @alice_phone client_ip 100.64.68.1 @alice_lap client_ip 100.64.68.2 @bob_phone client_ip 100.64.68.3 @not_ts not client_ip 100.64.0.0/16 request_header @alice_phone X-WEBAUTH-USER alice request_header @alice_lap X-WEBAUTH-USER alice request_header @bob_phone X-WEBAUTH-USER bob # Remove for others request_header @not_ts -X-WEBAUTH-USER reverse_proxy 127.0.0.1:5678 } ``` ### Future Implementation (Screenshot) Just another checkbox in the list of supported authentication methods ### Audiobookshelf Server Version v2.19.0 ### Current Implementation (Screenshot) I am not sure if this is already possible with OIDC or with the pull #3302 . If so, please document what is the header that needs to be set.
adam added the enhancementbacklog labels 2026-04-25 00:08:14 +02:00
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Feb 5, 2025):

I've not heard this called reverse proxy authentication before. We've discussed this a few times as "forward authentication".

This isn't planned to be implemented for the reasons explained here https://github.com/advplyr/audiobookshelf/pull/2189#issuecomment-1818901032

Basically we wouldn't be able to implement this cleanly/securely in the mobile apps.
And we already support OIDC which can be used to roll your own auth. Supporting this would add complexity to our existing auth setup.

@advplyr commented on GitHub (Feb 5, 2025): I've not heard this called reverse proxy authentication before. We've discussed this a few times as "forward authentication". This isn't planned to be implemented for the reasons explained here https://github.com/advplyr/audiobookshelf/pull/2189#issuecomment-1818901032 Basically we wouldn't be able to implement this cleanly/securely in the mobile apps. And we already support OIDC which can be used to roll your own auth. Supporting this would add complexity to our existing auth setup.
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@balki commented on GitHub (Feb 5, 2025):

@advplyr Just to be clear, I am not requesting 'forward authentication' here. reverse proxy auth is very simple.

# pseudocode
if (settings.reverse_proxy_auth_enabled && request.hasHeader('X-WEBAUTH-USER') {
user = request.headers['X-WEBAUTH-USER']
}

Should just work great for mobile apps and any other clients too. There is no extra settings, no separate authentication server, no cookies, no redirection, no logout etc. I don't think any of the concerns of forward_auth will apply.

@balki commented on GitHub (Feb 5, 2025): @advplyr Just to be clear, I am not requesting 'forward authentication' here. reverse proxy auth is very simple. ``` # pseudocode if (settings.reverse_proxy_auth_enabled && request.hasHeader('X-WEBAUTH-USER') { user = request.headers['X-WEBAUTH-USER'] } ``` Should just work great for mobile apps and any other clients too. There is no extra settings, no separate authentication server, no cookies, no redirection, no logout etc. I don't think any of the concerns of forward_auth will apply.
adam commented 2026-04-25 00:08:15 +02:00
Author
Owner
Copy Link
Copy Source

@Kapot commented on GitHub (Feb 20, 2026):

EDIT:

Rethinking this over I actually do think this need some configuration to the app. As the app needs to set or be told what the valid headers are. So it's more work than i originally thought. I understand it's not on the roadmap, thats ok.

If you do want to look at it, Tautulli does have this setting implemented. On the server setting page you can set Custom HTTP Headers. Basic authentication or Custom authentication. I use custom and fill it with info generated in Pangolin.

Original post:

I'd like to add my support for this specific implementation and explain why it would work securely for mobile apps.

My setup: I use Pangolin (a self-hosted reverse proxy with built-in SSO) in front of Audiobookshelf. The problem is that the ABS mobile app can't handle Pangolin's SSO redirect flow, so I'm forced to either expose ABS without any auth layer, or require a full VPN for mobile access. Which is great as a single users, but can be challenging with more users.

The X-WEBAUTH-USER header approach would solve this cleanly. Pangolin would inject the header on every request transparently — the mobile app needs zero changes and connects normally. ABS reads the header and handles the session itself.

The security model is sound:

  • The header is set by the reverse proxy, never by the client
  • As long as ABS only trusts the header when reverse_proxy_auth_enabled is explicitly set, there's no risk of spoofing from the open internet
  • It's the same trust model used by many other self-hosted apps (Organizr, Authelia, etc.)

The pseudocode suggested above looks trivial to implement and the use case is solid. Would really appreciate this being reconsidered. Happy to test any implementation.

@Kapot commented on GitHub (Feb 20, 2026): EDIT: Rethinking this over I actually do think this need some configuration to the app. As the app needs to set or be told what the valid headers are. So it's more work than i originally thought. I understand it's not on the roadmap, thats ok. If you do want to look at it, Tautulli does have this setting implemented. On the server setting page you can set Custom HTTP Headers. Basic authentication or Custom authentication. I use custom and fill it with info generated in Pangolin. Original post: > I'd like to add my support for this specific implementation and explain why it would work securely for mobile apps. > > My setup: I use Pangolin (a self-hosted reverse proxy with built-in SSO) in front of Audiobookshelf. The problem is that the ABS mobile app can't handle Pangolin's SSO redirect flow, so I'm forced to either expose ABS without any auth layer, or require a full VPN for mobile access. Which is great as a single users, but can be challenging with more users. > > The `X-WEBAUTH-USER` header approach would solve this cleanly. Pangolin would inject the header on every request transparently — the mobile app needs zero changes and connects normally. ABS reads the header and handles the session itself. > > The security model is sound: > - The header is set by the reverse proxy, never by the client > - As long as ABS only trusts the header when `reverse_proxy_auth_enabled` is explicitly set, there's no risk of spoofing from the open internet > - It's the same trust model used by many other self-hosted apps (Organizr, Authelia, etc.) > > The pseudocode suggested above looks trivial to implement and the use case is solid. Would really appreciate this being reconsidered. Happy to test any implementation.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label backlog enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2545
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?