Native OIDC Coexistence

Native OIDC Coexistence

Jellyfin upstream is building native OpenID Connect into the server: jellyfin/jellyfin#17271 (open, no longer draft; last activity July 2026), driven by demand discussion #16470. Jellyfin 12.0 is in feature freeze, so native OIDC lands 13.0 at the earliest. This page is the plugin's documented stance: what native OIDC changes, what it does not, and how the two coexist.

Stance

This plugin complements native OIDC; it does not race it. When the server grows a first-party OIDC core, that is good for everyone — fewer passwords in the world. The plugin remains the answer for everything the native core deliberately leaves out, and for every server release line that predates it (10.11/11.x/12.x will never get native OIDC).

This plugin vs. the native draft

What the native draft (#17271) implements today: provider configuration with secret redaction, one-time provider-bound exchange codes, external identity links keyed on (providerId, issuer, subject), create-user provisioning, required groups, and admin-group sync with last-admin protection.

Capability	Native draft (#17271)	This plugin
OpenID Connect sign-in	✔	✔
SAML 2.0 sign-in	— (explicitly excluded)	✔
Multiple providers side by side	✔	✔
Role → admin mapping	✔ (admin group sync)	✔
Role → library-folder / Live TV mapping	—	✔
Avatar sync from the IdP	—	✔
Self-service account linking	—	✔ (/SSOViews/linking)
SSO-only mode (password login off, break-glass)	—	✔
Last-admin protection	✔	✔
Server range	13.0+ (at the earliest)	10.11 / 11.x / 12.x (today)

Convergent design (independently arrived at): the plugin's one-time login-outcome token (#251) has the same shape as the native draft's one-time exchange codes — both bind a completed browser login to a single client token issuance.

Link-model alignment (migration honesty)

A future "hand your links to the native core" migration is not committed, but the semantic differences are documented now so nothing here silently hardens against it:

• Key shape. The plugin keys links on (protocol mode, configured provider name, subject) — the provider name is the admin-chosen configuration name. The native draft keys on (providerId, issuer, subject) — a stable provider entity id plus the issuer in the key. A migration must map configuration names to provider entities.
• Issuer binding. The plugin binds the issuer to an OpenID subject link trust-on-first-use at login (#186) — the issuer is a validated attribute, not part of the storage key. Upstream makes the issuer part of the key itself. Post-TOFU links carry the issuer and could be exported; a link whose user never signed in after #186 carries none and would need a re-login (or stay plugin-owned).
• Legacy username-keyed links (pre-#155) migrate lazily to the stable subject key on login. An export would require them resolved first — same re-login answer.
• SAML links have no native counterpart and remain plugin-owned indefinitely.

What we track

• jellyfin/jellyfin#17271 — the native OIDC implementation PR (merge target and final capability set).
• jellyfin/jellyfin#16470 — the demand discussion.
• The 13.0 release cycle, once 12.0 ships.

When native OIDC ships, this page gains a migration section with concrete guidance; until then the plugin's positioning is unchanged — the option for SAML, richer RBAC, linking, avatars and SSO-only on every current Jellyfin release. Contacting upstream about link interop is a separate decision I would take deliberately, not a side effect of this page.