New OpenID Connect Support/Testing

[gauthier-th]

Please use this thread to discuss about the new OpenID Connect implementation: #2715

Preview tag is preview-new-oidc (last update: 15/04/2026)

Caution

Please make a backup before testing this.

This feature is still experimental. Do not use it on a production instance unless you have a verified backup and a tested rollback plan.
See Backups.

Also, keep in mind that this may break an any point and may not be compatible with future version of Seerr

[cordlord]

For anyone curious, things have changed from the old preview-OIDC image, understandably so.
As far as I can tell, seerr handled all the migrations flawlessly going straight from the old to the new preview. My OIDC account was even still linked and everything. That being said, absolutely back up and run on a test folder/container first.

As of posting, I cannot log in through OIDC due to a redirect uri error. It seems like the redirect uri endpoint is different, but I'm not sure what it's supposed to be just yet and my OIDC won't pick up the correct one automatically. I also can't piece together if anything else has changed in the settings.json as far as the OIDC config goes since it's not available through the webUI just yet.

Super stoked to see progress and thanks to everyone's hard work on this feature!

[cordlord]

I can also confirm it's working with Authentik. Love to see it!

[michaelhthomas]

Perfect! Authentik works again! I had to add back the trailing slash to the issuer URL otherwise Seer would throw a discovered metadata issuer does not match the expected issuer error.

Yeah, as far as the trailing slash, it depends on the provider whether or not it's needed (it must exactly match the URL in the discovery document). When the settings UI is added it will have a "Test" button that should make it a bit easier to see if you've got it right.

[cordlord]

Not sure if anyone else has tried connecting a new OIDC account. If I remove my OIDC account, then try to re-link it, I get another URI redirect error.
Adding https://auth.domain.com/profile/settings/linked-accounts to my redirect uris along with https://auth.domain.com/login is working flawlessly for me.

Just not sure if that's intended or I'm missing something, but no big deal.

[michaelhthomas]

Not sure if anyone else has tried connecting a new OIDC account. If I remove my OIDC account, then try to re-link it, I get another URI redirect error.
Adding https://auth.domain.com/profile/settings/linked-accounts to my redirect uris along with https://auth.domain.com/login is working flawlessly for me.

Just not sure if that's intended or I'm missing something, but no big deal.

This is intended and mentioned in the documentation.

[charredchar]

Nevermind my previous issue... it's because the user I am attempting to log in with is part of my Jellyfin Admin group but not part of my Jellyfin Users group. I tested with a Jellyfin User and that works fine.
So the real issue is that how do I allow admins to use Seerr and automatically make them admins without needing to go in by hand and make them an admin? For Jellyfin that's done by a separate Admin Roles field you define.

[sgayda2]

I am curious how this would work for users that have previously been created or are using the jellyfin login option. Is there code/plan for merging accounts that had previously been created when you detect the same email/username/whatever is the same between an old account and an OIDC account that was just used

[fallenbagel]

I am curious how this would work for users that have previously been created or are using the jellyfin login option. Is there code/plan for merging accounts that had previously been created when you detect the same email/username/whatever is the same between an old account and an OIDC account that was just used

While I havent looked into the codebase or how oidc works, we already have support for exactly what youre saying if I'm not mistaken:

Where you can link your existing account to oidc. Linked Accounts feature was added as part of oidc feature. By the same PR author

[pretorien51]

still not scheduled to be integrated into the main version?
to uprade to seer i only need to target to this new branch?

[nstrelow]

Amazing, I finally switched over from Jellyseerr and everything was smooth setting up 🥳

Tiny tiny improvement I would suggest is allowing to disable the local&jellyfin sign in. I think the jellyfin oicd allowed that, great for my oidc users that only log in via that.
But that probably should be part of adding more of the config back to the UI.

Thanks a lot for the amazing work 😁 Feels great to finally be on Seerr

[edbourque0]

I tried this out with Pocket ID on a fresh Seerr install but I can't make it work.

Here is what I did :

1. Created a fresh docker install with a postgres database
2. Went through the initial Seerr setup
3. Updated the settings.json file with this :

"oidc": {
  "providers": [
   {
    "slug": "pocketid",
    "name": "Pocket ID",
    "issuerUrl": "https://auth.mydomain.com",
    "clientId": "[redacted]",
    "clientSecret": "[redacted]",
    "logo": "[redacted]",
    "newUserLogin": true
   }
  ]
 }

4. The home screen still only shows Seerr or Jellyfin authentication.

What I am missing here ?

I'm sure it's a stupid mistake...

Thank you all for your help and that you to everybody that made this feature and Seerr possible!

[Nuuki9]

That pretty much matches my config. One thing - do you see the following in your settings.json:

"oidcLogin": true,

[edbourque0]

That was it, I knew it was something stupid...
Thank you for the heads up, it works perfectly now!

[Nuuki9]

Glad it worked out - troubleshooting OIDC can often get a bit tricky so easy to miss the more obvious things :-)

[nebb00]

Do you guys support role_claims now?

[roib20]

The preview-new-oidc tag currently does not include the security patch introduced in Release v3.1.1:

🛡️ Security

• Patch CVE-2026-40175 - Unrestricted Cloud Metadata Exfiltration via Header Injection Chain - (3ca6422)

I would appreciate it if the tag can be updated; at the same time I also understand this is a preview tag that's not meant for production usage.

[michaelhthomas]

Good point, I'll rebase the branch so hopefully we can get an updated preview image out.

[gauthier-th]

Don't hesitate to ping me (here or on Discord) if you want me to update the preview.

[roib20]

Thanks for updating the tag: preview-new-oidc

[Jycreyn]

Migrated from Jellyseerr (preview-OIDC tag) to Seerr (preview-new-oidc) today and everything works great.

For the OIDC setup with Authentik, the new redirect URI is much simpler — just https://yourapp.domain/login instead of the old https://yourapp.domain/login?provider=authentik&callback=true. Way cleaner and properly follows the OIDC standard.

Migration was straightforward: copied the appdata, fixed permissions (chown 1000:1000), and the automatic settings migration ran without issues on first start.

Thanks for the great work on this!

[scottfridwin]

Running into an issue trying to configure from scratch with the preview-new-oidc image. Same exact docker compose works with the seerr:v3.2.0 image.

Right off the bat after selecting and trying to login with Jellyfin I see errors. The email, username, password are all correct and work on the stable image.
"Something went wrong while trying to sign in."
"Validation failed. Please toggle the libraries again to continue."

Curiously when I look at the browser console I can see a difference between the responses to the api call for authorization (https://seerr.mydomain.com/api/v1/auth/me). Might be related.
On the preview-new-oidc deployment I get a 401 whereas on the seerr:v3.2.0 deployment I get a 403.

[NachoPicchu]

I can't login at all with the latest preview-new-oidc image. Not local, not Jellyfin, not OIDC. I get no error message from the UI at all. I got "Something went wrong while trying to sign in." when I tried to log in with my local admin user that didn't have a password. Reverted to the old image, set a password for the local user and set up the new image again. Then it's the same as for all the other login providers: no error message and the page refreshes.
I'm also seeing the 401 in the Browser console.

When I use a Jellyfin account for login the container logs just say:
jellyseerr | 2026-04-17T10:00:07.858Z [info][API]: Found matching Jellyfin user; updating user with Jellyfin {"ip":"123.123.123.123","jellyfinUsername":"NachoPicchu"}

The other login methods produce no container logs.

[Krayon0]

Encountering a similar thing, the preview-new-oidc tag was working fine for me before but not anymore.
Authentik auth seems to work fine, redirects back and everything but won't go past the login screen.

/api/v1/auth/me returns 401 - the Cookie includes connect.sid in the request header so a weird error.

{
    "message": "cookie 'connect.sid' required",
    "errors": [
        {
            "path": "/api/v1/auth/me",
            "message": "cookie 'connect.sid' required"
        }
    ]
}

[cordlord]

I can't login at all with the latest preview-new-oidc image. Not local, not Jellyfin, not OIDC. I get no error message from the UI at all. I got "Something went wrong while trying to sign in." when I tried to log in with my local admin user that didn't have a password. Reverted to the old image, set a password for the local user and set up the new image again. Then it's the same as for all the other login providers: no error message and the page refreshes. I'm also seeing the 401 in the Browser console.

When I use a Jellyfin account for login the container logs just say: jellyseerr | 2026-04-17T10:00:07.858Z [info][API]: Found matching Jellyfin user; updating user with Jellyfin {"ip":"123.123.123.123","jellyfinUsername":"NachoPicchu"}

The other login methods produce no container logs.

So, I'm seeing this too, but existing sessions all still work and let me in fine. So it's something specifically when logging in fresh that got borked.

I also am not getting any useful logs other than what you shared.

I guess for now I'll just have to run latest tag and drop OIDC temporarily since I no longer have the old image. Thankfully it started right up without issue when I switched back.

[homelabdude]

Encountering a similar thing, the preview-new-oidc tag was working fine for me before but not anymore. Authentik auth seems to work fine, redirects back and everything but won't go past the login screen.

/api/v1/auth/me returns 401 - the Cookie includes connect.sid in the request header so a weird error.

{
    "message": "cookie 'connect.sid' required",
    "errors": [
        {
            "path": "/api/v1/auth/me",
            "message": "cookie 'connect.sid' required"
        }
    ]
}

Moved from jellyseerr:preview-OIDC to preview-new-oidc and I am encountering the same issue. I thought it was a reverse proxy problem - I run 2 instances one behind NPM and the other behind SWAG and both have the same issue.

[v3DJG6GL]

FYI:
I am still building an image based on the previous OIDC PR #1505 (+ #2212) and seerr:develop branch (with latest security commits):
https://github.com/v3DJG6GL/seerr/pkgs/container/seerr

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

as its based on dev branch and containing non-released features: don't forget to make backups ofc ;)

[roofuskit]

Seems like Jellyfin logins don't work at all on this preview build.

Edit: scratch that, cannot login at all when using this build. Created a fresh install with "latest", logged in with jellyfin, created local users after login. Switched builds to this new preview, unable to login at all with either account type, jellyfin or local. I could not properly setup Seer using this build from scratch as the login to jellyfin would fail every time.

[cordlord]

It was working until the last update they did to it. Waiting for a fix.

[Jycreyn]

Same here, can't login anymore :/

[logdan]

Yep, same, have not been able to login since upgrading, even with a Jellyfin user account non-OIDC. Tried to lightly poke around to see if there were any obvious database flags.

Errors are:

OIDC

seerr  | 2026-04-19T15:37:08.783Z [warn]: Failed OIDC account linking attempt {"cause":"Account is already linked to a different user","ip":"::f
fff:172.28.10.3","provider":"authentik","currentUserId":1,"linkedUserId":2}

And:

Jellyfin

seerr  | 2026-04-19T15:37:11.326Z [info][API]: Found matching Jellyfin user; updating user with Jellyfin {"ip":"::ffff:172.28.10.3","jellyfinUse
rname":"user1"}

which prints, but then login spins infinitely.

[Jycreyn]

#2715 (comment)

[Kernald]

The problem is that it's just noise. The people actually working on that PR have a lot more context and can get the exact same thing from an LLM even faster than you did. If you want to actually help, implement your changes, test them and open a PR against that branch.

[hax4dazy]

It's a potential fix

So you don't even know if it works? Did you even try to compile your fix into seer and try it?

[Jycreyn]

Check out my comment and explanation in the PR before you get all condescending. I've tested it myself, and it works in two environments.

My comment was meant to gather information, to see if it works well for others too.

[Jycreyn]

Just because it was created or written by an LLM doesn't mean it's bad, though. My comment was certainly written by an LLM, but it wasn't thought up by it. The fix isn't that complicated—just look at the changes between the last commit and the one before it....

[Taegost]

In an effort to provide an actual helpful response: @Jycreyn I made the changes you suggested to the index.ts for my instance, I can see that change inside the container, but I still get the 401 error that others are experiencing as well

[lex87-star]

migrated from jellyseerr.
I got logged in for a few seconds then kicked out and just see the login screen again.
But i can't see any error neiter in webinterface nor in docker logs.

[Taegost]

That's the same thing I'm seeing. If you look in the browser console, it's probably showing a 401 error when it does that.
It does seem to be creating the cookie for the session though, as soon as I switch to the :latest tag, it goes right in without having to log in again.

[lex87-star]

That's the same thing I'm seeing. If you look in the browser console, it's probably showing a 401 error when it does that. It does seem to be creating the cookie for the session though, as soon as I switch to the :latest tag, it goes right in without having to log in again.

It even worked with oidc Authentication?

[cordlord]

That's the same thing I'm seeing. If you look in the browser console, it's probably showing a 401 error when it does that. It does seem to be creating the cookie for the session though, as soon as I switch to the :latest tag, it goes right in without having to log in again.

It even worked with oidc Authentication?

No, OIDC is not implemented in :latest. Best guess is they had a valid sign in session/token that let them in that is independent of auth provider.

[Taegost]

That's the same thing I'm seeing. If you look in the browser console, it's probably showing a 401 error when it does that. It does seem to be creating the cookie for the session though, as soon as I switch to the :latest tag, it goes right in without having to log in again.

It even worked with oidc Authentication?

I'm sorry I wasn't very clear: No, OIDC Authentication doesn't work in the :latest branch. I had to switch to it just to get regular login working again.

[koek-blik]

For anyone having issues with the latest version of preview-new-oidc and getting kicked back to the login screen, use the following digest: ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6
This is the previous version of preview-new-oidc

[Foxite]

Thanks, I was having trouble finding the old version SHA.

[Taegost]

I appreciate the information, it finally works!

[theronypony]

Working, thank you!

[SKProCH]

Trying to setup this with authentik. Can't login with error: You do not have permission to sign in with auth.myauthentik.url No errors or messages in the container logs. Tried both preview-new-oidc and ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6 tags.

After successful login in authentik I see 403 in dev tools for https://jellyseerr.my.url/api/v1/auth/oidc/callback/authentik with

{"callbackUrl":"https://jellyseerr.my.url/login?code=5b8cc27781f04dc489ecaa61ccc334e3&state=Et47AM1FOz6YmhfHqsQnjWFyXMWunIst_XnjyvLfH1k"}

{error: "UNAUTHORIZED"}

And after that 401 to https://jellyseerr.my.url/api/v1/auth/me

cookie 'connect.sid' required

config.json:

 "oidc": {
  "providers": [
   {
    "slug": "authentik",
    "name": "auth.myauthentik.url",
    "issuerUrl": "https://auth.myauthentik.url/application/o/media-seer/",
    "clientId": "...",
    "clientSecret": "...",
    "newUserLogin": true
   }
  ]
 },

Did I do something wrong? How I can debug this?

[SKProCH]

Yes, the authentik callback url is fine, and everything from authentik side is fine I guess. I guess there is some error on seer side while processing authentik returned token.

Incognito doesn't change anything.

Logging level is debug default, and there is no any logs while login.

Either rollback to the previous release using the SHA digest posted above

I've already tried the preview-new-oidc and ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6. Is this is a right one?

[Taegost]

Yes, the authentik callback url is fine, and everything from authentik side is fine I guess. I guess there is some error on seer side while processing authentik returned token.

Incognito doesn't change anything.

Logging level is debug default, and there is no any logs while login.

Either rollback to the previous release using the SHA digest posted above

I've already tried the preview-new-oidc and ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6. Is this is a right one?

What you're seeing is exactly what I experienced on the preview-new-oidc tag. When I switched to the sha256 tag that you have here, it worked for me without any further changes.
In Authentik, I'm using Strict redirect URLs with the following settings:

• https://seerr.domain.com/login
• https://seerr.domain.com/profile/settings/linked-accounts
  I actually have 4 entries in total, I put both seerr and jellyseerr subdomains since my of my users have the jellyseerr domain bookmarked, and I've verified that Authentik works with both.
  If you still need help with it, feel free to reach out to me.

[SKProCH]

Ok, apparently there was be something wrong with my already existing user. Dropping the seerr database, while keeping the same config allow me to authorize myself fine.

[baxtrax]

Just want to say I also ran into this exact same issue with both versions and dropping the db also fixed it for me aslo

[Taegost]

I had an existing user who couldn't log in either, it kept saying that he wasn't authorized to login with SSO. I had to delete his profile and have it re-created for it to work again for him.

[caplam]

I had the same problem when migrating yesterday from the old preview to the new, with authentik:
Message telling me account already Linked or no message and back to login screen all these with a mac on Vivaldi or brave browser.
But on iPhone with safari it was ok.
Then i used the image with tag given above and all was ok.

[maxenced]

Trying this feature right now and can make it work. The only thing I don't understand (not event sure if it is possible) is :

• if newUserLogin is true, ANY user with an account on this provider can login
• if newUserLogin is false, there is no way I can pre-auth some email / user ?

So my question is : is there a way to pre-authorize/pre-create users so that only the people I authorize can login (yet) ? I tried to create a local user with same name but then I get a "you are not authorized to login with Google"

[theronypony]

I’m doing this with LDAP. I suppose as a workaround could turn on new user login, log in once as the user, then turn it off.

[Taegost]

I have my instance set to disallow new users, but there are still 2 ways to let in new users:

• You can import them from Jellyfin (if you use it. I don't know if Plex has a similar function)
• With the OIDC feature enabled, users that you give access to Seerr in your SSO system (in my case, Authentik) will have an account created for them at first login (I can't remember if that's a specific setting in the Seerr config or not, I assume that it is)

[TuotHash]

When can we expect to see this in a release?

[Foxite]

'Twill be done when 'tis done.