OpenID Connect Support/Testing

[michaelhthomas]

Please use this thread as a place to discuss testing / questions related to the work-in-progress OpenID Connect feature. This will allow the PR comments to be used for code review instead of general discussion.

[v3DJG6GL]

@voc0der

As someone who is clinging on to the old preview-OIDC from the last PR, can anyone chime in on if the upgrade process is relatively straightforward? I really appreciate the work and want to jump back to the branch with the new stuff.

I just made the upgrade from the old preview-OIDC to the latest PR: Firtst, I had these logs:

2025-03-26T13:44:29.760Z [debug][Settings Migrator]: Checking migration '0001_migrate_hostname.js'... 
2025-03-26T13:44:29.763Z [debug][Settings Migrator]: Migration '0001_migrate_hostname.js' has been applied. 
2025-03-26T13:44:29.763Z [debug][Settings Migrator]: Checking migration '0002_migrate_apitokens.js'... 
2025-03-26T13:44:29.820Z [error][Jellyfin API]: Something went wrong while creating an API key from the Jellyfin server {"error":"Unauthorized"}
2025-03-26T13:44:29.820Z [error][Settings Migrator]: Error while running migration '0002_migrate_apitokens.js': Failed to create Jellyfin API token from admin account. Please check your network configuration or edit your settings.json by adding an 'apiKey' field inside of the 'jellyfin' section to fix this issue. 
2025-03-26T13:44:29.820Z [error][Settings Migrator]: A common cause for this error is a permission issue with your configuration folder, a network issue or a corrupted database.

I had to manually adjust settings.json file and add an apiKey inside of the jellyfin settings. After that, Jellyserr started without issues.

But I am affected by the issue already mentioned in the PR: #1505 (comment)
All my Jellyseerr users are local users and were created with the old OIDC PR.
Thus, they have no linked accounts. When they try to log in, Jellyseerr tries to create a new local user even though one already exists. And since an account with the same email account already exists, the login fails. Maybe I need to find a way to manually edit the sqlite3 database and add the linked accounts manually, but I haven't found the time yet....

[michaelhthomas]

The sid is a unique user identifier from the IDP (Authelia). I'm not too familiar with Authelia specifically, but this looks like it may be helpful: https://www.authelia.com/reference/cli/authelia/authelia_storage_user_identifiers/

[v3DJG6GL]

The sid is a unique user identifier from the IDP (Authelia). I'm not too familiar with Authelia specifically, but this looks like it may be helpful: https://www.authelia.com/reference/cli/authelia/authelia_storage_user_identifiers/

oh thanks a lot, that was the information I needed :D
for reference: this is the SQL query I used to find the identifiers in the Authelia database:

SELECT * FROM public.user_opaque_identifier
ORDER BY username ASC

after manually adding these identifiers to the sub column in the linked_accounts table, all accounts are correctly linked :D

[bzly]

The previous commit the preview-OIDC tag pointed to had the option to use the email field as an identifier (and optionally require the email be verified)—is this feature not planned for the updated implementation?

I have local users imported into Jellyseerr from Plex, but haven't rolled out Authentik yet. This means I cannot bulk/pre-modify their users with their Authentik user identifier (because they don't have one). Without using email as an identifier, each user would have to login as they do currently and link an Authentik account, or I will have to do it for them in some manner one-at-a-time, and it would leave my Jellyseerr in a weird state where I have to have OIDC and another login type active at the same time until all linking is complete. I could also delete all their users, of course, which would be the simplest solution for me but not particularly elegant.

This process of switching to OIDC login when one already has local accounts seems cumbersome without using email as an identifier; am I missing something simple (entirely possible) or has this state not been considered?

[fallenbagel]

This process of switching to OIDC login when one already has local accounts seems cumbersome without using email as an identifier; am I missing something simple (entirely possible) or has this state not been considered?

The pr is not completed yet. It's in draft mode. In the description, it says todos: automatic linking. Please be patient. It's unfinished.

[bzly]

This process of switching to OIDC login when one already has local accounts seems cumbersome without using email as an identifier; am I missing something simple (entirely possible) or has this state not been considered?

The pr is not completed yet. It's in draft mode. In the description, it says todos: automatic linking. Please be patient. It's unfinished.

So it turns out I was missing something simple: the ability to read. I wasn't meaning to be impatient! Thanks.

[smdion]

Hello,

I did the manual database addition for linked_accounts as found here - #183 (comment) . I am now seeing this fatal error on start. It worked for about 8-10 hours overnight before this error. I did manually link a few local users to the OIDC provider as well.

I have attempted to restore from backup and allow it to handle the migration manually, but it appears it did not attempt the same migration.

> jellyseerr@0.1.0 start /app
> NODE_ENV=production node dist/index.js

2025-03-26T16:06:20.636Z [info]: Commit Tag: d6e8c93af63807d6c910e1318ab4c39abe0f92f3 
2025-03-26T16:06:21.096Z [info]: Starting Jellyseerr version develop-d6e8c93af63807d6c910e1318ab4c39abe0f92f3 
Migration "AddLinkedAccounts1742858484395" failed, error: SQLITE_ERROR: table "linked_accounts" already exists
2025-03-26T16:06:21.600Z [error]: QueryFailedError: SQLITE_ERROR: table "linked_accounts" already exists
    at handler (/app/node_modules/.pnpm/typeorm@0.3.11_pg@8.11.0_sqlite3@5.1.7_ts-node@10.9.1_@swc+core@1.6.5_@swc+helpers@0.5.11__@t_vaey37rslj53tdrdcvr4valjua/node_modu
les/typeorm/driver/sqlite/SqliteQueryRunner.js:81:26)
    at replacement (/app/node_modules/.pnpm/sqlite3@5.1.7/node_modules/sqlite3/lib/trace.js:25:27)
    at Statement.errBack (/app/node_modules/.pnpm/sqlite3@5.1.7/node_modules/sqlite3/lib/sqlite3.js:15:21) 
 ELIFECYCLE  Command failed with exit code 1.

[michaelhthomas]

Looks like it's trying to run the migration, not knowing that the database has already been updated. Best thing would probably be to drop the table and then let the migration add it back.

[smdion]

Looks like it's trying to run the migration, not knowing that the database has already been updated. Best thing would probably be to drop the table and then let the migration add it back.

That worked, but it lost the manually linked accounts that I had (which makes sense as the table was dropped). I assume I'm safe to manually link the accounts back to OIDC now that the mitigation is there? I assume the issue is because I linked accounts before the mitigation was present. Thanks for all your work on OIDC, very excited to have this in the main branch.

[v3DJG6GL]

An issue I am facing: I cannot hide the Jellyfin login form:

Although jellyfin/jellyseerr login methods are disabled:

Here the related settings.json configuration:

{
 "clientId": "<REDACTED>",
 "vapidPrivate": "<REDACTED>",
 "vapidPublic": "<REDACTED>",
 "main": {
  "apiKey": "<REDACTED>",
  "applicationTitle": "Jellyseerr",
  "applicationUrl": "",
  "cacheImages": false,
  "defaultPermissions": 216031392,
  "defaultQuotas": {
   "movie": {
    "quotaLimit": 0,
    "quotaDays": 7
   },
   "tv": {
    "quotaLimit": 0,
    "quotaDays": 7
   }
  },
  "hideAvailable": false,
  "localLogin": false,
  "mediaServerLogin": false,
  "oidcLogin": true,
  "newPlexLogin": false,
  "oidc": {
   "providerName": "Authelia",
   "providerUrl": "https://auth.DOMAIN.TLD",
   "clientId": "jellyseerr.DOMAIN.TLD",
   "clientSecret": "<REDACTED>",
   "userIdentifier": "email",
   "requiredClaims": "email_verified",
   "scopes": "openid profile email groups",
   "matchJellyfinUsername": true,
   "automaticLogin": false
  },
  "discoverRegion": "",
  "streamingRegion": "US",
  "originalLanguage": "",
  "mediaServerType": 2,
  "partialRequestsEnabled": true,
  "enableSpecialEpisodes": false,
  "locale": "en",
  "oidcName": "Authelia",
  "oidcClientId": "jellyseerr.DOMAIN.TLD",
  "oidcClientSecret": "<REDACTED>",
  "oidcDomain": "https://auth.DOMAIN.TLD",
  "oidcMatchUsername": true
 },
 "oidc": {
  "providers": [
   {
    "slug": "Authelia",
    "name": "Authelia",
    "issuerUrl": "https://auth.DOMAIN.TLD",
    "clientId": "jellyseerr.DOMAIN.TLD",
    "clientSecret": "<REDACTED>",
    "logo": "https://auth.DOMAIN.TLD/favicon.ico",
    "requiredClaims": "",
    "scopes": "openid,profile,groups,email",
    "newUserLogin": true
   }
  ]
 },

EDIT:
I removed these configuration entries as they probably come from the old PR:

  "oidcName": "Authelia",
  "oidcClientId": "jellyseerr.DOMAIN.TLD",
  "oidcClientSecret": "<REDACTED>",
  "oidcDomain": "https://auth.DOMAIN.TLD",
  "oidcMatchUsername": true

  "oidc": {
   "providerName": "Authelia",
   "providerUrl": "https://auth.DOMAIN.TLD",
   "clientId": "jellyseerr.DOMAIN.TLD",
   "clientSecret": "<REDACTED>",
   "userIdentifier": "email",
   "requiredClaims": "email_verified",
   "scopes": "openid profile email groups",
   "matchJellyfinUsername": true,
   "automaticLogin": false
  },

Hasn't changed anything though

[michaelhthomas]

This is probably a bug, I'll look into it. Thanks for letting me know!

[alleyu2]

I am getting this error 2025-03-26T21:47:55.817Z [error]: Failed OIDC login attempt {"cause":"Unknown error","ip":"xxx","errorMessage":"Unexpected end of JSON input"}

Jellyseerr config:
"oidc": { "providers": [ { "slug": "authentik", "name": "authentik", "issuerUrl": "https://xx/application/o/jellyseerr", "clientId": "xx", "clientSecret": "xx", "logo": "https://cdn.jsdelivr.net/gh/selfhst/icons/svg/authentik.svg", "scopes": "", "newUserLogin": false }

Authentik:

[DuvelCorp]

Try to remove the redirect uri in the provider. Didnt work for me when I tried to specify something there

[alleyu2]

I have tried deleting redirect uri in provider but it still gives me the same error.

[alleyu2]

I got it working. I didn't assign scopes in authetik. My bad. This is resolved.

[eligibbs]

I have openid email profile in jellyseerr, and those scopes checked in authentik. Is this the same as you? Did it allow you to log in users without have to link accounts manually?

[DuvelCorp]

I think we might have an issue with case matching in usernames.

I impersonated one of my user in Authentik, to test how the OIDC logon behaves on him.

His jellyfin username is Kris and its in Jellyseer for years (and thus he doesn't have his email address in Jellyseer)
He enrolled in Authentik with username kris (so no capital letter)

This is what happened when I first-logged in with Authentik in Jellyseer with his account :

So the existing Kris user was ignored and Jellyseer created a new kris user

This looks abnormal to me. Case-matching in usernames shouldn't be a thing in any system as it can only be a source of problems. The root issue might be in Jellyseer itself, that allows such things at user creation and in the database. There should be a Case-insensitive UNIQUE CONSTRAINT on the username column of the user and linked account tables

[fallenbagel]

@fallenbagel Checked the code and that's what I thought. You lowercase all GET variable, and then serach on the DB with a lowercase on the column

Its like this everywhere and its the reason why it has always worked and that you never ended up with mixed case identical usernames

This approach is dangerous (I guess it was like this in your initial fork of overseer...)
Ideally the DB should control this itself with a UNIQUE NOCASE CONSTRAINT on the username to prevent the actual issues.

@michaelhthomas in server/routes/auth.ts there's nothing you do to lowercase the usernames received from the database and the one received from the OID

I see. I didn't check there either. I just based it off of logging in on my jellyseerr with "User" and "user" both worked with no issues.

[michaelhthomas]

The user name for linked accounts is just for display purposes, and usually will be the user name from the provider. So if your jellyseerr username is Bob and you log in with an account with username JohnDoe, it would show JohnDoe on the linked accounts page. There is no issue with the case of usernames, actually it is desirable to display using the actual case to match the provider behavior.

Note that neither emails nor usernames are used to match OpenID Connect accounts to jellyseerr ones. The only way (currently) that logging in with an OpenID Connect provider will not create a new account is if you have already linked your OpenID Connect account to an existing Jellyseerr user.

[DuvelCorp]

The user name for linked accounts is just for display purposes, and usually will be the user name from the provider. So if your jellyseerr username is Bob and you log in with an account with username JohnDoe, it would show JohnDoe on the linked accounts page. There is no issue with the case of usernames, actually it is desirable to display using the actual case to match the provider behavior.

Note that neither emails nor usernames are used to match OpenID Connect accounts to jellyseerr ones. The only way (currently) that logging in with an OpenID Connect provider will not create a new account is if you have already linked your OpenID Connect account to an existing Jellyseerr user.

Wait.. you dont consider the actual behavior as an issue and wont do anything to patch it?
Ending up with several users having the same username in the database is not an issue to you???

Its not supposed to create a new user in that case, because that user already exists in Jellyseer.
Usernames are the main identifier in Jellyfin and they should be preserved unique in Jellyseer.

Maybe its not an issue for you because you only have like 2-3 users on your installation.
When you have dozens, letting things like this turns inevitably into a complete mess.
That's not how OID is supposed to be handled.

Also this breaks the data model.
The idea of the linked_accounts table is to have a many-to-1 relationship with the user table. One user can have several linked accounts.
Kris and kris are the same user. And the OID first-logon should check this and not create the user if it already exists in the user table.
If you let things like this, it ends up in 1-to-1 relationship with duplicated users and links, or even worst, in a many-to-many relationship. And thats where user management goes totally out of control.

[michaelhthomas]

The only unique identifier in Jellyseerr is the user email (for better or worse). The username field in the database is just the user's display name, which in most cases is just their literal name. There is a separate column for linked jellyfin usernames, which do actually have to be unique.

Also, as I mentioned previously, the username field in the linked_accounts database has nothing to do with the Jellyseerr user's username, it is just used when displaying linked OpenID Connect accounts on the linked accounts page. There is no need for these usernames to be unique, as they are not used for identification at all. The sid field, which is an actual unique identifier, is the primary key and has to be unique. This is the correct way to implement OpenID Connect, as outlined in the specification. It is explicitly discouraged to use emails or usernames for identification, as there is no expectation that they are unique or secure identifiers for a user.

Now, as it relates to the general concern of not creating new users where there is already an existing user that should be linked, I agree that the current implementation is sub-optimal. If you're worried about users accidentally creating duplicate accounts, for now the best approach would be to just disable the "New user log in" setting, so that anyone logging in with an account that is not already linked will fail. In the future, I plan to implement support for linking an unseen OpenID Connect account to your existing Jellyseerr account when logging in for the first time, which would make this a more pleasant experience while remaining compliant with the security guidance from the OpenID Connect specification.

[DuvelCorp]

There's nothing forced Unique in the user table except the email.
Jellyfin fields included.

And this is plain wrong but its a legacy from Overseer and we should deal with it.

And the only reason why things works and that there can't be any duplicate in the user table until now, is that the code querying the database is full of SQL expressions like this
lowercase(username DB column) = lowercase(username to search) or lowercase(jellyfinusername DB column) = lowercase(username to search)
ie, code-controlled uniqueness instead of database-controlled uniqueness.
As I have shown in my previous answer

But now with OID there's a situation where code-controlled uniqueness will be broken, and its a flaw that will inevitably lead to issues, because it was until now a situation totally impossible, and thus unhandled in other existing parts of the code.

Also, as I mentioned previously, the username field in the linked_accounts database has nothing to do with the Jellyseerr user's username

The flaw isnt in the linked_account table., its in the user table, which potentially affects other things than just the new OID feature

[v3DJG6GL]

One strange behavior I've observed:
When I rename an existing OIDC configuration, the existing configuration is duplicated and not just renamed. I don't know if this is the intended behavior, but I at least expected that the configuration is not duplicated, but only renamed...

[michaelhthomas]

Hmm, I'm guessing that the slug field is being updated when you change the provider name? That's definitely a bug.

[v3DJG6GL]

Yes, here the related configuration when editing the provider name:

 "oidc": {
  "providers": [
   {
    "slug": "authelia",
    "name": "Authelia",
    "issuerUrl": "https://auth.DOMAIN.TLD",
    "clientId": "jellyseerr.DOMAIN.TLD",
    "clientSecret": "<REDACTED>",
    "logo": "https://auth.DOMAIN.TLD/favicon.ico",
    "requiredClaims": "",
    "scopes": "openid,profile,groups,email",
    "newUserLogin": true
   },
   {
    "slug": "authelia-test",
    "name": "Authelia-TEST",
    "issuerUrl": "https://auth.DOMAIN.TLD",
    "clientId": "jellyseerr.DOMAIN.TLD",
    "clientSecret": "<REDACTED>",
    "logo": "https://auth.DOMAIN.TLD/favicon.ico",
    "requiredClaims": "",
    "scopes": "openid,profile,groups,email",
    "newUserLogin": true
   }
  ]

[dominicrico]

@michaelhthomas opened a PR in your repo which fixes the slug renaming. This should also fix this Bug as well, as the slug will be the same all the time.

[dominicrico]

@michaelhthomas I hope you are fine with some helping hands? I would love to fix some small things and get this one over the line.

[v3DJG6GL]

I'd like to add a group claim here:

Only users that are in the jellyfin_users group should be allowed to login. But entering the group name alone doesn't work.
Shouldn't I first specify the Role Claim groups and then specify which group roles are required jellyfin_users ?

[jacknbeans]

I actually just added a PR for this! See here for details. It's probably not very well implemented and will need some good code reviewing before it will be accepted.

[tannerln7]

It's working great for me with Auth0 and Pomerium. I just wanted to ask if it would be possible to add an option to disable the manual login form in order to force users to use the OIDC login?

[dominicrico]

I included in my PR an automatic redirect to the OIDC Provider if there is only one registered and no other login option is enabled.

[FirbyKirby]

Out of curiosity, have the migrations been merged into this PR?

Through my own laziness, I accidentally "upgraded" to this PR since I had set my production docker to run on the preview-OIDC tag a few years ago when it was set to the old #184 PR. It was just working so well for me and my users with Authentik OIDC. So, I accidentally upgraded and believe I see the same effect as others on this thread in the fact that users can't log in via Authentik due to the error Failed OIDC login attempt {"cause":"Unknown error","ip":"xxx.xxx.xxx.xxx","errorMessage":"SQLITE_CONSTRAINT: UNIQUE constraint failed: user.email"} in the logs.

I was ultimately able to get myself back into Jellyseer as an owner through a local login and then linking my Authentik account to my Jellyfin account in Jellyseer, but all my other users are local users as they all created their accounts and logged in via Authentik OIDC on PR #184 only (never used the jellyfin loging method.)

I haven't found a way to perform the same account linking for them as owner. I'm hoping that I just need to run the migration, but that's beyond my capability at this time. I tried using the docker containers command line and accessing the SQLite database, so I could manually either drop the linked account table and then add the table via the method @michaelhthomas proposed here. But the docker doesn't seem to have the sqlite3 command.

Anyway, I definitely got myself into this mess, but I'm looking forward to this PR enough to learn how to fix it.

[bzly]

The code to create the linked_accounts table for existing databases is in this PR now, and not the issue you (we) are facing - see this discussion.

[fallenbagel]

But the docker doesn't seem to have the sqlite3 command.

If you have your config mounted you can just edit the db on host (which should be how you should be doing it in the first place. Never edit sqlite db's when the app is running)

[FirbyKirby]

@bzly thanks for the catch. Your absolutely right. We're in the same boat.

@fallenbagel thanks for the excellent advice. I should have known better. Much appreciated for the education. Now, I'm off to break things properly.

[lilian276]

I try to make it works again but I've got different error than I've seen here. I'm not programmer but hope that can help you. After crossing some information I got in this thread:

Using Authentik based an previous verion of preview-oidc + slug name added in url https://jellyseerr.DOMAIN.TLD/login/oidc/callback/authentik

For jellyseerr:

    "name": "Authentik",
    "logo": "https://auth.DOMAIN.TLD/favicon.ico",
    "issuerUrl": "https://auth.DOMAIN.TLD/application/o/jellyseerr/",
    "clientId": "<Client ID>",
    "clientSecret": "<Client Secret>",
    "slug": "Authentik",
    "scopes": "openid,profile,email",
    "requiredClaims": "jellyfin_users", 

Jellyseerr logs:

Failed OIDC login attempt {"cause":"Invalid jwt or missing claims","ip":"84.14.241.3","idToken":"<Long ID Token>","errorMessage":"jellyfin_users is a required field"}

[jacknbeans]

Is jellyfin_users a User Claim that you grant your users to have access to Jellyseer? If you are instead using Role Based Access Control (RBAC), then the jellyfin_users role won't be accessible via the current state of the preview-OIDC tag. You can check this PR that I opened as it adds the necessary fields to make this work, specifically the Role Claim and User Roles. However, I don't use Authentik, and tested my changes with Authelia, so take all this with a grain of salt.

[lilian276]

I'll try that and do as my best to find a way. As a dumb, I put that in prod. Thanks to salt my karma, it has better taste 🤣

[lilian276]

jellyfin_users is a User Claim (user group), I don't use RBAC at all.
I've check PR but it miss Role Claim and User Roles fields.

[lilian276]

For Authentik this config works. I've create a new jellyseerr container from zero put same config in OIDC and it works @jacknbeans

What happened with previous container:
I've removed jellyfin_users and I've got this error.
I don't have many user so I prefer restart.

[nebb00]

Is jellyfin_users a User Claim that you grant your users to have access to Jellyseer? If you are instead using Role Based Access Control (RBAC), then the jellyfin_users role won't be accessible via the current state of the preview-OIDC tag. You can check this PR that I opened as it adds the necessary fields to make this work, specifically the Role Claim and User Roles. However, I don't use Authentik, and tested my changes with Authelia, so take all this with a grain of salt.

I need this PR

[hax4dazy]

Just wanted to say that it worked flawlessly! Had to first figure out how I can use the docker container on another "version" but after that it was smooth sailing. Thanks for making this!

[caplam]

Hi,
A simple comment to thanks the dev. I installed it last week. I was using overseer and needed an oidc login. I didn't try to use my overseer db so it's a fresh install.
My sso provider is authentik.
I first imported myself (server owner) as plex user. Then others users have been created by connecting through authentik.
My account is linked to plex and authentik and other users are linked to authentik.

[keesfluitman]

I think it auto updated my preview-OIDC. I used the old. But I forgot my original admin account password. It doesnt show an authentik login button anymore and it doesnt auto login either.
Any way I can CLI a user and password? Or some other way?

I was able to solve the first problem. Setting up a new jellyseerr container and copying it's settings.json to my old container.
Now, I'd need to link all my local user accounts to their authentik accounts. Ill just delete them and impersonate them and relogin. But what was the other solution? Cause I kept getting constraint on email. So it wasnt linking them automatically?

[smdion]

Are their plans to allow automatic login again for OIDC as there was in the old previewOIDC?

[Cookie-Monster-Coder]

Are their plans to allow automatic login again for OIDC as there was in the old previewOIDC?

It would be nice to have it natively redirect to the SSO page, like immich does.

But you can do it via Cloudflare Redirect Rules:

[sbogomolov]

Is there a Seerr preview-OIDC image? I’m using fallenbagel/jellyseerr:preview-OIDC. It works great with both Authentik and Authelia.

[sbogomolov]

This is cool… I thought it can only build from local files.

[lareeth]

The fallenbagel/jellyseerr:preview-OIDC image is based off commit 7f3979411655ef5f65ce4918fe0f8f214403f75e which is the latest from the preview-OIDC branch, you shouldnt need to build it yourself

[SandraCHC]

If I understand it correct, the current dev Branch is the working branch for seerr, and I have read, that OIDC is planed for the release of seerr. But I don't found this OIDC Settings. Is the Branch preview-OIDC noch included in the dev?

[lareeth]

The branch 'preview-OIDC' PR hasn't been merged, so it isn't on the 'develop' branch, they're most likely on focusing on the merge of the codebases first, and will work on OIDC after. They will either build their own OIDC implementation or require the PR for OIDC to be rebased and updated. You can view the status on the PR here: #1505

[gauthier-th]

OIDC is planed for the release of seerr

It is not. OIDC is not merged yet and some work is still to be done.

[daurpam]

Hi! and sorry for this :(, don't know where to ask for..

I'm actually using this branch fallenbagel/jellyseerr:preview-OIDC, and don't know how to open issue for it, after the merge between jellyseerr and overseerr.

In one of the schedule task, it seems that something isn't working well because the next message appears for hours (till I stop the container), and load cpu to a 30% of use:

[warn][Media Request]: Media already exists, marking request as APPROVED {"requestId":2617,"mediaId":8188}
[warn][Media Request]: Media became available before request was approved. Skipping approval notification {"requestId":2617,"mediaId":8188}

I suppose this probably fixed in the main branch, but how can I fixed to stop this overload of processor? Someone has an updated branch with this issue resolved?

Another question about this preview, is there a option to autoprovisioning users, that still exists in seerr platform, and avoid the users to make a link by themselves?

Perhaps someone knows who I could contact? Thank you.

[henkas]

Hey everyone :)

Just wanted to give a quick success note setting up OIDC using ZITADEL.
Decided to test the OIDC feature in (Over/Jelly) Seerr with the fallenbagel/jellyseerr:preview-OIDC tag using Docker Compose.
Based on the fact that it's not merged yet and that it's been a work-in-progress for quite a while, I was very happy to find out that it just worked at the first try. Both signing in and linking the external account to an existing user or Plex user works so far after testing for a few minutes.

For anyone looking for info, here are the settings I used in Seerr and ZITADEL:

Seerr config

• Provider Name: ZITADEL
• Logo: path to logo
• Issuer URL: https://auth.mydomain.com (or whatever is the base domaain of your ZITADEL installation => You can find it by going to https://auth.mydomain.com/.well-known/openid-configuration to find the issuer URL of your setup)
• Client ID: get it from ZITADEL
• Client Secret: also this
• Provider Slug: zitadel (or whatever you want, but you'll need it in a sec)
• Scopes: I entered 'openid email profile roles'
• Required Claims: email_verified
• Allow New Users: enabled
• After this, Save Changes in the popup and don't forget to scroll down and click Save Changes at the bottom of the page too (took me a minute to realize that's why the option didn't show in the login page :D)

ZITADEL config

• Type of application: Web
• Authentication method: Code
• Redirect URIs: https://seerr.mydomain.com/login?provider={provider_slug}&callback=true (or I guess if local setup you could probably use https://my.ipa.ddr.ess:5055/login?provider={provider_slug}&callback=true just make sure to enter the provider slug you choose before to the URL.

(Also hoping that someone else can confirm that these are the correct settings, but assuming they are since it seems to be working :D

Anyways, great work and thanks for the awesome app!

[quagsirus]

After setting OIDC as the only authentication method, there is nowhere in the UI to refresh the Plex auth token (which gets invalidated when changing Plex password for example)

[Plex Scan]: Scan interrupted {"errorMessage":"Permission denied even after attempted authentication :( Wrong username and/or password maybe?"}
---
[Plex.tv API]: Something went wrong getting the devices from plex.tv {"errorMessage":"Request failed with status code 401"}```

[Nerdtality]

Jellyseerr OIDC documentation added to VoidAuth https://voidauth.app/#/OIDC-Guides?id=-jellyseerr-experimental

[Prankish8407]

Good day,

I noticed when i request stuff on radarr via jellyseerr-OIDC all is good, but when other OIDC users request movies they dont get trought.
Its only for movies, not for series, series work fine for other users.

any idea? or is this still a limitation for OIDC version?

[caplam]

i noticed that too.
I didn't investigate much but in my case it seems related to the tag passed to radarr.
My users are not very active since a few weeks. I deleted all existing users tag in radarr. It seems to have solved the problem but i still need confirmation

[gauthier-th]

Please see #1897 and #2229 for this issue.

[Prankish8407]

@caplam Let me try that as well as I use tags as well to track requests, I'll get back to you on this.

Do I need to disable tags in jellyseerr as well?

@gauthier-th I'm using names without spaces, lastnamefirstname combined.
Example: Tony Stark would be StarkTony (fake names)

[gauthier-th]

You can disable "Tag requests" in the service settings to fix the issue for now.
@Prankish8407 there are 2 issues. One for the space in the names, one for the space in the tag given to Radarr. Disable the "Tag requests" to fix the later.

[Prankish8407]

You can disable "Tag requests" in the service settings to fix the issue for now. @Prankish8407 there are 2 issues. One for the space in the names, one for the space in the tag given to Radarr. Disable the "Tag requests" to fix the later.

Yeah that seemed to fix it, cheers for the workaround.
i dont program in typescript, so im unable to assist, but thanks for all the work you guys put in!

[liamk024]

Jellyfin's SSO Auth plugin has an option for scheme override to force requests to use https instead of http. This is a requirement for it to work correctly with my reverse proxy.

As far as I can tell there is no way to do this currently with the OIDC preview on jellyseerr. Is there any way around this right now or is it possible for a similar option to be added to jellyseerr?

[lareeth]

Are you running Seerr/Jellyseerr behind a reverse proxy? If so you need to enable proxy support so the backend looks at the forwarded proto headers and correctly identifies you are using https

[voc0der]

Any timeline on this? We have now been through two massive PRs and an app change. Huge amounts of people continue to only use this feature.

Apologize for emailing everyone but....what are we waiting for?

[lareeth]

Please see my comment above #1529 (reply in thread) but the team is working on the jellyseerr seerr merge, once there is a first release of seerr, I'm sure they will start to pickup backlog items.

[its-wizza]

I did a straight swap of tag from latest to preview-OIDC, as a result I had all media appear as "Movie Not Found" and "Series Not Found". OIDC login also didn't work. Switching back to latest restored the functionality. Any ideas why this would be or how I can track down the cause?

I oreviously had this issue after changing my local DNS server, and had to disable IPv6 to resolve. I have confirmed IPv6 was still disabled when not working in this case.

[iewl]

i want to setup OIDC too, but i get this error:

[+] up 1/1
✘ Image ghcr.io/fallenbagel/jellyseerr:preview-OIDC Error manifest unknown 0.8s
Error response from daemon: manifest unknown

im using the tag correct, right?

[voc0der]

try docker.io/fallenbagel/jellyseerr:preview-OIDC

[iewl]

Great, that worked! Thank you

[mi7chal]

Hello,
could you guys please update me on the current status of the account linking feature? I recall seeing plans for implementation of it, but it appears it is still in progress, isn't it?

[mi7chal]

In the meantime, I’ve added a custom implementation for account linking/merging. My fork automatically links OIDC with existing Seerr accounts. Additionally, if an account doesn't exist in Seerr, it checks Jellyfin/Emby/Plex, imports the user and creates an account automatically.

This isn't production-ready for the moment, but it's fully working to host it on homelab. If there is interest I can prepare production-ready version.

You can check it out or deploy from links below. In order to make this feature work you need to enable Account Linking option under your OIDC provider Advanced Settings (see image below).

My fork repo: mi7chal/jellyseerr/feat/oidc/login
Docker image: mi7chal/seerr:oidc-autolink

Account linking option:

[viretius]

Your domain is visible there. Maybe you want to delete the picture?

[mi7chal]

Thx, updated picture

[ghost]

The docker.io/fallenbagel/jellyseerr:preview-OIDC has been working great for me and my friends who use it to request items. I have personally played with the new Seerr 3.0.1, and that seems very nice, but until OIDC is added to it, I have to stay on docker.io/fallenbagel/jellyseerr:preview-OIDC. My friends aren't super technically savvy, so getting them to remember 1 account was hard enough (Authentik) to use apps I am hosting. Adding a second account and login would probably keep them from using it as much, defeating the purpose.

That said, if a similar testing build pops up for Seerr, I will gladly do legwork to help test that. Thank you for everyone working on this project!

[GlenNicholls]

You can use LDAP with Authentik configured as the LDAP provider in Jellyfin, then configure seerr to use Jellyfin for login. That’s how my instance is configured until OIDC is supported. If you want to explore that path at all, lmk and I can post my Jellyfin LDAP config as it took a bit of fiddling to get it working

[ghost]

Will that work with Emby in place of Jellyfin? If so, yes, I'm absolutely interested in giving that a try. I appreciate it!

[2o1o0]

The docker.io/fallenbagel/jellyseerr:preview-OIDC has been working great for me and my friends who use it to request items. I have personally played with the new Seerr 3.0.1, and that seems very nice, but until OIDC is added to it, I have to stay on docker.io/fallenbagel/jellyseerr:preview-OIDC. My friends aren't super technically savvy, so getting them to remember 1 account was hard enough (Authentik) to use apps I am hosting. Adding a second account and login would probably keep them from using it as much, defeating the purpose.

until OIDC is added to it, I have to stay on docker.io/fallenbagel/jellyseerr:preview-OIDC. My friends aren't super technically savvy, so getting them to remember 1 account was hard enough

Same goes here, all my integrated apps use OIDC as SSO and I don't want to use LDAP, one IdP is enough to manage. I definitely see this as a regression. Hopefully it will picked back up.

[v3DJG6GL]

I was in the same situation and began building an image based on current Seerr develop branch with additionally added OIDC functionality (from PR #1505) and QuickConnect functionality (from PR #2212) :
https://github.com/v3DJG6GL/seerr

Now my friends can not only login into Seerr with their SSO account, but also link their (passwordless) Jellyfin SSO account to their Seerr account. This in turn opens up a multitude of possibilities for integrating Seerr and Jellyfin - thanks to Jellyfin Plugins https://github.com/n00bcodr/Jellyfin-Enhanced and https://github.com/ranaldsgift/KefinTweaks:
Synchronizing Watchlists, search & requests directly from the Jellyfin WebUI and so on...

I'll continue to update this image until both OIDC and QuickConnect PRs are merged and released

ghcr.io/v3djg6gl/seerr:feat-oidc-jellyfin-quickconnect

[ghost]

That was straight forward and seems to work perfectly! Thank you very much! I'll continue to use this branch until the OIDC features are merged. Thank you again very much!

[Nerdtality]

VoidAuth guide is also available, https://voidauth.app/#/OIDC-Guides?id=-jellyseerr

fallenbagel/jellyseerr:preview-OIDC

[gthrift]

Do you follow the standard migration path instructions from jellyseer to seer?

…

On Sun, Feb 15, 2026 at 6:54 AM v3DJG6GL ***@***.***> wrote: I was in the same situation and began building an image based on current Seerr develop branch with additionally added OIDC functionality (from PR #1505 <#1505>) and QuickConnect functionality (from PR #2212 <#2212>) : https://github.com/v3DJG6GL/seerr Now my friends can not only login into Seerr with their SSO account, but also link their (passwordless) Jellyfin SSO account to their Seerr account. This in turn opens up a multitude of possibilities for integrating Seerr and Jellyfin - thanks to Jellyfin Plugins https://github.com/n00bcodr/Jellyfin-Enhanced and https://github.com/ranaldsgift/KefinTweaks: Synchronizing Watchlists, search & requests directly from the Jellyfin WebUI and so on... *I'll continue to update this image until both OIDC and QuickConnect PRs are merged and released* ghcr.io/v3djg6gl/seerr:feat-oidc-jellyfin-quickconnect — Reply to this email directly, view it on GitHub <#1529 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB6R6ADVYO3NEBGNGCFP2T4MBM53AVCNFSM6AAAAABZ2Q6TK6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBRGEZDKMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[v3DJG6GL]

Seerr is basically Jellyseerr but renamed.
So there is not really a migration needed.
I mean there are migrations included since last docker.io/fallenbagel/jellyseerr:preview-OIDC release as e. g. PR #2231
But that's not a migration from Jellyseerr - > Seerr.
Nevertheless: Backups are still important of course