-
-
Notifications
You must be signed in to change notification settings - Fork 264
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
feat: support OIDC authentication #184
base: develop
Are you sure you want to change the base?
Conversation
You may want to blur some of the info in the image |
Ah I see that you resolved the merge conflicts. Was going to ask. Thanks |
@michaelhthomas Hi. I tried to test this PR, however, during first setup in the library step, I get this error and I am not able to continue it setup |
Uh oh... I'm pretty sure that means you made it to the second page but aren't logged in with Plex or Jellyfin, which probably means the login failed and I need to add some better error handling. Which one were you testing? |
Jellyfin. That is from the libraries setup page right after logging in |
@Fallenbagel Found the bug and am working on a fix. Got a question...right now there's a value for |
We need the |
Ok sweet. I'll test Emby with my current implementation to make sure everything works as expected, and when it's implemented properly there will probably be some changes that need to be made to the login window / setup wizard. |
I have not tested yet but if it works for emby it should work for jellyfin. Will test tonight |
I tested the setup and it indeed worked. However, as I have no way of testing OIDC, I will deploy this as a preview tag ( |
@Fallenbagel resolved the merge conflicts. OIDC is working great for me (using authentik) but would love to have some others test with different OIDC providers. |
Is LDAP possible with this? (I don't really know OIDCs and stuff so) |
Not directly. A number of oauth2 / OIDC providers do integrate with LDAP (including authentik) for authentication, but oauth2 is much higher level. Where LDAP acts more like an external users database, an OIDC/oauth provider handles all the sign in and authentication logic. Plex SSO actually uses oauth2 afaik, it just doesn't conform to the OIDC standard. |
I can test with Keycloak, just learning how to compile and run this build still. |
If you want to compile it natively to test instead of the deployed docker snapshot, pull this PR and try it And please provide feedback. Feedback is very much needed (since this is kind of a big feature) |
Howdy, I am excited to see this MR, its certainly something that is missing in my setup and hence i (somewhat selfishly) want to help. My relevant setup: I have never implemented open id login mechanism but I have connected few applications to OpenID that Authelia provides (as outlined above), I am happy to test and provide feedback. I have ran your branch locally and have few questions. A typical config in Authelia looks something like this
(I believe data needed to setup is somewhat similar for KeyCloak +- some small details) In particular both Authelia and the app (Jellyseerr in this case) need to have id and the secret, both of which are chosen by the client.. In addition authelia (keycloak also) needs the callback url and the required scopes. In your implementation I see place for id but not the secret, is there a way of adding this ? I also do not know (maybe i am missing something obvious) what the callback url is and what scopes are required. |
Because Jellyseerr is a SPA (single page app), it uses the OAuth PKCE authorization flow instead of the traditional authorization flow. Since all of the login and (most of) the validation logic occurs on the client when using this flow, the client secret is not used. This is a "public" authorization flow, so the configuration will look a little bit different from apps using the traditional authorization flow. This looks to be the relevant configuration option for Authelia, and other providers should have similar options. In order to maintain security with this mechanism, be sure that the redirect URLs are limited only to your Jellyseerr instance ( |
That makes a lot of sense! I take it then I need something like this
I am building the docker image now, will shortly deploy and update. |
Docker image is already built tho. Can be access through |
I have set up oidc with Authelia; everything works fine except that Full Library Scan and Recently Added Scan stopped working. There are no errors thrown, not on Jellyseeerr and not Emby. The owner-user can login with oidc and is of type Emby user (3). Is anybody else having these problems? |
I have the same problem. Jellyseerr fails to access the Jellyfin API, so things like the sync or scan of the Jellyfin libraries don't work. |
Can you share your logs. When you press sync or scan. Need more info. |
I'm using the latest container image
If I configure the Jellyfin internal URL to be my reverse proxy, I can see that the failed request goes to the
It looks like the double slash is causing problems:
The relevant parts of the
In addition to that, I had to grant myself owner permissions by editing the database manually:
|
After a bit more digging I've found a workaround for the 404 errors when accessing the Jellyfin API. The problem is that Jellyseerr doesn't know my Jellyfin user id, so the call to I've discovered my user id and created an API key in Jellyfin, then added them to my user in Jellyseerr:
After that, the library scan works. I think this Jellyfin API key setting should be a global option and not per-user. |
We dont use apikeys. We use auth tokens (specifically the auth token of the owner account for syncing). So whatever apikey you generate on jellyfin doesn't matter as we only use authTokens. Which is something that's designed to be automatically retrieved when logging in. Sounds like your jellyfinUserId changed (which should never happen) but that was causing jellyseerr to not update your authtoken(?) but im not sure why you were getting a 404. Just an fyi, the behavior of login, authtokens are already very different from this PR (I think this pr is about 2 versions old). |
Yeah.... I'm thinking of just making a new PR based on the one upstream (sct/overseerr#3746) with some tweaks and additional features from this one. Since that might have a smaller scope, hopefully it could end up being merged more quickly. I could then make some smaller PRs with additional user interface and functionality improvements that aren't strictly necessary to get the feature released. |
That would be great. Specifically the biggest change we're gonna get on auth is #773 and apikeys (we're gonna stop authtokens) |
There is a bug at least in the latest build: When a user has an email like John.Doe@gmail.com in Authentik (watch at the upper-cases) and then trys to login, he will get an error and the log report:
Changing his email to lower case in Authentik fixes it. |
Can confirm this bug still happens my side. And I am using Keycloak, so can't use this fix. |
I'm having problems (statuscode 401) getting the required claims working with "custom scopes". No matter what scopes I enter in the jellyseer oidc configuration, only "email openid profile" appear to be requested according to Authentik. When the Required Claims value is something that is returned without needing a specific scope(email_verified), my problems with 401 errors are fixed. Have i messed up something or is this an actual bug? |
Thank you! |
@chinyongcy or @crltc....Has anyone figured out the custom scopes issue with Authentik? I've tried everthing, but cant pass through a custom property. Its not showing in my payload in jellyseer. I can only make this work with email/email_verified. Thats a bummer. I have a custom scope going though in jellyfin OIDC plugin, so it seems the issue is on the jellyseer side, not Authentik. |
This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged. |
For those that have been running authelia and recently updated, this suggested change fixed my errors post update. |
Is there a rough idea on a timeline for this support? Really want to migrate my users to jellyfin and jellyseer using Authelia as user management |
changes to fix build after merging with latest develop re Fallenbagel#184
I have managed to set this up with authelia, but there is one small error, when signing out it redirects to: https://jellyseerr.example.com/api/v1/auth/undefined instead of the login page or whatever page it was trying to redirect to. |
Any information of the status of this PR? Currently using the preview branch which seems to work nicely, would love to see it merged. |
Hello, you should have a look here #883 |
I dont 100% understand why this cant be parallel? So this PR being integrated before Linking is introduced. Just seems this feature will be pushed more and more because of more and more changes to the underlying system and parallel development state. :/ |
I agree with @Ruakij, it seems this has been pushed for over 2 years yet there’s a build with the feature fully operational. Are there any downsides to merging what’s in |
This PR is way outdated. It's not even close to the state that And if you look at #926 you can find that it's in the roadmap. But we need to completely rework this pr to even be compatible. |
Alright @Fallenbagel, no worries. Thanks for the work! |
If there are some rework here. We should change the callback schema to allow https even if you run it in http because you can deploy Jellyseer behind a reverse proxy which is quite common. |
Description
Adds support for logging in using an OIDC Identity Provider (Auth0, Authentik, Keycloak, etc.).
Refactors Plex OAuth login to be in its own component, like the other identity providers.
Screenshot (if UI-related)
To-Dos
yarn build
yarn i18n:extract
Issues Fixed or Closed