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

feat: support OIDC authentication #184

Open
wants to merge 73 commits into
base: develop
Choose a base branch
from

Conversation

michaelhthomas
Copy link

@michaelhthomas michaelhthomas commented Jul 11, 2022

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)

Login Page

Settings Page

To-Dos

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

Issues Fixed or Closed

@john-sp
Copy link

john-sp commented Jul 14, 2022

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

@Fallenbagel
Copy link
Owner

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

@Fallenbagel
Copy link
Owner

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

@michaelhthomas
Copy link
Author

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

Which one were you testing?

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

@michaelhthomas
Copy link
Author

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

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

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

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

Fallenbagel commented Aug 18, 2022

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

@Fallenbagel Fallenbagel added the merge conflict Cannot merge due to merge conflicts label Sep 7, 2022
@michaelhthomas
Copy link
Author

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

Fallenbagel commented Sep 18, 2022

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

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

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

@Fallenbagel
Copy link
Owner

Fallenbagel commented Sep 22, 2022

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

atropos112 commented Sep 23, 2022

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

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

atropos112 commented Sep 24, 2022

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

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

atropos112 commented Sep 24, 2022

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
image
(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
Copy link
Author

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

@4WaYDp
Copy link

4WaYDp commented May 28, 2024

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?

@jorti
Copy link

jorti commented May 29, 2024

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.

@Fallenbagel
Copy link
Owner

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.

@jorti
Copy link

jorti commented May 29, 2024

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 docker.io/fallenbagel/jellyseerr:preview-OIDC.
The only message I get when I click on "Sync libraries" is:

2024-05-29T08:37:37.111Z [error][Jellyfin API]: Something went wrong while getting libraries from the Jellyfin server: Request failed with status code 404

If I configure the Jellyfin internal URL to be my reverse proxy, I can see that the failed request goes to the /Users//Views Jellyfin endpoint:

192.168.1.1 - - [29/May/2024:08:48:27 +0000] "GET /Users//Views HTTP/1.1" 404 988 "-" "-" 104003 "jellyfin@docker" "http://10.89.0.117:80" 1ms

It looks like the double slash is causing problems:

# curl -I https://jellyfin.example.com/Users//View
HTTP/2 404 
accept-ranges: bytes
alt-svc: h3=":443"; ma=2592000
content-type: text/html
date: Wed, 29 May 2024 08:51:52 GMT
etag: "65b785cb-3dc"
last-modified: Mon, 29 Jan 2024 11:02:35 GMT
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block
content-length: 988

# curl -I https://jellyfin.example.com/Users/View
HTTP/2 405 
allow: DELETE, GET, POST
alt-svc: h3=":443"; ma=2592000
date: Wed, 29 May 2024 08:51:54 GMT
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=63072000; includeSubDomains; preload
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-response-time-ms: 7.4041
x-robots-tag: noindex, nofollow
x-xss-protection: 1; mode=block

The relevant parts of the settings.json file:

 "main": {
  "apiKey": "REDACTED",
  "applicationTitle": "Jellyseerr",
  "applicationUrl": "https://jellyseerr.example.com",
  "csrfProtection": true,
  "cacheImages": false,
  "defaultPermissions": 71303200,
  "defaultQuotas": {
   "movie": {
    "quotaLimit": 0,
    "quotaDays": 7
   },
   "tv": {
    "quotaLimit": 0,
    "quotaDays": 7
   }
  },
  "hideAvailable": false,
  "localLogin": false,
  "mediaServerLogin": true,
  "newPlexLogin": true,
  "oidcLogin": true,
  "oidc": {
   "providerName": "Authelia",
   "providerUrl": "https://auth.example.com",
   "clientId": "jellyseerr",
   "clientSecret": "REDACTED",
   "userIdentifier": "preferred_username",
   "requiredClaims": "email_verified",
   "scopes": "email openid profile groups",
   "matchJellyfinUsername": true,
   "automaticLogin": false
  },
  "region": "ES",
  "originalLanguage": "",
  "trustProxy": true,
  "mediaServerType": 2,
  "partialRequestsEnabled": true,
  "locale": "es"
 },
 "jellyfin": {
  "name": "",
  "hostname": "http://jellyfin:8096",
  "externalHostname": "https://jellyfin.example.com",
  "jellyfinForgotPasswordUrl": "https://auth.example.com/reset-password/step1",
  "libraries": [
   {
    "id": "ed2a25286c558a96e1424971742ca350",
    "name": "Movies",
    "enabled": true,
    "type": "movie"
   },
   {
    "id": "5ddaa59a73205234890fdcfc683e14ef",
    "name": "Shows",
    "enabled": true,
    "type": "show"
   }
  ],
  "serverId": "a0c6a6aff1ce4463c0a2eda775a310f9"
 },

In addition to that, I had to grant myself owner permissions by editing the database manually:

# sqlite3 /var/lib/containers/storage/volumes/jellyseerr/_data/db/db.sqlite3

sqlite> select id, email, username, permissions from user;
sqlite> update user set permissions = 3 where id = 1;
sqlite> .exit

@jorti
Copy link

jorti commented May 29, 2024

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 /Users/JELLYFIN_USER_ID/View is incorrect.

I've discovered my user id and created an API key in Jellyfin, then added them to my user in Jellyseerr:

sqlite> select id, email, username, jellyfinUsername, jellyfinAuthToken, jellyfinUserId, jellyfinDeviceId from user;
1|[email protected]|username||||

sqlite> update user set jellyfinUsername = 'username', jellyfinUserId = 'JELLYFIN_USER_ID', jellyfinAuthToken = 'REDACTED'  where id = 1;

After that, the library scan works.

I think this Jellyfin API key setting should be a global option and not per-user.

@Fallenbagel
Copy link
Owner

Fallenbagel commented May 29, 2024

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

@github-actions github-actions bot removed the merge conflict Cannot merge due to merge conflicts label May 29, 2024
@michaelhthomas
Copy link
Author

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.

@Fallenbagel
Copy link
Owner

Fallenbagel commented May 29, 2024

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)

@Sapd
Copy link

Sapd commented May 31, 2024

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:

SQLITE_CONSTRAINT: UNIQUE constraint failed: user.email"

Changing his email to lower case in Authentik fixes it.

@Scot-Survivor
Copy link

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:

SQLITE_CONSTRAINT: UNIQUE constraint failed: user.email"

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.

@maarten-vdb
Copy link

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?

@kartik2406
Copy link

This works perfectly for me using Authentik and Plex including automatic login. I started from scratch and do not have any advanced config settings in NPM.

Jellyseerr: Issuer URL: https://auth.example.com/application/o/applicationname

Authentik Provider: Redirect URI: https://jellyseerr.example.com/login/oidc/callback

image

This works perfectly for me using Authentik and Plex including automatic login. I started from scratch and do not have any advanced config settings in NPM.

Jellyseerr: Issuer URL: https://auth.example.com/application/o/applicationname

Authentik Provider: Redirect URI: https://jellyseerr.example.com/login/oidc/callback

image

Thank you!
This worked for me :D

@Doug411
Copy link

Doug411 commented Jun 11, 2024

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

@github-actions github-actions bot added the merge conflict Cannot merge due to merge conflicts label Jun 12, 2024
Copy link

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

@Alumni1506
Copy link

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

nebb00 commented Jun 24, 2024

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

@gauthier-th gauthier-th mentioned this pull request Aug 12, 2024
14 tasks
sudopseudocode added a commit to sudopseudocode/jellyseerr that referenced this pull request Sep 8, 2024
sudopseudocode added a commit to sudopseudocode/jellyseerr that referenced this pull request Sep 9, 2024
changes to fix build after merging with latest develop

re Fallenbagel#184
@TheRedCyclops
Copy link

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

mikevanes commented Sep 13, 2024

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

lucaam commented Sep 13, 2024

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

Ruakij commented Sep 13, 2024

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

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

Fallenbagel commented Sep 13, 2024

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

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

@pando85
Copy link

pando85 commented Nov 1, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merge conflict Cannot merge due to merge conflicts preview PRs deployed for testing with tag `:preview-prxx`
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Feature Request] Support login with OIDC [Feature request] SSO