[Enhancement]: Authorized applications

[rasmuslos]

Describe the feature/enhancement

To support the new OpenID connect login option all clients have to implement the new login strategy themselves. This means that applications have to register a unique URL scheme because audiobookshelf:// would conflict with the official app. From the apple docs:

If multiple apps register the same scheme, the app the system targets is undefined.
There’s no mechanism to change the app or to change the order apps appear in a Share sheet.

Users would have to add callback URLs for each third-party client they use, which is quite annoying.
On top of that trusting third-party developers to always adapt new login strategies is in my opinion quite optimistic. If for example 2FA auth is introduced for local accounts all client applications would have to be updated to not be rendered useless, or users would have to miss out on the feature to still be able to use their favourite app.

I would suggest that sign-ins are always handled by ABS and clients just receive a token. Similar to authorising a GitHub / Spotify / ... app. When a user wants to authenticate themselves the client application just opens a web browser and provides some information about itself. Something like

https://server/authorize?applicationName=Example&applicationDescription=Lorem%20Ipsum&applicationCallback=example%3A%2F%2Fauthorize

The user can review these and then choose to authorize the client or to reject the request. When the user grants permission (and logins in if required) they are redirected to the callback URL

example://authorize?token=TOKEN

This would make adding new login strategies much more simple because every single client would just support them without any additional work required

[Sapd]

I have written up a concept for that here: #2379 (comment)

Still I would recommend a whitelist for the mobile callbacks with audiobookshelf://oauth as default. However if wanted one could provide * or so als option for all URLs.

I would suggest that sign-ins are always handled by ABS and clients just receive a token. Similar to authorising a GitHub / Spotify / ... app. When a user wants to authenticate themselves the client application just opens a web browser and provides some information about itself. Something like

A Callback-URL is always passed in the first request (however without an App Description, which is not defined in the standard). See:
https://github.com/advplyr/audiobookshelf-app/blob/fed6579e08eca6db4b8f53574f5d23cdf8a0df01/components/connection/ServerConnectForm.vue#L199
I would also not advise changing it in something custom and reinventing the wheel, there is no need for that and the current flow follows the oauth2 standard. Third party apps should be able to even directly use a oauth2 library of their liking. Implementing a custom flow would also be not easier. In a custom flow you would still need PKCE.

Also GitHub, Spotify and co use standard oauth2 btw.

Edit: In theory on could add also the app name, by defining an optional parameter, and then first - like in a standard oauth2 flow - redirect to an internal ABS site asking if its okay with the name, and then redirect to the oauth provider. Depending on the configuration of the oauth2 provider the user would have to give the ok two times. This solution if really required in the future can be built on top of the other concept I have written up above. It would also work with oauth2 libraries.

[advplyr]

Added in v2.7.0