[Enhancement]: Allow authentication via the API #414

Closed
opened 2026-04-24 23:08:13 +02:00 by adam · 5 comments
Owner

Originally created by @duplaja on GitHub (Jun 2, 2022).

Describe the feature/enhancement

Right now, in order to log-in, the mobile apps need to hit the /login endpoint, which is the same as the web browser login.

Implementing an alternate authentication method via the API, and using this endpoint for the mobile apps, will allow the the browser login page to be put behind additional authentication much more easily (authelia, basic auth for that url, etc).

Originally created by @duplaja on GitHub (Jun 2, 2022). ### Describe the feature/enhancement Right now, in order to log-in, the mobile apps need to hit the `/login` endpoint, which is the same as the web browser login. Implementing an alternate authentication method via the API, and using this endpoint for the mobile apps, will allow the the browser login page to be put behind additional authentication much more easily (authelia, basic auth for that url, etc).
adam added the enhancement label 2026-04-24 23:08:13 +02:00
adam closed this issue 2026-04-24 23:08:14 +02:00
Author
Owner

@advplyr commented on GitHub (Jun 2, 2022):

I don't understand, why would the endpoints need to be different?

@advplyr commented on GitHub (Jun 2, 2022): I don't understand, why would the endpoints need to be different?
Author
Owner

@duplaja commented on GitHub (Jun 2, 2022):

Sure! Authelia protects by forcing non-bypassed urls / endpoints to redirect to a separate subdomain, to authenticate.

Ideally, I'd put audio.example.com/login behind Authelia, so that anyone who has not authenticated with my Authelia instance is forced to authenticate there first (allows me to do stuff like 2FA).

The mobile app (Android) sends the login request to audio.example.com/login as well, and since it's an app embed, it can't handle a redirect / throws an unknown error.

The preferred outcome (for me) would be to be able to protect the web login via Authelia, while still allowing the mobile apps to function by bypassing a point they authenticate with. I was able to get this to work via some manipulation of the trailing slash on that URL, but it's not the best to rely on.

@duplaja commented on GitHub (Jun 2, 2022): Sure! Authelia protects by forcing non-bypassed urls / endpoints to redirect to a separate subdomain, to authenticate. Ideally, I'd put `audio.example.com/login` behind Authelia, so that anyone who has not authenticated with my Authelia instance is forced to authenticate there first (allows me to do stuff like 2FA). The mobile app (Android) sends the login request to `audio.example.com/login` as well, and since it's an app embed, it can't handle a redirect / throws an unknown error. The preferred outcome (for me) would be to be able to protect the web login via Authelia, while still allowing the mobile apps to function by bypassing a point they authenticate with. I was able to get this to work via some manipulation of the trailing slash on that URL, but it's not the best to rely on.
Author
Owner

@Kramins commented on GitHub (Jul 1, 2022):

Would it not be better to support OpenId and/or Proxy Authentication Headers?

@Kramins commented on GitHub (Jul 1, 2022): Would it not be better to support OpenId and/or Proxy Authentication Headers?
Author
Owner

@advplyr commented on GitHub (Jul 1, 2022):

Yes I think so. That was being discussed here https://github.com/advplyr/audiobookshelf-app/issues/254

@advplyr commented on GitHub (Jul 1, 2022): Yes I think so. That was being discussed here https://github.com/advplyr/audiobookshelf-app/issues/254
Author
Owner

@advplyr commented on GitHub (Nov 24, 2022):

Closing this as an SSO solution requested in #998 overlaps

@advplyr commented on GitHub (Nov 24, 2022): Closing this as an SSO solution requested in #998 overlaps
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#414