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-bit]

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:

[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

[pimonteiro]

Anyone has made this work on kubernetes?

[lareeth]

@pimonteiro Can you clarify what you mean?

This container runs on both docker (directly run or compose) and kubernetes (official chart and 3rd party)

if you are trying to update your kubernetes templates (or helm chart) you will need to update the image reference to use docker.io/fallenbagel/jellyseerr:preview-OIDC

Can you confirm how you are running in kubernetes? Are you using the official seerr chart?`

The official chart can be updated by setting the following values

image:
  registry: docker.io
  repository: fallenbagel/jellyseerr
  tag: preview-OIDC

[pezfisk]

I've installed seerr with the ProxmoxVE Helper Script, how can I enable the OpenID Connect feature? I can only find how to enable it with the docker container.

[Metzlmane]

look at the source code which is getting installed and updated, you probably have to change the defined repository
https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/install/seerr-install.sh

[liamk024]

Are there any plans yet for which version of seerr this will be fully implemented in yet?

[platnub]

#2715

[stargazze]

Hello
I'm trying fallenbagel/jellyseerr:preview-OIDC out but I get "An error occurred while logging in with authelia." after logging an redirection. However I don't see anything in the jellyseerr logs in debug mode. Any idea why?

Authelia config:

      - client_id: 'seerr'
        client_name: 'Seerr'
        client_secret: '***'
        public: false
        authorization_policy: 'one_factor'
        require_pkce: false
        pkce_challenge_method: ''
        redirect_uris:
          - 'https://seerr.***.***/login?provider=authelia&callback=true'
          - 'https://jellyseerr.***.***/login?provider=authelia&callback=true'
        scopes:
          - 'openid'
          - 'email'
          - 'profile'
          - 'groups'
        response_types:
          - 'code'
        grant_types:
          - 'authorization_code'
        access_token_signed_response_alg: 'none'
        userinfo_signed_response_alg: 'none'
        token_endpoint_auth_method: 'client_secret_post'`

Jellyseerr oicd config:

oidc": {
  "providers": [
   {
    "slug": "authelia",
    "name": "authelia",
    "issuerUrl": "https://auth.***.***",
    "clientId": "seerr",
    "clientSecret": "***",
    "logo": "https://www.authelia.com/images/branding/logo-cropped.png",
    "scopes": "openid profile email groups",
    "newUserLogin": true
   }
  ]
 },

[BrenekH]

I think the scopes in Jellyseerr are supposed to be comma-separated instead of space-separated

[stargazze]

I think the scopes in Jellyseerr are supposed to be comma-separated instead of space-separated

Thanks for your answer. Jellyseerr says "Space-separated list of scopes to request from the provider". I still tried comma-separated but it failed before redirecting to authelia.

[stargazze]

Ok I got to the bottom of it: I tried to login with a user that was a jellyfin user type. OIDC manage local users so it didn't find it and try to create it. I guess an existing user with the same email made the creation fail.
I just had to link the authelia account to the existing user in admin panel to get it to work. Great!
Shouldn't the logs print something in that case?

[coolapso]

which image should we use for this right now? Seems the preview-OIDC tag is no longer available after the rename? I see a preview-new-oidc but that one seems to not have the oidc settings option. am I missing something?

[lareeth]

This is an unmerged feature, information and docs will change. Please be mindful of this.

[coolapso]

This is an unmerged feature, information and docs will change. Please be mindful of this.

I completely understand that, which makes my question even more relevant!

[GraphicHamster]

Its not really reasonable to expect other projects to have updated documentation for an experimental branch.
Also, the Authelia docs are specifically talking about the jellyseerr preview-OIDC branch. If you follow those directions, they should work, you will just be running Jellyseerr rather than Seerr.

[coolapso]

I don't think its authelia that maintains those docs. either way ... I got it working with authelia just fine! Thank you for the pointers!

[aslafy-z]

You can build your own with:

git clone https://github.com/michaelhthomas/seerr -b feat/oidc-login-basic
docker build -t zadki3l/seerr:preview-oidc-3fcf9f4 -b COMMIT_TAG=local seerr

I pushed docker.io/zadki3l/seerr:preview-oidc-3fcf9f4 which is aligned to the tip of the branch of PR #2715.

[GraphicHamster]

Tested and working with Zitadel.

[nebb00]

When this comes please include role_claims

[schmensch]

Hi, I'm trying to use the preview-new-oidc image, but when deploy it and try to sign in, I get an 401: unauthorized error with the following message:
{"message":"cookie 'connect.sid' required","errors":[{"path":"/api/v1/auth/me","message":"cookie 'connect.sid' required"}]}
The connect.sid cookie exists.
This happens with all methods of logging in (local, jellyfin sign in, OIDC sign in, ...).

If I switch to the regular image after a failed login and refresh the site, I'm logged in. This is reproducable with all methods of sign in:

• Try to sign in while using the preview-new-oidc image, login fails (401 in the browser, redirected back to the login page)
• Restart the server to use the latest image
• Refresh the site, I am logged in (no matter what login method I used).

It appears that login is working and the server is aware of my session, but somehow can't serve the correct pages.

Edit: I tried reproducing this issue on a brand new install (in the case that switching between the images somehow messes up the server), but the set up process can't be completed with the preview-new-oidc image as I can't create the owner user.

Edit 2: The develop image does not have this issue, it behaves the same as the latest image. This is specific to some change in the preview-new-oidc image.

[psudeoing]

I am having the same issue. Everything including the SSO callback request succeeds and it loads the home page's skeleton, but then kicks me back out to the login page instantly.

I have not changed my configuration since the last iteration of preview-new-oidc, which worked fine.

[koek-blik]

Also having this issue. I managed to temporarily fix it by using the following image/digest which is the previous preview-new-oidc: ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6

[psudeoing]

Thanks, was looking for a way to do this.

[lex87-star]

is the feature already in the latest build 3.2.0 included?

[psudeoing]

No.

[Kariton]

Is it planned to configure oidc via environment variables?

this would simplify dry configuration in code and would make it possible to manage or even rotate client secret via operators like
aclerici38/pocket-id-operator or pando85/kaniop

[michaelhthomas]

No, but I imagine you could achieve something similar by editing the configuration JSON file. All of the provider settings are stored there.

[aslafy-z]

I feel like this should be addressed at the whole project scope. Only the DB and API key can be configured using environment variables as of today.

[mi7chal]

What's the current status? Is image preview-new-oidc working fine?

[aslafy-z]

I'm using zadki3l/seerr:michaelhthomas-oidc-0bfd615 which is built from commit 0bfd615, it works fine.

Build your own with

cd $(mktemp -d)
git clone https://github.com/michaelhthomas/seerr -b feat/oidc-login-basic
docker build -t seerr:michaelhthomas-oidc --build-arg COMMIT_TAG=local seerr

[gauthier-th]

Closing this discussion in favor of the new one: #2721