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: 01/06/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

[n1ght-hunter]

i think he means automatically. I'm kinda running into the same issue. If my users want to use OIDC each one has to manually go and link the account which honestly most probably just wont even bother doing. Other applications just match the email or whatever to accounts and effectively auto link them.

[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?

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

[Msuix1]

same here. net-new seer users through oidc (Pocket ID) are signed in and created fine, but if the user already exists as a Plex user in seer, seer throws a SSO error. If I trash the conflicting user within seer and the user tries sign-in through oidc again, the account is made and the user has no issue. So yeah, something wrong with adding the linked oidc account to the existing user in seer it seems.

EDIT: If you direct users to the Linked Accounts portion of their profile within seer, they can Add the OIDC account from there and it will union the access as expected. It's too bad this doesn't happen automatically on sign-in when there's a match on account email, but that is fixable.

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

[TN-1]

My 2c: I migrated over from Jellyseer:preview-oidc to ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6, and once I fixed the redirect URI in Authentik (Just delete the old one and let it fill it in next login) and it is all working great.

[CJOWood]

[hax4dazy]

Hey bud, you might wanna remove your clientSecret and issuerURL. You just basically gave anyone the tools to impersonate your SSO client. (prob also a good idea to rotate your secret after you remove it)

[cordlord]

@gauthier-th Sorry to bother, would it be possible to get the tag updated with today's changes?

[gauthier-th]

Tag updated.

[hax4dazy]

Perfect, thanks for the tag update. Logging in works for me again!

[jakecelentano]

Thanks for picking this back up!! Looking forward to this feature!

I deployed this branch end-to-end against my Authentik instance (IdP on a
sibling subdomain, e.g. auth.example.com → app.example.com, app behind a
reverse proxy with TLS terminated upstream) and hit two things that blocked
login for me.

I threw it to Claude Code & got the following, if it's at all useful.
FWIW, it's now working e2e for me

SameSite=Strict on the correlation cookies broke the callback. Afterthe redirect back from Authentik, the oidc-state / oidc-code-verifiercookies weren't sent, and the callback failed with Rejected OIDC callback without correlation cookies. Switching them to SameSite=Lax made it work (callback returns 204 with the cookies present).

The IdP and app are the same site, so Strict arguably should've survived, but Lax reliably fixed it for me, and it's what the OAuth 2.0 BCP suggests for state/PKCE cookies

After a successful callback, every authenticated request 401'd with cookie 'connect.sid' required. The callback itself returned 204 and the session was created, but /api/v1/auth/me (and everything else) rejected it.

I traced it to cookieParser(settings.clientId) — express-session signs connect.sid with sessionSecret, so the different cookie-parser secret makes the session cookie unreadable to the OpenAPI validator. Looks like the same thing as #3024. Dropping the cookie-parser secret and reading the correlation cookies unsigned fixed it for me (they're already HttpOnly + Secure high-entropy values, so signing didn't seem load-bearing).

[Taegost]

It looks like the latest changes that were pushed a couple days ago to the preview-new-oidc tag fixed the issue with the 401's.

[baudneo]

I didnt see this issue on a quick review of this thread, but when I try to link an authentik account from my main existing plex account in: Users -> <main plex account Username> -> Linked Accounts -> Link Account -> Authentik. It throws a URI redirect error. I had to add this regex based redirect URI for it to work: http://10.0.22.9:5055/users/\d/settings/linked-accounts.

Make sure Strict is changed to Regex as the \d corresponds to the user ID and can change.

[hax4dazy]

I managed to remove the admin status from my account, does anyone know how i need to edit my user in the database to make myself an admin again?

[Foxite]

There is a sqlite file in /app/config/db if you're using Docker, open it with a sqlite editor of your choice while the app is shut down.

Set permissions value of your user to 2.

UPDATE user SET permissions = 2 WHERE id = yourUserId; ought to work

[Prankish8407]

can i safely update from this image "fallenbagel/jellyseerr:preview-OIDC" to the new one with tag?

[jimsladek]

Hello I use image seerr/seerr:preview-new-oidc &
ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6 but i don't see the option to add oidc authentik from Settings -> Users i have only Activate the Jellyfin connection & Enable Local Sign-In. I'm the only one ?

[lex87-star]

I'm guessing it's because the oidcLogin is supposed to be outside of the oidc struct. In your config it is nested inside the oidc struct.

I'm guessing it's because the oidcLogin is supposed to be outside of the oidc struct. In your config it is nested inside the oidc struct.

the oidclogin is missing, if i add them manually and restart the server it vanished and just what you see blow will stay:

 },
 "oidc": {
  "providers": [
   {
    "slug": "authentik",
    "name": "authentik",
    "issuerUrl": "https://auth.test.com/application/o/jellyseerr/",
    "clientId": "dfdf",
    "clientSecret": "sdfdsfd",
    "logo": "https://cdn.jsdelivr.net/gh/selfhst/icons/svg/authentik-light.svg",
    "newUserLogin": true,
    "oidcLogin": true,
    "requiredClaims": "",
    "scopes": "email openid profile"
   }
  ]
 },

[jimsladek]

oidcLogin option already existe in settings.json you just need to move the value to true & remove the one you added in oidc providers config

[baudneo]

I'm guessing it's because the oidcLogin is supposed to be outside of the oidc struct. In your config it is nested inside the oidc struct.

I'm guessing it's because the oidcLogin is supposed to be outside of the oidc struct. In your config it is nested inside the oidc struct.

the oidclogin is missing, if i add them manually and restart the server it vanished and just what you see blow will stay:

 },
 "oidc": {
  "providers": [
   {
    "slug": "authentik",
    "name": "authentik",
    "issuerUrl": "https://auth.test.com/application/o/jellyseerr/",
    "clientId": "dfdf",
    "clientSecret": "sdfdsfd",
    "logo": "https://cdn.jsdelivr.net/gh/selfhst/icons/svg/authentik-light.svg",
    "newUserLogin": true,
    "oidcLogin": true,
    "requiredClaims": "",
    "scopes": "email openid profile"
   }
  ]
 },

See this config ->

#2721 (comment)

[lex87-star]

is config ->

the "oidcLogin": true, will be removed all the time as soon as i restart the seeerrr server

[baudneo]

I'm out of ideas on how to communicate with you effectively, I'm tapped out of this convo from here on out.

[tholeb]

Really hyped for this feature ! Is there any ETA for the stable release ?

How safe is it to move from v3 ?

[baudneo]

Try changing the issuer URL: https://authentik.company/application/o/seerr-oidc/

[baudneo]

youre welcome

[tholeb]

Try changing the issuer URL: https://authentik.company/application/o/seerr-oidc/

same, the button is not showing up.

I tried doing a fresh install, but I have the same issue.

Even renaming the slug to seerr.

I guess i'll wait for the official release 😅, thanks for the help anyway

[lex87-star]

same here, i have some issue even though my issuer url was ../o/jellyseerr i had as slug authentik. I adapted this but still getting the 401.
No issues with ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6

[tholeb]

same here, i have some issue even though my issuer url was ../o/jellyseerr i had as slug authentik. I adapted this but still getting the 401. No issues with ghcr.io/seerr-team/seerr@sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6

I indeed receive a 401 on seerr.bla.com/api/v1/auth/me.

[ricklahaye]

I used image preview-new-oidc and received the following error:

seerr  | 2026-06-15T21:28:13.726Z [error][Auth]: SQLITE_ERROR: no such column: User__settings.discordId 

[lex87-star]

You using a discord as social auth provider?
You can try to
ALTER TABLE user_settings ADD COLUMN IF NOT EXISTS "discordId" character varying;

As mentioned above in the settings but backup first

[ricklahaye]

I never used the discord social auth provider. I came straight from :latest tag.

After altering the table I was able to login again with local account. After that I configured oidc and is working correctly now.

[soepketel-dev]

So there is still no other (newer) working release except sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6 ?

[hax4dazy]

No the latest release of preview-new-oidc works if you have a preconfigured OCID setup.

[soepketel-dev]

@hax4dazy does it contain the latest patches of release v3.3.0 ?

[cordlord]

@soepketel-dev as far as I'm aware, the tag was last updated on 06/01. v3.3.0 was released 06/09, so preview-new-oidc tag would still be on v3.2.0.
Feel free to correct me or add if I'm wrong.

[lex87-star]

No the latest release of preview-new-oidc works if you have a preconfigured OCID setup.

you are right, finally it is working without modifying anything. thanks for the info

[Volterxien]

Wondering if there's a way this could be configured to optionallt link to a jellyfin account?
This would enable plugins such as jellyfin enhanced that incorporates seerr requests directly in the jellyfin page.

I have no idea what the technical aspects of this look like tho.

[pecirep]

Jellyfin's own OIDC plugin supports account linking already, no need to do it here. And it wouldn't be right for seer to link the accounts anyway.

[Volterxien]

If you log in with OIDC to seerr tho it creates a local account rather than a jellyfin account. Unless this has already been changed?
Sorry if I'm misunderstanding

[theronypony]

I'll just add that for existing accounts on Jellyfin, as long as the username is an exact match, it should link the account

[Volterxien]

That sounds perfect. Thanks so much!

[BoBeR182]

Looking to get this working as well. I want to link my Jellyfin account > Seerr via Jellyfin Enhanced, and be able to login to both application with a single keycloak user.

[Hydropants]

Hi All,

I am wondering if there is a "launch URL" that I could use in my Authentik? I want to be able to launch the 'app' from my Authentik apps page and it automatically logs in... Other apps seem to give you this URL. (I dont want to launch the seerr login page and have to click the 'login with Authentik' button)
I have tried various URL's to no avail. I will list below what I have tried.

- /login
- /api/v1/auth/oidc/login/<slug of oidc provider>

The response I get from "/api/v1/auth/oidc/login/" is displayed on my browser like
{"redirectUrl":"https://my.authentik.com.au/application/o/authorize/?redirect_uri=http%3A%2F%2Fmy.overseer.com.au%2Flogin&scope=openid+profile+email&code_challenge=InImogC8IswBkQzWiDnQ4BBPS-LV3g4unhW_QoZMCe8&code_challenge_method=S256&state=ReazDmSYy04ZxNrTqDIbFcw8FDaDEjbgbq_Qw8-5tU0&client_id=<client ID>&response_type=code"}
It doesnt seem to perform the redirect

I had noticed that in the above redirect uri that the schema is http and my overseer is on https ... could it be that?

[Taegost]

The launch URL and redirect URL are two different things. The Launch URL gets pointed to whatever URL you have set up for Seerr itself.

The two redirect URLs you need in Authentik are:

• https://yourseerserverurl.com/login
• https://yourseerserverurl.com/profile/settings/linked-accounts

On the Seerr side, the issuerURL needs to be the following, where "slug" is the slug you defined for it in Authentik:

• https://my.authentik.com.au/application/o/slug/

[Hydropants]

Howdy,
I appreciate your reply.

I was asking directly what URL to use in order to initiate the login oidc login process. As if you have pressed the "Login with Authentik" button on the seerr login page.

[Taegost]

Howdy, I appreciate your reply.

I was asking directly what URL to use in order to initiate the login oidc login process. As if you have pressed the "Login with Authentik" button on the seerr login page.

That would be the issuerURL. The OIDC setup docs are in the PR for adding OIDC to Seerr, you can read it here: https://github.com/michaelhthomas/seerr/blob/feat/oidc-login-basic/docs/using-seerr/settings/users/oidc.md

[tholeb]

I've been testing the recent OIDC changes and found that sha256:a14a9c326881fdce70b00df3fc095f5b5b128f5552677f677cd3788e757fb4e6 successfully fixes the 401 error I had with preview-new-oidc. (Note: I did notice there is still a 403 occurring on the login page, but it's not blocking in any way). It would be great if this fix could get merged into the preview-new-oidc branch.

I also had a few questions regarding the future roadmap for this feature:

• Automatic Account Linking: Will there be a way to automatically link an OIDC account to an existing Jellyfin account (e.g., matching by email or username)? I was able to do this manually via the linking tab, but an automatic process would be ideal.

• SSO-Only Enforcement: Will there be an option to enforce logging in only via Authentik/OIDC by disabling local logins? If so, adding a CLI toggle to bypass this would be highly recommended in case an admin gets locked out of the SSO.

• UI Configuration: Are there any plans to allow configuring OIDC providers directly via the Jellyfin UI? If this is something you'd like to support, I'd be glad to submit a PR for it!

[voc0der]

It isn't a question. You said "Roadmap for the future". That means its not there. It's been there for years.

Under User Settings>
Enable Local Sign-In
Enable Jellyfin Sign-In

Under settings.json

{ 
   ...
   "localLogin": true,
  "mediaServerLogin": true,
  "oidcLogin": true,
  ...
}

And yes, its exhausting to talk to something thats wrong and obviously written by AI.

[tholeb]

It isn't a question. You said "Roadmap for the future". That means its not there. It's been there for years.
Under User Settings> Enable Local Sign-In Enable Jellyfin Sign-In

Under settings.json

{ 
   ...
   "localLogin": true,
  "mediaServerLogin": true,
  "oidcLogin": true,
  ...
}

I'm aware of those settings, they are exactly what I pointed out in my previous comment :

The user settings page allows you to

• use seer connection ( = local sign-in)
• use jellyfin connection ( = jellyfin sign-in)
• allow registration via Jellyfin

My questions are about features that are not implemented. I simply want to know if there are any plans on implementing them. I'm asking for automatic linking, SSO only login and OIDC setup in the UI. None of those are actually here. Hence my questions.

And yes, its exhausting to talk to something thats wrong and obviously written by AI.
What's better, a sentence with bad phrasing and mistakes or a clear comment rephrased by AI ? Anyway, it's not the place to talk about this.

[voc0der]

Am I missing something? SSO only login is possible We just covered it now twice.

[tholeb]

Am I missing something? SSO only login is possible We just covered it now twice.

I meant OIDC only login. You can't uncheck both the seerr/local login and jellyfin login and use the OIDC (authentik in my case) login.

[fallenbagel]

Am I missing something? SSO only login is possible We just covered it now twice.

I meant OIDC only login. You can't uncheck both the seerr/local login and jellyfin login and use the OIDC (authentik in my case) login.

Yes you can. Its currently only possible via settings.json because

As stated in the PR UI side will be implemented in a separate PR. The whole purpose of this PR is to rewrite it better in scoped small PRs so it's easily reviewable.