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]: Add an HTTPS redirect URL for OIDC support on mobile #1571

New Issue
Closed
opened 2026-04-24 23:50:18 +02:00 by adam · 2 comments
adam commented 2026-04-24 23:50:18 +02:00
Owner
Copy Link
Copy Source

Originally created by @mark-monteiro on GitHub (Dec 2, 2023).

Describe the feature/enhancement

Currently, the mobile app uses the redirect URI audiobookshelf://oauth for the mobile app. I'm not sure how common it is for OAuth providers to support custom schemes in the redirect URI, but at least for Authelia, only the http or https schemes are supported (see docs). For OAuth providers with this limitation, it is not possible to use OIDC on the mobile app.

I am going to quote the documentation from Immich on how this problem is solved in that application, because I think the same approach can be used here:

The redirect URI for the mobile app is app.immich:/, which is a Custom Scheme. If this custom scheme is an invalid redirect URI for your OAuth Provider, you can work around this by doing the following:

  1. Configure an http(s) endpoint to forwards requests to app.immich:/
  2. Whitelist the new endpoint as a valid redirect URI with your provider.
  3. Specify the new endpoint as the Mobile Redirect URI Override, in the OAuth settings.

With these steps in place, you should be able to use OAuth from the Mobile App without a custom scheme redirect URI.
info

Immich has a route (/api/oauth/mobile-redirect) that is already configured to forward requests to app.immich:/, and can be used for step 1.

I think a new https endpoint should be defined on the server that redirects to audiobookshelf://oauth, so that this scenario can be supported.

The redirect URI for the mobile app would also have to be changed to point to this new endpoint. Alternatively, the redirect URI for the mobile app could be configurable with a server setting so that users can chose to either use the new https endpoint or audiobookshelf://oauth as the redirect URI. This is the approach taken in Immich, though I'm not entirely sure why, since it seems simpler to just always use the HTTPS endpoint. Perhaps it was made configurable in order to avoid introducing a breaking change.

Originally created by @mark-monteiro on GitHub (Dec 2, 2023). ### Describe the feature/enhancement Currently, the mobile app uses the redirect URI `audiobookshelf://oauth` for the mobile app. I'm not sure how common it is for OAuth providers to support custom schemes in the redirect URI, but at least for Authelia, only the `http` or `https` schemes are supported ([see docs](https://www.authelia.com/configuration/identity-providers/open-id-connect/#redirect_uris)). For OAuth providers with this limitation, it is not possible to use OIDC on the mobile app. I am going to quote the [documentation from Immich](https://immich.app/docs/administration/oauth#mobile-redirect-uri) on how this problem is solved in that application, because I think the same approach can be used here: > The redirect URI for the mobile app is `app.immich:/`, which is a [Custom Scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app). If this custom scheme is an invalid redirect URI for your OAuth Provider, you can work around this by doing the following: > > 1. Configure an http(s) endpoint to forwards requests to app.immich:/ > 2. Whitelist the new endpoint as a valid redirect URI with your provider. > 3. Specify the new endpoint as the Mobile Redirect URI Override, in the OAuth settings. > > With these steps in place, you should be able to use OAuth from the [Mobile App](https://immich.app/docs/features/mobile-app) without a custom scheme redirect URI. info > Immich has a route (/api/oauth/mobile-redirect) that is already configured to forward requests to app.immich:/, and can be used for step 1. I think a new https endpoint should be defined on the server that redirects to `audiobookshelf://oauth`, so that this scenario can be supported. The redirect URI for the mobile app would also have to be changed to point to this new endpoint. Alternatively, the redirect URI for the mobile app could be configurable with a server setting so that users can chose to either use the new https endpoint or `audiobookshelf://oauth` as the redirect URI. This is the approach taken in Immich, though I'm not entirely sure why, since it seems simpler to just always use the HTTPS endpoint. Perhaps it was made configurable in order to avoid introducing a breaking change.
adam added the enhancement label 2026-04-24 23:50:18 +02:00
adam closed this issue 2026-04-24 23:50:19 +02:00
adam commented 2026-04-24 23:50:19 +02:00
Author
Owner
Copy Link
Copy Source

@Sapd commented on GitHub (Dec 2, 2023):

I also thought about implementing that because it is a workaround for Googles' Policy on non-https URLs, however I did not come around in doing that time wise.

We probably just need a new route /auth/openid/mobile and forward the code and state parameter and redirect (and verify the state parameter with the session to be sure before redirecting).

An Option for just using the app redirect URI is not needed.

Edit: A good approach should be:

  • Keep the Client as is, with audiobookshelf://oauth hardcoded in the app, which basically describes our client
  • Catch the redirect_uri in our /auth/openid route, and use as-is if its to /auth/openid/callback, or if not, check if its in the whitelist
  • If its in the whitelist, save in the session the redirecturi and use it in oidcStrategy._params.redirect_uri to generate a correct URI to the auth provider
  • Create a route like /auth/openid/mobile-redirect
  • Verify if the passed state parameter is the same as in our session (just to be sure and safe)
  • Take the redirect of the session, and redirect the client to that link forwarding also code and state-parameter which were passed to our route

The whitelist would be in the ui and pre-filled with audiobookshelf://oauth. Other URIs could be added for enabling 3rd party apps.

@Sapd commented on GitHub (Dec 2, 2023): I also thought about implementing that because it is a workaround for Googles' Policy on non-https URLs, however I did not come around in doing that time wise. We probably just need a new route `/auth/openid/mobile` and forward the code and state parameter and redirect (and verify the state parameter with the session to be sure before redirecting). An Option for just using the app redirect URI is not needed. Edit: A good approach should be: - Keep the Client as is, with `audiobookshelf://oauth` hardcoded in the app, which basically describes our client - Catch the `redirect_uri` in our `/auth/openid` route, and use as-is if its to `/auth/openid/callback`, or if not, check if its in the whitelist - If its in the whitelist, save in the session the redirecturi and use it in `oidcStrategy._params.redirect_uri` to generate a correct URI to the auth provider --- - Create a route like `/auth/openid/mobile-redirect` - Verify if the passed state parameter is the same as in our session (just to be sure and safe) - Take the redirect of the session, and redirect the client to that link forwarding also `code` and `state`-parameter which were passed to our route The whitelist would be in the ui and pre-filled with `audiobookshelf://oauth`. Other URIs could be added for enabling 3rd party apps.
adam commented 2026-04-24 23:50:20 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Dec 24, 2023):

Added in v2.7.0

@advplyr commented on GitHub (Dec 24, 2023): Added in [v2.7.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.7.0)
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 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#1571
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?