[Feature request] SSO

[Cookie-Monster-Coder]

Description

Jellyfin has SSO with this plugin https://github.com/Pfuenzle/jellyfin-plugin-sso and with https://github.com/goauthentik/authentik you are able to use SSO as the provider.

Desired Behavior

Automatically sign in if the auth provider/Jellyfin is signed into.

Additional Context

Provide any additional information or screenshots that may be relevant or helpful.

[fallenbagel]

It seems that it's a feature (sct/overseerr#1638) not present in the core Overseerr too. For now our main focus is to simply add Jellyfin/Emby/Plex support to Jellyseerr and update to the latest features of Overseerr (the :develop tag)

[DomiiBunn]

I hate to be that person but I'm not sure if #883 really resolved this one. At least it's not true SSO to be adding other streaming services via user+pass.

Unless I am blind (highly likely) the goal would be to have a redirect flow to an auth provider like above mentioned authentik or another OID/SSO provider.

At least I don't see how putting in the platforms password here is SSO. Kinda opposite since the goal of SSO is to detach t the user credential from the platform and centralize user management.

[fallenbagel]

I hate to be that person but I'm not sure if #883 really resolved this one. At least it's not true SSO to be adding other streaming services via user+pass.

Unless I am blind (highly likely) the goal would be to have a redirect flow to an auth provider like above mentioned authentik or another OID/SSO provider.

At least I don't see how putting in the platforms password here is SSO. Kinda opposite since the goal of SSO is to detach t the user credential from the platform and centralize user management.

It did not this was closed accidentally. That pr references this issue as it opens up FUTURE work for this. That pr was made to detach accounts from needing to be media server linked. Due to how our architecture was achieving SSO or OIDC or whatever was impossible with the previous way, accounts were handled. Thus that pr was created. But that pr linked this, and because the pr linked this issue, it got erroneously automatically closed when that pr was merged (and we didn't realise).

I'm not sure whether OIDC or ForwardAuth is related to this, but from what you explained, forwardAuth should be able to achieve exactly that, shouldn't it?

#1341

[DomiiBunn]

Forward auth is a lot easier for the app backend to implement. Basically check if a header exists like x-user-<email, name, groups> and than the deployment needs to have a reverse proxy that will check the auth and add the headers. It they do exist the app should auto login the user and fully bypass it's own auth flow other than group checking/permission checking

Some add another header like a proxy secret and or IP whitelisting to only allow the headers to auth users from just the trusted IPs

[tevinflores]

Hey, I started playing around with authentik and the moment I found out jellyseerr didn't support SSO, I decided to give it a shot and make it compatible with it. I created a branch with the feature working. I'd appreciate it if I could get some feedback on it.

[fallenbagel]

Hey, I started playing around with authentik and the moment I found out jellyseerr didn't support SSO, I decided to give it a shot and make it compatible with it. I created a branch with the feature working. I'd appreciate it if I could get some feedback on it.

Please open a PR for it so we can review it :)

[M0NsTeRRR]

Hello,

I’m closing this issue in favor of #183, as that is the main issue for handling this.

Regards,