Skip to content
SoundLeaf
App Store
Menu

Server guides · Troubleshooting

Audiobookshelf OpenID login errors and fixes

Fix Audiobookshelf OpenID login errors: check X-Forwarded-Proto, the issuer URL, user matching and sign-in timeouts. Each error with its cause and fix.

All server guides
On this page
  1. ”Invalid callback URL - must be same-origin”
  2. Same error when you open Audiobookshelf at the root of your domain
  3. ”No data in openid callback - OPError: expected 200 OK, got: 302 Found”
  4. ”No data in openid callback - Unauthorized”
  5. ”User not found and email is not verified”
  6. ”User not found and auto-register is disabled”
  7. Auto Register broken in 2.26.0
  8. Errors about groups (Group Claim)
  9. ”No session” behind a reverse proxy
  10. ”No callback or already expired”
  11. ”User has no password set. Might have been created with OpenID”
  12. Set up OpenID login for iPhone apps

If Audiobookshelf OpenID sign-in fails, find the error in the server log and match it to a section below. Most come down to your reverse proxy settings, the Issuer URL, how Audiobookshelf finds the person’s account, or a sign-in that took too long.

OpenID lets people sign in through a separate login service, such as Authentik, Authelia or Pocket ID. Each section gives the cause, the fix and, where there is one, the version that changed it.

Two things to do before anything else:

  • Restart Audiobookshelf after every change to the authentication settings. The settings page says “Restart your server after saving to apply OIDC changes.”
  • Update the server. Several of the fixes below shipped in v2.30.0 and v2.37.1. Checked against v2.37.1.

Most of these messages are only in the server log. An admin can read it in Settings > Logs on the web page, or with docker logs audiobookshelf in Docker (use your container name). The log usually gives more detail than the message shown in your app.

”Invalid callback URL - must be same-origin”

You see this on the web page when you press the OpenID button. Phone apps don’t use this check.

Cause: Audiobookshelf compares the page you came from with its own address. It works out its own address from headers your reverse proxy sends along with each request (the proxy is the server that passes outside requests on to Audiobookshelf). X-Forwarded-Proto is the header that says whether the visitor used HTTPS. If the proxy doesn’t send X-Forwarded-Proto: https, the server thinks it runs on http, your browser is on https, and the two don’t match.

Fix:

  1. Update to v2.30.0 or later. Nginx Proxy Manager sends X-Forwarded-Proto: http, https, which older versions read as http. v2.30.0 fixed that (#4609).

  2. Make sure your proxy sends the header. In nginx: proxy_set_header X-Forwarded-Proto $scheme;. In Apache, one user fixed it with:

    RequestHeader set X-Forwarded-Proto "https"
    

    For HAProxy, Caddy or Traefik, set the same header to https. The reverse proxy guide has full examples.

  3. Restart Audiobookshelf and try again.

Same error when you open Audiobookshelf at the root of your domain

If the header is right and you still get “Invalid callback URL - must be same-origin”, check the address in your browser. Audiobookshelf only accepts a return address under its base path, which is /audiobookshelf/ by default. If you open https://books.example.com/ instead of https://books.example.com/audiobookshelf/, the server rejects it. The log says “Rejected callback URL outside router base path”.

Fix: open the web page at https://your.server.com/audiobookshelf/ (or your own base path, if you changed it) and sign in from there. This is still open as #5287. Phone apps are not affected.

”No data in openid callback - OPError: expected 200 OK, got: 302 Found”

Full log line: [Auth] No data in openid callback - OPError: expected 200 OK, got: 302 Found. The web page shows “Unauthorized”.

Cause: your provider signed you in. Then Audiobookshelf asked the provider for the sign-in result, and the provider (or something in front of it) answered with a redirect instead. The server does not follow that redirect. In #4208, a project contributor points to an http address being used where the provider expects https (comment), and to checking the Issuer URL and restarting (comment).

Fix:

  1. Check Issuer URL in Settings > Authentication. Copy the exact issuer URL your provider publishes for this app, including any path it has. Don’t add a page path of your own.
  2. Press Auto-populate next to Issuer URL to fill in the other addresses from the provider, then check they all start with https://.
  3. If a Cloudflare login or other proxy rule sits in front of the provider, make sure the server can reach the provider without being sent to a login page.
  4. Save and restart Audiobookshelf.

”No data in openid callback - Unauthorized”

Cause: the provider signed you in, but Audiobookshelf could not complete the sign-in. The log line just before it, starting with [OidcAuth] openid callback error, says why. The common reasons are below: no matching user, an unverified email, or a group claim problem.

Fix: read that earlier log line and find it in the sections below.

”User not found and email is not verified”

Full log line: [User] openid: User not found and email "[email protected]" is not verified.

Cause: Match existing users by is set to Match by email, and your provider sent email_verified: false for this person. Audiobookshelf won’t link an account by an unverified email. Pocket ID sends this value per user, so a Pocket ID user whose email isn’t verified hits this.

Fix: pick one:

  • Keep Match by email: mark the email as verified in your provider, and make sure the email on the Audiobookshelf account is the same one the provider sends.
  • Switch to Match by username: the Audiobookshelf username must then match the username the provider sends.

”User not found and auto-register is disabled”

Cause: no Audiobookshelf user matches this person, and Auto Register is off.

Fix: pick one:

  • Turn on Auto Register in Settings > Authentication to create the account at first sign-in.
  • Create the user in Settings > Users with the same email or username, and set Match existing users by to Match by email or Match by username to suit.

Auto Register broken in 2.26.0

In v2.26.0, signing in a new person with Auto Register on failed (#4485). v2.26.1 fixed it. Update if you are still on 2.26.0.

Errors about groups (Group Claim)

Group Claim is the name of the field your provider uses to send a person’s groups, usually groups. These errors appear when it is filled in:

  • Group claim groups not found or empty in userinfo: the provider sent no groups claim for this person. Check the claim name and that the provider includes it.
  • No valid group found in userinfo: the groups list has none of admin, user or guest. Add the person to one of those groups in your provider (any case works).
  • map is not a function in the error: the groups field is not a list. Set your provider to send a list of group names, like ["user"].

To skip roles from the provider, leave Group Claim empty. New users then get the User role.

”No session” behind a reverse proxy

The web page used to show a bare “No session” page. Since v2.37.1 it sends you back to the login page with “No sign-in session”. The server still answers phone apps with “No session”; what you see depends on the app.

Cause: when you come back from the provider, the browser no longer sends the cookie that ties the sign-in together, or the server has forgotten it. Reports in #5127 point to Firefox’s bounce tracking protection dropping the cookie, and to an Authentik update. A server restart in the middle of a sign-in also does it, because the server keeps sign-ins in memory.

Fix: this is still open. Things that help:

  1. Try another browser. In the report, the same setup worked in Chrome and failed in Firefox.
  2. Don’t restart the server while someone is signing in.
  3. Finish the sign-in in one go, without the back button.

”No callback or already expired”

Cause: when the web sign-in came back, the browser no longer had the short-lived cookie that says where to return. Usually it expired because the sign-in took too long: before v2.37.1 the limit was 2 minutes, and the server showed a bare page with this text. A browser that blocks or drops the cookie gives the same error.

Fix: update to v2.37.1, which gives you 10 minutes and sends you back to the login page with the error (#5614). One user reported it still happening on the latest version (v2.37.1 at the time) a few days after the fix. If you see it, go to your Audiobookshelf address and sign in again instead of pressing back. Your provider may sign you in straight away.

”User has no password set. Might have been created with OpenID”

Full log line: [LocalAuth] Failed login attempt for username "name" from ip ... (User has no password set. Might have been created with OpenID). SoundLeaf shows “Invalid username or password. Check both and try again.” Other apps show their own message.

Cause: someone tried the username and password form for an account that has no password. Accounts made by Auto Register have none.

Fix: use the OpenID button. If the person also needs password sign-in, an admin sets a password for them in Settings > Users. See how to reset an Audiobookshelf password.

Set up OpenID login for iPhone apps

Phone apps need two more steps:

  1. In Settings > Authentication, add each app’s own address to Allowed Mobile Redirect URIs. The official app uses audiobookshelf://oauth, and SoundLeaf uses soundleaf://oauth.
  2. In your provider, allow the mobile redirect address that the same settings page shows, like https://your.server.com/auth/openid/mobile-redirect. Copy it from there so it includes the Subfolder for Redirect URLs if one is set.

The SoundLeaf steps and its error messages are in Sign in to SoundLeaf with OpenID.