Feature Request: Native SSO / OIDC Authentication for All Clients

[PloxPlox]

Jellyfin currently has no native external authentication support. The only options are:

• LDAP plugin — works with all clients but bypasses MFA and requires an additional outpost to deploy
• SSO-Auth plugin — supports OIDC/SAML but is limited to the web UI; native clients (Android, iOS, desktop) cannot use it

Users running Jellyfin behind a reverse proxy with an identity provider (Authentik, Authelia, Keycloak, etc.) are forced to either expose raw API endpoints, maintain separate credentials, or restrict access to VPN-only.

Add native OIDC/OAuth2 authentication support at the server level, allowing all clients to authenticate via an external identity provider — either through a browser-based redirect flow (similar to how many mobile apps handle OAuth) or through a device authorization flow (RFC 8628).

This would allow:

• A unified login experience across all platforms
• MFA enforcement via the identity provider
• No need for workarounds or additional plugins

[navyjosh]

I would love to see OIDC on Jellyfin. A lot of people exposing this service to web external. Usually I just use forwardauth for services that don't support OIDC but forwardauth breaks jellyfin's API so I can't use it for this service. Yes please sign me up for some OIDC.

[RockZors]

Not having this is what's holding me back from implementing jellyfin.

[jthoward64]

It's been said before by Jellyfin devs, as much as people want it; there are other things they want more and only so many devs to do it

[strazto]

that's not exactly the full picture.

There's been at least one PR raised #14729 that aims to address the feature

but the maintainers claim the current identity implementation needs big re-arch / migration to use ASP.Net Core Identity (ie, builtin ASP.Net identity infrastructure) before anyone can start adding features to it

The PR author and maintainers seem to disagree about whether that migration is feasible, since authn is so tightly coupled into the app

[Binvention]

Hard to say it's only because there aren't enough time and devs since there is an unofficial plugin that adds oidc support it's just not available as a default plugin and there's no way to disable the normal login so that it's the default method of logging in.

[manicmoose]

Hard to say...

Sadly, it looks like that SSO solution has now been archived - the DEV has had enough and given up.
If that plugin breaks in any subsequent JF release then there are no options.

Equally sadly, I know the JF dev's have their priorities, but this particular request seems to have almost 4x the number of votes than the next highest requested item does.

[snoochyp]

RFC: Native-client SSO for Jellyfin — a phased path that doesn't wait on the core identity re-arch

Author: Daniel Orcutt (@snoochyp)
Status: Draft / requesting maintainer feedback
Scope: jellyfin-plugin-sso (server), Swiftfin (iOS/tvOS reference client)
Non-goal: touching Jellyfin core's identity layer (explicitly deferred to the planned ASP.NET Core Identity re-arch)

---

Problem

SSO in Jellyfin today ends at the web UI. The jellyfin-plugin-sso plugin implements full OIDC/SAML (Google, Authelia, Authentik, Keycloak…), maps external identities to Jellyfin users, and mints real Jellyfin credentials — but the flow can only complete inside a browser with web-UI localStorage present. Native clients (Swiftfin, Android, Android TV, Roku) cannot use it at all: users behind an IdP must either keep separate Jellyfin passwords (bypassing their MFA) or run LDAP (same problem).

Meanwhile, adding OIDC to Jellyfin core is blocked on the identity re-architecture (see the stalled refactor PR and maintainer comments in the native-SSO discussion). That blocker is real, but it shouldn't leave native clients stranded in the interim.

Claim: the gap is small. The plugin can already authenticate and issue credentials. What's missing is a native-app-shaped completion path. This RFC proposes one, in two phases, with zero core changes, plus a clean migration story for when the core re-arch lands.

Prior art

Immich solved this exact problem for its mobile apps: the server is the OIDC relying party; the app opens the system browser; on completion the server redirects to a custom scheme (app.immich:///oauth-callback) that the OS bounces back into the app. For IdPs that refuse custom-scheme redirect URIs (e.g. Google), the server exposes an https forwarder (/api/oauth/mobile-redirect) that re-redirects to the scheme. This pattern is battle-tested at large scale and maps 1:1 onto Jellyfin's plugin architecture.

---

Phase 1 — SSO-assisted Quick Connect (smallest PR, unblocks every client, solves TV first)

Jellyfin already ships a device-authorization-style flow: Quick Connect. Most native clients (including Swiftfin) already support it. Phase 1 is pure glue: let a web-browser SSO login approve a Quick Connect code.

sequenceDiagram
    participant TV as Apple TV / any client
    participant JF as Jellyfin + SSO plugin
    participant Phone as User's phone browser
    participant IdP as Google / Authelia

    TV->>JF: QuickConnect/Initiate → code "ABX412" (shown on screen)
    Note over TV: "Sign in with SSO — go to<br/>https://server/sso/qc and enter ABX412"
    Phone->>JF: GET /sso/OID/start/{provider}?quickConnect=ABX412
    JF->>IdP: standard OIDC authorization redirect
    IdP-->>Phone: user authenticates (with their MFA)
    IdP->>JF: callback with code → id_token
    JF->>JF: map claims → Jellyfin user (existing plugin logic)
    JF->>JF: QuickConnect/Authorize("ABX412") as that user
    Phone-->>Phone: "Device approved ✔"
    TV->>JF: (polling) QuickConnect/Connect → approved
    TV->>JF: Users/AuthenticateWithQuickConnect → standard AccessToken

Loading

Server changes (plugin only): carry an optional quickConnect parameter through OIDC state; on successful identity mapping, authorize the Quick Connect session as the mapped user and render a confirmation page. Roughly a small, self-contained PR.

Client changes: none required (existing Quick Connect UIs work). Optional UX polish: a "Sign in with SSO" hint next to the code.

Why this first: it solves the hardest clients (TV boxes — no browser, no custom schemes) with the least code, works for every client at once, and produces an immediately demoable result that builds credibility for Phase 2.

Phase 2 — First-class native flow: Authorization Code + PKCE (reference implementation in Swiftfin)

Standard OAuth-for-native-apps (RFC 8252 + PKCE RFC 7636), Immich-style:

sequenceDiagram
    participant App as Swiftfin (iOS)
    participant JF as Jellyfin + SSO plugin
    participant IdP as Google / Authelia

    App->>JF: GET /sso/OID/providers (public)
    JF-->>App: [{name:"Google", …}] → login screen shows SSO buttons
    Note over App: user taps "Sign in with Google"<br/>ASWebAuthenticationSession opens:
    App->>JF: /sso/OID/start/Google?code_challenge=X&redirect_uri=org.jellyfin.swiftfin://oauth-callback
    JF->>IdP: OIDC authorization redirect
    IdP-->>App: user authenticates in system browser sheet
    IdP->>JF: callback → id_token
    JF->>JF: map claims → Jellyfin user
    JF->>JF: mint one-time code, 30s TTL, single-use
    JF-->>App: 302 → org.jellyfin.swiftfin://oauth-callback?code=Y
    App->>JF: POST /sso/OID/token {code, code_verifier, deviceInfo}
    JF-->>App: standard Jellyfin AccessToken
    Note over App: from here the session is indistinguishable<br/>from a username/password login

Loading

New plugin surface (3 endpoints):

Endpoint	Purpose
GET /sso/OID/providers	public discovery: provider list for login UIs (empty ⇒ clients render nothing new)
POST /sso/OID/token	one-time-code → Jellyfin AccessToken exchange (PKCE-verified, device-bound)
GET /sso/mobile-redirect	https→custom-scheme forwarder for IdPs that reject custom-scheme redirect URIs (required for Google)

Swiftfin changes: SSO buttons on the server login view (driven by discovery — local username/password auth remains untouched and default); ASWebAuthenticationSession + callback handling; token storage via the existing keychain path. Custom URL schemes work on free Apple developer accounts, so contributor friction stays low.

Android and other clients get the same server contract; Chrome Custom Tabs / equivalent per platform. Swiftfin serves as the reference implementation.

Local-auth coexistence (explicit requirement)

• The username/password form is never removed or gated.
• SSO affordances appear only when /sso/OID/providers returns entries — old servers / plugin-less servers see zero UI change.
• Admins choose per-provider whether accounts auto-create or must pre-exist (existing plugin semantics).

Security model

• PKCE (S256) mandatory; state validated on every callback
• One-time codes: ≤30s TTL, single-use, bound to the requesting device identifier
• Access tokens never appear in URLs, browser history, or logs — only the one-time code rides the redirect
• redirect_uri allow-list: only registered client schemes (org.jellyfin.swiftfin, org.jellyfin.mobile, …)
• Token-exchange endpoint rate-limited
• Identity mapping is explicit-claim based (sub/email → user); auto-provisioning off by default (username-collision account takeover is the classic SSO-plugin vulnerability class)
• Quick Connect path inherits Jellyfin's existing QC hardening (server-side toggle, code expiry)

Migration story (why this doesn't fight the core re-arch)

The client-facing contract is deliberately tiny (providers, start, token). When the ASP.NET Core Identity re-arch lands, these endpoints migrate from plugin to core with unchanged shapes — no client releases required. Phase 1/2 code becomes the interim implementation and the de-facto spec for core's native SSO, rather than throwaway work.

What I'm offering

I'm prepared to implement this: Phase 1 plugin PR first, then the Phase 2 plugin endpoints + the Swiftfin reference implementation (tested against Authelia and Google on my own infrastructure). Requesting feedback on: (1) appetite for this in jellyfin-plugin-sso vs. elsewhere, (2) the one-time-code exchange design, (3) Swiftfin maintainers' preferences for the login-screen UX.

[Essjayess]

* **LDAP plugin** — works with all clients but bypasses MFA and requires an additional outpost to deploy

I also want OIDC. But this statement is false regarding bypassing MFA. I have the LDAP plugin configured with an LDAP outpost. MFA is enforced with Authentik. My users have to type username and then password;token to login.