[Bug]: &#34;Invalid callback URL - must be same-origin&#34; #2960

@nichwall commented on GitHub (Aug 25, 2025):

This sounds like a misconfigured reverse proxy, assuming you have verified that you entered https in both Audiobookshelf and your OIDC provider configuration.

Can you share your reverse proxy configuration?

@nichwall commented on GitHub (Aug 25, 2025): This sounds like a misconfigured reverse proxy, assuming you have verified that you entered https in both Audiobookshelf and your OIDC provider configuration. Can you share your reverse proxy configuration?

adam commented

@Vito0912 commented on GitHub (Aug 25, 2025):

Probably unrelated but I had the same issue when loading a backup from my default server to my dev server. I had to completely disable OIDC to get it working again. No reverse proxy in use at all.
I am very positive that this has to do with the fixed security issue.
Just wanted to leave this here as I thought I just miscliked things

@Vito0912 commented on GitHub (Aug 25, 2025): Probably unrelated but I had the same issue when loading a backup from my default server to my dev server. I had to completely disable OIDC to get it working again. No reverse proxy in use at all. I am very positive that this has to do with the fixed security issue. Just wanted to leave this here as I thought I just miscliked things

adam commented

@njack21 commented on GitHub (Aug 27, 2025):

Same issue. It was working previously. I blew away my OIDC configuration and started over, but am still having the issue.

I am using Nginix Proxy Manager and have made no changes to the configuration since it was previously working.

Details Tab

Domain Name: abs.example.com
Scheme: http
Forward IP: 192.168.1.x
Forward Port 13378
Block Common Exploits and Websockets Support both checked
Cache Assets not checked.

Custom Locations

none

SSL

SSL Certificate: *.example.com
HTTP/2 Support: checked
All others unchecked

Advanced

none

@njack21 commented on GitHub (Aug 27, 2025): Same issue. It was working previously. I blew away my OIDC configuration and started over, but am still having the issue. I am using Nginix Proxy Manager and have made no changes to the configuration since it was previously working. **Details Tab** - Domain Name: abs.example.com - Scheme: http - Forward IP: 192.168.1.x - Forward Port 13378 - Block Common Exploits and Websockets Support both checked - Cache Assets not checked. **Custom Locations** - none **SSL** - SSL Certificate: *.example.com - HTTP/2 Support: checked - All others unchecked **Advanced** - none

adam commented

2026-04-25 00:12:23 +02:00

@tomatmonkeyturf commented on GitHub (Aug 28, 2025):

Same issue. Mine was also working previously. Latest update seems to have broken OIDC through a reverse proxy.
AudioBookShelf in Docker. SSO provider Authentik. Reverse Proxy NGINX Proxy Manager. Proxy manager config is the same as njack21

The application seems be able to use OIDC accessing it directly with host and port. I had to disable OIDC in AudioBookShelf to be able to login through the proxy manager.

@tomatmonkeyturf commented on GitHub (Aug 28, 2025): Same issue. Mine was also working previously. Latest update seems to have broken OIDC through a reverse proxy. AudioBookShelf in Docker. SSO provider Authentik. Reverse Proxy NGINX Proxy Manager. Proxy manager config is the same as [njack21](https://github.com/njack21) The application seems be able to use OIDC accessing it directly with host and port. I had to disable OIDC in AudioBookShelf to be able to login through the proxy manager.

adam commented

@alindt commented on GitHub (Aug 29, 2025):

I had to revert to v2.27.0, it's the last version that works.

@alindt commented on GitHub (Aug 29, 2025): I had to revert to v2.27.0, it's the last version that works.

adam commented

2026-04-25 00:12:23 +02:00

@Pimmetje commented on GitHub (Aug 29, 2025):

I have a docker container behind a HA-proxy. I need to know how how the expected value is determined. Than i am most likely be able to fix it.

@Pimmetje commented on GitHub (Aug 29, 2025): I have a docker container behind a HA-proxy. I need to know how how the expected value is determined. Than i am most likely be able to fix it.

adam commented

2026-04-25 00:12:23 +02:00

@Vito0912 commented on GitHub (Aug 30, 2025):

@Pimmetje

Can you check where it tries to redirect you when you click the Login with OpenID button?

I have never worked with Nuxt, so I don’t know why it behaves the way it does, but we set a serverUrl somewhere:

https://github.com/advplyr/audiobookshelf/blob/master/client/pages/login.vue#L135C1-L135C97

This does not send you to your current host, but instead to whatever is set in the env. That is a problem if the callback will send you to your current address. Maybe I am missing something, but this makes no sense to me. Of course, the host will not match if the env is wrong.

In addition to this, I am not sure (and I think this makes the problem worse) that the host header gets overwritten by somewhat, at least in dev builds.
I make the request with Host: 192.168.178.100:3000, but the header received in the validation method is host: 'localhost:3333', which matches the address in the serverUrl env. So wherever this is set, it seems to be wrong (Note: In dev builds is always localhost:3333). Because of this, it does not even work to manually go to the same host.

I get redirected to:
http://localhost:3333/audiobookshelf/auth/openid?callback=http://192.168.178.100:3000/audiobookshelf/login

If I change it manually to the correct values:
http://192.168.178.100:3000/audiobookshelf/auth/openid?callback=http://192.168.178.100:3000/audiobookshelf/login

The host is still seen as localhost:3333 and it fails.

It works on all my production systems, so I don’t know why some of you have this issue, but I guess the serverUrl is set to http for the OP e.g.

@Vito0912 commented on GitHub (Aug 30, 2025): @Pimmetje Can you check where it tries to redirect you when you click the Login with OpenID button? I have never worked with Nuxt, so I don’t know why it behaves the way it does, but we set a `serverUrl` *somewhere*: https://github.com/advplyr/audiobookshelf/blob/master/client/pages/login.vue#L135C1-L135C97 This does not send you to your current host, but instead to whatever is set in the env. That is a problem if the callback will send you to your current address. Maybe I am missing something, but this makes no sense to me. Of course, the host will not match if the env is wrong. In addition to this, I am not sure (and I think this makes the problem worse) that the host header gets overwritten by somewhat, at least in dev builds. I make the request with `Host: 192.168.178.100:3000`, but the header received in the validation method is `host: 'localhost:3333'`, which matches the address in the `serverUrl` env. So wherever this is set, it seems to be wrong (Note: In dev builds is always localhost:3333). Because of this, it does not even work to manually go to the same host. I get redirected to: `http://localhost:3333/audiobookshelf/auth/openid?callback=http://192.168.178.100:3000/audiobookshelf/login` If I change it manually to the correct values: `http://192.168.178.100:3000/audiobookshelf/auth/openid?callback=http://192.168.178.100:3000/audiobookshelf/login` The host is still seen as `localhost:3333` and it fails. It works on all my production systems, so I don’t know why some of you have this issue, but I guess the `serverUrl` is set to http for the OP e.g.

adam commented

@Pimmetje commented on GitHub (Sep 1, 2025):

I get the following redirect:
https://audiobookshelf.example.org/audiobookshelf/auth/openid?callback=https://audiobookshelf.example.org/audiobookshelf/login
So in my case it detects/redirects to the correct url. Only the verification does not compare to the correct url.

@Pimmetje commented on GitHub (Sep 1, 2025): I get the following redirect: https://audiobookshelf.example.org/audiobookshelf/auth/openid?callback=https://audiobookshelf.example.org/audiobookshelf/login So in my case it detects/redirects to the correct url. Only the verification does not compare to the correct url.

adam commented

@Vito0912 commented on GitHub (Sep 1, 2025):

I am not sure if this will fix it for you, but as for NPM it sent a wrong proto:
'x-forwarded-proto': 'http, https'

(It should just be http or https) https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto

I just assume HA-proxy does the same. #4635 should fix this.

@Vito0912 commented on GitHub (Sep 1, 2025): I am not sure if this will fix it for you, but as for NPM it sent a wrong proto: `'x-forwarded-proto': 'http, https'` (It should just be http or https) https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto I just assume HA-proxy does the same. #4635 should fix this.

adam commented

@Sapd commented on GitHub (Sep 2, 2025):

Hello,

this change was made by me and advplyr because of a high security issue in regards to redirects. You should not revert back to an old version.

Make sure that x-forwarded-proto is correctly set. Given your error message, your reverse proxy is not correctly set up.

The code here does that:

const currentProtocol = req.secure || req.get('x-forwarded-proto') === 'https' ? 'https' : 'http'

If x-forwarded-proto is not set, it might fall back to http.

@Sapd commented on GitHub (Sep 2, 2025): Hello, this change was made by me and advplyr because of a high security issue in regards to redirects. You should not revert back to an old version. Make sure that `x-forwarded-proto` is correctly set. Given your error message, your reverse proxy is not correctly set up. The code here does that: ``` const currentProtocol = req.secure || req.get('x-forwarded-proto') === 'https' ? 'https' : 'http' ``` If x-forwarded-proto is not set, it might fall back to http.

adam commented

@Vito0912 commented on GitHub (Sep 2, 2025):

@Sapd NPM by default appends a list of protocols used. See #4635 which why it fails for so many.
I got this reproduced on a completely fresh install with minimal setup and all defaults left on.

@Vito0912 commented on GitHub (Sep 2, 2025): @Sapd NPM by default appends a list of protocols used. See #4635 which why it fails for so many. I got this reproduced on a completely fresh install with minimal setup and all defaults left on.

adam commented

@Sapd commented on GitHub (Sep 2, 2025):

@Sapd NPM by default appends a list of protocols used. See #4635 which why it fails for so many. I got this reproduced on a completely fresh install with minimal setup and all defaults left on.

I see. I checked your code and LGTM.

@Sapd commented on GitHub (Sep 2, 2025): > [@Sapd](https://github.com/Sapd) NPM by default appends a list of protocols used. See [#4635](https://github.com/advplyr/audiobookshelf/pull/4635) which why it fails for so many. I got this reproduced on a completely fresh install with minimal setup and all defaults left on. I see. I checked your code and LGTM.

adam commented

@github-actions[bot] commented on GitHub (Oct 8, 2025):

Fixed in v2.30.0.

@github-actions[bot] commented on GitHub (Oct 8, 2025): Fixed in [v2.30.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.30.0).

adam commented

@Pimmetje commented on GitHub (Oct 10, 2025):

Added header X-Forwarded-Proto https (using set header in ha proxy)
Now it is working thanks for the fix.

@Pimmetje commented on GitHub (Oct 10, 2025): Added header X-Forwarded-Proto https (using set header in ha proxy) Now it is working thanks for the fix.

adam commented

@jvines commented on GitHub (Oct 11, 2025):

This keeps happening to me. I am in 2.30.0, but still get the error when using authentik:

[2025-10-11 15:23:29.999] WARN: [OidcAuth] Rejected callback URL to different origin: https://abs.mydomain.com/audiobookshelf/login (expected http://abs.mydomain.com)
[2025-10-11 15:23:30.000] WARN: [Auth] Rejected invalid callback URL: https://abs.mydomain.com/audiobookshelf/login

@jvines commented on GitHub (Oct 11, 2025): This keeps happening to me. I am in 2.30.0, but still get the error when using authentik: ``` [2025-10-11 15:23:29.999] WARN: [OidcAuth] Rejected callback URL to different origin: https://abs.mydomain.com/audiobookshelf/login (expected http://abs.mydomain.com) [2025-10-11 15:23:30.000] WARN: [Auth] Rejected invalid callback URL: https://abs.mydomain.com/audiobookshelf/login ```

adam commented