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.

[phoenix-limited]

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.

[hax4dazy]

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

[caplam]

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

[keesfluitman]

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

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

[smdion]

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

[Cookie-Monster-Coder]

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

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

But you can do it via Cloudflare Redirect Rules:

[HumnResources]

After this latest update, my authentik config is no longer working due to a mismatched redirect uri. I was using an older version with the following working fine (note there's no slug for authentik);
https://jellyseerr.DOMAIN.TLD/login/oidc/callback

I have a small user base so I just deleted the db/cache folders and rebuilt from fresh. After setup, I changed my redirect uri to the following;
https://jellyseerr.DOMAIN.TLD/login/oidc/callback/authentik
as per the previous comments, adding the slug for the provider. (which was not seemingly necessary before). However this hasn't made any difference. Was there a change to the redirect uri from what's posted here?

Edit:

A copy of my oidc config on jellyseerr;
{
"slug": "authentik",
"name": "Authentik",
"issuerUrl": "https://auth.domain.tld/application/o/jellyseerr/",
"clientId": "<CLIENT_ID>",
"clientSecret": "<CLIENT_SECRET>",
"requiredClaims": "media",
"scopes": "email,openid,profile,groups",
"newUserLogin": true,
"logo": "https://auth.domain.tld/favicon.ico"
}

Edit 2:

I managed to get it working. For anyone who runs into this issue, simply removing the redirect from authentik entirely and allowing it to find the uri itself seemed to work. Not sure the difference as the actual uri itself is the same. Likely just internal referencing of sorts.

[denisgabriel5]

Sooo, what callback URL should I use? I tried quite a few variations, but nothing worked. Some of the variations I tried:

• https://jellyseerr.example.com/login/oidc/callback/slug
• https://jellyseerr.example.com/oidc/callback/slug
• https://jellyseerr.example.com/oidc/login/slug

[michaelhthomas]

It should just be https://jellyseerr.example.com/login

[denisgabriel5]

That didn't work either. Just to make sure, is this the correct docker image that I set in my docker-compose.yml?

image: fallenbagel/jellyseerr:preview-OIDC

Also, the Issuer URL should be just https://auth.example.com, right?

[bzly]

In the Authentik provider you can remove all entries for redirect URIs and the first successfully used one is then populated. This feature has helped me realise before when I've had things misconfigured and was being redirected to my local IP. I'm up to date with the fallenbagel/jellyseerr:preview-OIDC tag and my redirect URI is https://jellyseerr.example.com/login/oidc/callback/slug.

In Jellyseerr my issuer URL is https://auth.example.com/application/o/application-slug.

[denisgabriel5]

I left it blank and it worked. Weird. Thanks a lot tho.

[slimshizn]

Got this working thanks to some of the comments. Thanks!

Seems disabling Emby login does not work, as the login screen still shows Login with Emby This works if using CF #1529 (reply in thread)

Separately the provider button seems to be showing the name twice, causing the words to look jumbled. Due to the image, removed the url and it's gone.

Is there any way to have the provider name be separate from the slug? It allows it when you first create the authentication, but afterwords if you change the name, it also changes the slug to match.

[MobButcher]

I've been rocking this branch for a couple of days now without issues. I've set up login with Authelia and it's all working, including automatic creation of new users, and them setting up initial password for direct logins.

Currently I would love there to be no login/password fields when there is only Authelia access enabled, so that this way I can force auth only through OIDC and have a single button login. That, and I haven't figured out how I can pass avatars from my LDAP through Authelia and into Jellyseerr. That would be absolutely wonderful to figure out, 'cause it'd mean I can have unified avatar pictures across my services.

[slimshizn]

This works #1529 (reply in thread) assuming you are using CF.

[MobButcher]

I'm sure I can adapt that for Caddy server, which I'm using, but my suggestion was more about disabling login fields in UI while still presenting the OIDC button option. It's theoretically possible that users can somehow bypass these kinds of redirects, and it would be nice to not have to do that.
I do appreciate the suggestion, though!

[bzly]

I'm running the latest Docker image from fallenbagel/jellyseerr:preview-OIDC and with only OIDC login enabled my login page does not have any user/pass fields:

[MobButcher]

That's not my experience, unfortunately. I've disabled everything but the OIDC, and I've even restarted the server to make sure, but no dice. The option to log in through Jellyfin was enabled, though, and my owner account is connected to Jellyfin, so that might be why.