Jellyfin OIDC Integration Stalled: A Complete PR Ready but Going Nowhere

The Jellyfin open-source media server community has recently reignited debate around OIDC (OpenID Connect) authentication support. A Pull Request (PR) that appeared fully complete and recently submitted has been put on hold by the official team — a decision that has disappointed many users eager for native single sign-on capabilities. According to discussions on Reddit, the core issue isn't the quality of the code itself, but a disagreement over maintenance strategy.

What Happened: Why Was a Complete PR Shelved?

For long-time Jellyfin followers, OIDC support has been a highly requested feature. OIDC allows users to authenticate through third-party identity providers (such as Authelia, Authentik, Keycloak, etc.) for unified login — something that's essentially a necessity in self-hosted scenarios. Many users have already deployed a full SSO stack in their homelab, yet Jellyfin remains the one service requiring a separate set of credentials.

According to community feedback, the submitted PR appeared quite complete, with the feature implementation close to production-ready. Yet the Jellyfin maintainer team ultimately decided not to merge it. The reason wasn't a technical flaw — rather, the team was unwilling to take on the long-term maintenance burden of this additional code at this stage. They would prefer to first redesign and refactor the existing authentication system, then introduce OIDC on top of the new architecture.

OIDC (OpenID Connect) is an identity authentication layer built on top of the OAuth 2.0 protocol, published by the OpenID Foundation in 2014. It allows client applications to verify user identity through a trusted Identity Provider (IdP) and receive user information in a standardized JWT (JSON Web Token) format. Compared to traditional username/password systems, OIDC's core advantage is Single Sign-On (SSO): users authenticate once at the IdP and are automatically signed into all applications connected to that IdP, eliminating the need to maintain separate accounts for each service. In self-hosted environments, Authelia, Authentik, and Keycloak are the most common open-source IdP choices — they also support multi-factor authentication, access policy controls, and other advanced features, greatly simplifying permission management across a homelab. Jellyfin's lack of native OIDC support means it remains an "authentication island" within the broader self-hosted ecosystem.

The Maintainer's Perspective: Why Refactor Before Adding Features

From an engineering management standpoint, the Jellyfin team's choice has its own logic. Authentication and authorization are the security core of any server software, and introducing an external identity protocol means dealing with a series of complex challenges: token refresh, session management, user mapping, permission boundaries, and more.

Forcing OIDC onto a not-yet-cleaned-up authentication system could lead to two problematic outcomes: first, tangled old and new logic that increases the risk of security vulnerabilities; second, having to tear out already-merged code during a future refactor, creating even more technical debt. For an open-source project maintained primarily by volunteers, being cautious about the authentication module is understandable.

In other words, this isn't a rejection of OIDC — it's a refusal to build on a foundation that's about to be torn down. The team's stance reads more like "we agree on the direction, but the timing isn't right."

Community Disappointment and Practical Trade-offs

For users, this decision is naturally frustrating. A feature that's "already written" being shelved understandably creates the impression of a resource or willingness problem — especially for those who've already got SSO working across their other services and just want Jellyfin to close the gap.

This kind of tension is extremely common in open-source projects:

• Contributor perspective: They invested time to complete a working PR and want it accepted.
• Maintainer perspective: Merging means taking responsibility for that code indefinitely, including all future compatibility and security maintenance.
• User perspective: They just want the feature as soon as possible and have limited visibility into internal architectural disagreements.

These three sets of needs don't always align, and final decision-making authority rests with the maintainer team. This is a classic example of the enormous gap that exists in open-source collaboration between "code being written" and "code being merged."

How to Use OIDC Right Now

For users who can't wait for official support, the community already has some indirect workarounds available. A common approach is to use a reverse proxy combined with an identity gateway to intercept authentication requests before they reach Jellyfin — for example, using Authelia or Authentik as a front-end authentication layer. However, it's worth noting that such solutions typically can't deeply integrate with Jellyfin's native user system, and compatibility on mobile apps and certain clients can be limited.

There are also long-standing third-party plugin-based SSO implementations in the community, but since they're not part of the official mainline, users need to evaluate their stability and security independently. For production environments or multi-user shared setups, caution is still advised.

The principle behind a reverse proxy front-end authentication solution is: before a user's request reaches Jellyfin, a reverse proxy such as Nginx or Caddy intercepts the request and calls Authelia or Authentik for identity verification. Once authentication passes, the proxy forwards the request to Jellyfin with user identity information appended in the HTTP request headers. Jellyfin itself remains unaware of the OIDC flow and continues handling requests through its own account system. The main limitation of this approach is that Jellyfin's mobile clients (such as the official iOS/Android apps) typically connect directly to the server, bypassing the browser's cookie-based authentication mechanism, which causes the front-end authentication to fail. Some third-party clients (such as Infuse and Swiftfin) face similar issues. As a result, this solution works well in a web browser context but is difficult to extend across all platform clients, making it more suitable for technically proficient users with relatively simple use cases.

Conclusion

This OIDC PR being shelved is fundamentally a trade-off between "feature development speed" and "long-term architectural health" in an open-source project. It's bad news for users hoping for native SSO, but from the perspective of project sustainability, sorting out the authentication system before introducing an external protocol may well be the more responsible approach. The encouraging takeaway is that the direction toward OIDC hasn't been rejected — it's simply been deferred until a more appropriate refactoring milestone.