Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Add support for OIDC authentication #926

Open
sbordeyne opened this issue Apr 2, 2024 · 7 comments
Open

[Feature Request] Add support for OIDC authentication #926

sbordeyne opened this issue Apr 2, 2024 · 7 comments
Labels
enhancement New feature or request

Comments

@sbordeyne
Copy link

sbordeyne commented Apr 2, 2024

What feature should be added to Suwayomi?

  • Add support for OIDC (OpenID Connect) instead of HTTP Basic Auth.
  • OIDC servers include : Auth0, Keycloak, Authentik
  • OIDC flows work by first:
    • going to the website
    • clicking on a button/link to redirect to the OIDC server, on well defined URLs
    • The user logs in on the OIDC server
    • The OIDC server redirects the user back to the calling app, with a code
    • The app makes a token exchange HTTP query to the OIDC server, echanging the code for a long-lived refreshToken, as well as a short-lived accessToken

Why/Project's Benefit/Existing Problem

I run tachidesk on my homelab, and I want to be the sole user, along with some specified people from my family/friends. I also run keycloak on that server, which makes it an ideal solution for that use case. OIDC is a standard, so it should benefit a lot of other people, as well as to offload any authentication issues towards battle-tested solutions.

HTTP Basic Auth is a solution for now, but I cannot share the credentials to anyone, making it unsuitable to provide a backend for some close friends / family (which are not always very wise especially around computer security topics)

Running an authentication backend like keycloak allows :

  • federated single sign on
  • passwordless authentication
  • 2FA policies
@sbordeyne sbordeyne added the enhancement New feature or request label Apr 2, 2024
@Kickunio
Copy link

Kickunio commented Apr 3, 2024

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
Copy link
Collaborator

Syer10 commented Apr 3, 2024

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

@Robonau
Copy link
Contributor

Robonau commented Apr 3, 2024

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

@taos15
Copy link

taos15 commented Apr 3, 2024

@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.

@sbordeyne
Copy link
Author

sbordeyne commented Apr 4, 2024

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
Copy link

taos15 commented Apr 4, 2024

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.

@taos15
Copy link

taos15 commented Apr 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants