feat: support OIDC authentication

[michaelhthomas]

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

• Successful build yarn build
• Translation keys yarn i18n:extract
• Database migration (if required)

Issues Fixed or Closed

• Fixes [Feature Request] Support login with OIDC #183
• Fixes [Feature request] SSO #86

[john-sp]

You may want to blur some of the info in the image

[fallenbagel]

Ah I see that you resolved the merge conflicts. Was going to ask. Thanks

[fallenbagel]

@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

[michaelhthomas]

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?

[fallenbagel]

Which one were you testing?

Jellyfin. That is from the libraries setup page right after logging in

[michaelhthomas]

@fallenbagel Found the bug and am working on a fix. Got a question...right now there's a value for MediaServerType.EMBY that's essentially unused, since emby is actually treated as MediaServerType.JELLYFIN with JELLYFIN_TYPE set to "emby". Would you be ok with removing MediaServerType.EMBY to avoid confusion, or would you rather everything use MediaServerType.EMBY instead of JELLYFIN_TYPE for consistency?

[fallenbagel]

We need the MediaServerType=Emby as the current emby implementation is temporary. We are going to be implementing emby without the env variable through api which would also allow us to have simultaneous server support. So we need it

[michaelhthomas]

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.

[fallenbagel]

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

[fallenbagel]

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 (:preview-pr184 for testing for now

[michaelhthomas]

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

[fallenbagel]

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

[michaelhthomas]

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

[BoBeR182]

I can test with Keycloak, just learning how to compile and run this build still.

[fallenbagel]

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)

[atropos112]

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 am running Sonarr, Radarr, Jellyfin and of course Jellyseerr. I am also running Authelia which I currently use as my OpenID solution for ArgoCD, WikiJs, Grafana, Harbor and Gitlab.

---

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

- id: <user-picked-id-here>
  pre_configured_consent_duration: '365d'
  description: idk
  secret: <SECRETHERE>
  public: false
  authorization_policy: one_factor
  audience: []
  scopes:
    - openid
    - email
    - profile
  redirect_uris:
    - <CALLBACKURL>
   response_modes:
        - form_post 

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

[michaelhthomas]

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 am running Sonarr, Radarr, Jellyfin and of course Jellyseerr. I am also running Authelia which I currently use as my OpenID solution for ArgoCD, WikiJs, Grafana, Harbor and Gitlab.

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

- id: <user-picked-id-here>
  pre_configured_consent_duration: '365d'
  description: idk
  secret: <SECRETHERE>
  public: false
  authorization_policy: one_factor
  audience: []
  scopes:
    - openid
    - email
    - profile
  redirect_uris:
    - <CALLBACKURL>
   response_modes:
        - form_post 

(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 (https://your-jellyseerr-instance.xyz/login). Also, the openid, profile, and email scopes are all used so that Jellyseer can view users' names and email addresses. Thanks for being open to testing this out!

[atropos112]

That makes a lot of sense! I take it then I need something like this

      - id: jellyseerr
        public: true
        authorization_policy: two_factor
        audience: []
        scopes:
        - openid
        - email
        - profile
        redirect_uris:
        - https://jellyserrr-instance.xyz/login
        userinfo_signing_algorithm: none
        response_modes:
        - form_post 

I am building the docker image now, will shortly deploy and update.

[fallenbagel]

That makes a lot of sense! I take it then I need something like this

      - id: jellyseerr
        public: true
        authorization_policy: two_factor
        audience: []
        scopes:
        - openid
        - email
        - profile
        redirect_uris:
        - https://jellyserrr-instance.xyz/login
        userinfo_signing_algorithm: none
        response_modes:
        - form_post 

I am building the docker image now, will shortly deploy and update.

Docker image is already built tho. Can be access through preview-prxxx where xxx is this PRs number

[atropos112]

I wanted to test it further so I ran

docker build -t oicd-jellyseerr -f Dockerfile .
docker tag oidc-jellyseerr:latest myharbor.xyz/testing/oidc-jellyseerr:develop
docker push myharbor.xyz/testing/oidc-jellyseerr:develop

but when i run a pod with the above image I get

(pressing reload refreshes the page and this pop-up appears again)
this is strange, I tried running on the normal develop branch to see if its something with your changes (which I doubted) but I get the same issue. Data seems to need to be reloaded but even if i start on fresh pvc i still get this. Is there some variable I am missing ?

[michaelhthomas]

I wanted to test it further so I ran

docker build -t oicd-jellyseerr -f Dockerfile .
docker tag oidc-jellyseerr:latest myharbor.xyz/testing/oidc-jellyseerr:develop
docker push myharbor.xyz/testing/oidc-jellyseerr:develop

but when i run a pod with the above image I get

(pressing reload refreshes the page and this pop-up appears again)
this is strange, I tried running on the normal develop branch to see if its something with your changes (which I doubted) but I get the same issue. Data seems to need to be reloaded but even if i start on fresh pvc i still get this. Is there some variable I am missing ?

What happens when you press the reload button? That just looks like your browser still has the old version of the web interface cached

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.

[Alumni1506]

For people looking to use the latest version of authelia, using the previous working configuration will result in an error. You need to add token_endpoint_auth_method: 'client_secret_post' to the configuration file.

For those that have been running authelia and recently updated, this suggested change fixed my errors post update.

[nebb00]

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

[TheRedCyclops]

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.
No relevant logs

[mikevanes]

Any information of the status of this PR? Currently using the preview branch which seems to work nicely, would love to see it merged.

[lucaam]

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

[Ruakij]

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.
Linking needs to support multiple anyways and needs to migrate current states over, so this wouldnt be an exception. Ideally this would then only incur minimal changes there. (i.e. Enum + adding a Provider)

Just seems this feature will be pushed more and more because of more and more changes to the underlying system and parallel development state. :/

[0dragosh]

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 preview-OIDC and adding linking later?

[fallenbagel]

This PR is way outdated. It's not even close to the state that develop is in. We cannot just simply merge this pr.

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.

[0dragosh]

Alright @fallenbagel, no worries. Thanks for the work!

[pando85]

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.

[njhughes-01]

Im still running a really old dev branch as i don't want to break all my user logins if anyone moves to a newer branch and it functions can you please @ me. I understand this branch is in a rework state

[samip5]

Hi @michaelhthomas!

Is this PR abandoned? It sure looks that way and someone else could continue the work?

[michaelhthomas]

Hi @michaelhthomas!

Is this PR abandoned? It sure looks that way and someone else could continue the work?

Hi! Please read the earlier discussion. This will be revisited and implemented, but not in this PR. For now, I'll probably close this.

[samip5]

Hi @michaelhthomas!

Is this PR abandoned? It sure looks that way and someone else could continue the work?

Hi! Please read the earlier discussion. This will be revisited and implemented, but not in this PR. For now, I'll probably close this.

Hi! I did read the previous messages in the thread but it wasn't apparent to me what's the actual state except that it needs to be remade.

[michaelhthomas]

@samip5 I am still waiting for #883 to be merged. Once that is merged, a PR adding support for OpenID Connect should follow shortly thereafter.

[mobiledude]

Really looking forward to this!! Thanks for the great work guys!. This would mean I can ditch this and stay updated ;-)

[alleyu2]

Really looking forward to this!! Thanks for the great work guys!. This would mean I can ditch this and stay updated ;-)

Just curious what is this and hows does it help with SSO?

[samip5]

Really looking forward to this!! Thanks for the great work guys!. This would mean I can ditch this and stay updated ;-)

Just curious what is this and hows does it help with SSO?

Basically means they're still running this PR's code instead of being up-to-date.

[jridz]

@samip5 I am still waiting for #883 to be merged. Once that is merged, a PR adding support for OpenID Connect should follow shortly thereafter.

#883 just got accepted! Excited to see where this goes.

[crazyelectron-io]

Looking forward to OIDC support in the official release.

[edbourque0]

@samip5 I am still waiting for #883 to be merged. Once that is merged, a PR adding support for OpenID Connect should follow shortly thereafter.

@michaelhthomas Is this still in your short-term plans ?

[gauthier-th]

I'm locking this thread because nothing relevant is being said here.
Micheal will work on this when he has time, and we'll do our best to integrate this into Jellyseerr as quickly as possible. Keep in mind that we're all volunteers, and sometimes we have other obligations 😉

[gauthier-th]

The preview-OIDC tag now points to #1505 and not anymore to this PR.