[Feature Request] Add support for OIDC authentication

[sbordeyne]

[Feature Request] Add support for OIDC authentication

[taos15]

@Syer10 this is something I was thinking on work on. the implementation is pretty much the same as the trackers logic, not having the tracker login working was my bloacker on how it could be implemented.

The work flow is the same as anilist login, instead of logic to the anilist endpoint with the redirect. We are just changing the idp. for example with keyclack my redirect is keycloack.domain.tld/some/realm/protocol/openid-connect/auth you just need to config the post request to that uri and you will get a JWT, just like anilist.

The main think that need to be implementd is protecting the api route when oath auth is set to enable. then all the endpoints can use that JWT for the request. That is the broad idea of the workflow without going into the details.

I havent delete this PR because it will be the basic to setup the oath tologin.

[taos15]

For a complete implementation of what you are asking, multi-users account needs to be implemented. Custom
identity providers (idp) like keycloack could be implemented without multi-users, since the user will manage the users in they idp. But social login like github, google, etc will be challenging. Since if you dont have a list of "authorized users", anyone can login to your server with a social media. To cover the whole spectrum of this request, both custom idp (authelia, authentik, keycloack), and social media (google, facebook, or github) should be supported. Not every user will have the knowledge to setp a custom idp (like keycloack). To make the feature appealing a signup, with multi-users implementation, will be needed.

So, I think signup (it makes a list of authorized users for social login) and multi-users needs to be supported before oath2 can make sense.

[Kickunio]

It's possible to do that even now. I did it yesterday using keycloak, oauth2-proxy and nginx proxy manager just yesterday.
All in a docker container

[Syer10]

This would first require our own account solution, which is WIP here #623

[Robonau]

This would first require our own account solution, which is WIP here #623

not really,u could mostly leave the accounts up to the OIDC provider

and just have what currently exists being authenticated by the OIDC

all that would be needed on suwaoymi would be the OIDC implementation and a list of "users" that are allowed access (u might not even need the list OIDC might deal with this i don't remember)
you don't need to split stuff up in to users to do this

[sbordeyne]

This would first require our own account solution, which is WIP here #623

I don't think having a User account system in tachidesk would be a requirement to implement OIDC logins, as all of that can be offloaded to the OIDC server (after all you can get the user account, and can even save roles / user attributes, at least in keycloak if the oidc grants are configured properly), though it would be a nice improvement regardless

To give a bit more context into my use case, I want to be able to use tachidesk as I use jellyseerr, which means I want it to be the source of my manga downloads, and have my friends/family download them in tachidesk, but also provide them in komga, for convenience (the komga UI is a bit more to my liking for reading, plus it supports offline downloads as well, which make it great as a federated platform for readarr downloads as well). My goal would be to give access to friends to my tachidesk instance, let them download mangas from there, then provide all of the mangas my friends want to read as well as my own into komga, and have them read through them using tachiyomi with the komga extension (if it has not been disabled yet).

User accounts would be neat though, to track the reading progress of each user individually, as well as to restrict the kind of mangas / categories they have access to :)

[taos15]

This would first require our own account solution, which is WIP here #623

I don't think having a User account system in tachidesk would be a requirement to implement OIDC logins, as all of that can be offloaded to the OIDC server (after all you can get the user account, and can even save roles / user attributes, at least in keycloak if the oidc grants are configured properly), though it would be a nice improvement regardless

To give a bit more context into my use case, I want to be able to use tachidesk as I use jellyseerr, which means I want it to be the source of my manga downloads, and have my friends/family download them in tachidesk, but also provide them in komga, for convenience (the komga UI is a bit more to my liking for reading, plus it supports offline downloads as well, which make it great as a federated platform for readarr downloads as well). My goal would be to give access to friends to my tachidesk instance, let them download mangas from there, then provide all of the mangas my friends want to read as well as my own into komga, and have them read through them using tachiyomi with the komga extension (if it has not been disabled yet).

User accounts would be neat though, to track the reading progress of each user individually, as well as to restrict the kind of mangas / categories they have access to :)

I understand your workflow since that is how I use (or want to use) suwoyomi as well. Until the multi-users and oath2 gets implemented, I am using keycloak with traefik for the oath2, and komga (with oath2 authentication) extension for the local sources.