Skip to content

Client Compatibility

Nils Lehnen edited this page Aug 21, 2026 · 1 revision

Client Compatibility

Which Jellyfin client can complete an SSO sign-in, and by which mechanism. The behavioural explanation of the two mechanisms is on Login Flow § Non-web clients and Quick Connect; this page is the per-client concretisation of it.

The two mechanisms

  • Direct browser redirect. The client is a web browser, so it can run the redirect to the identity provider and the callback page the plugin serves. This is the Jellyfin Web UI, in a browser or inside a desktop client that embeds it.
  • Quick Connect. The client shows a six-character code, the user signs in through SSO in a browser and approves that code on an already-authenticated device, and Jellyfin hands the authenticated session back to the waiting client. Quick Connect is Jellyfin's own mechanism. The plugin carries no Quick Connect code of its own; its role is to make the browser login SSO-capable.

A client that can do neither cannot complete an SSO sign-in at all. Those are marked use the Web UI below.

Per client

The mechanism column is read from Jellyfin's own Quick Connect client-support table (https://jellyfin.org/docs/general/server/quick-connect/), which is upstream's statement about its clients rather than a measurement made here. The status column is this project's, and it says only what has actually been exercised against this plugin.

Client Mechanism Status here
Jellyfin Web Direct browser redirect Verified. The browser redirect and callback round trip runs against real identity providers on every scheduled end-to-end run in CI.
Jellyfin Media Player (desktop) Quick Connect; it also embeds the web UI Not yet verified
Jellyfin Android Quick Connect Not yet verified
Jellyfin Android TV Quick Connect Not yet verified
Jellyfin Mobile (iOS) Quick Connect Not yet verified
Swiftfin (iOS) Quick Connect Not yet verified
Swiftfin (tvOS) Quick Connect Not yet verified
Jellyfin Roku Quick Connect Not yet verified
Jellyfin WebOS Quick Connect Not yet verified
Jellyfin Xbox Quick Connect Not yet verified
JellyCon Quick Connect Not yet verified
Jellyfin Kodi None - use the Web UI Unsupported
Jellyfin MPV Shim None - use the Web UI Unsupported
Jellyfin Vue None - use the Web UI Unsupported

What the status column means

  • Verified - a round trip through this plugin has been run and observed. Today that is the browser redirect flow only, driven by the automated end-to-end harness against real identity providers.
  • Not yet verified - the client offers a mechanism this plugin supports, and nobody has run the round trip against it and written the result down. It is not a report that the client fails. The Quick Connect round trip is a manual item on the release checklist because it spans two devices and runs through the host's Quick Connect endpoints, which the automated harness does not drive.
  • Unsupported - the client offers neither mechanism, so there is nothing to verify.

No cell says verified for anything that has not been exercised, and an honest blank is preferred here over a fuller-looking table.

Approving the code matters as much as showing it

Quick Connect needs a second, already-authenticated device to approve the code, at Settings → Quick Connect. Not every client that can log in with Quick Connect can approve a code for another device: upstream's table marks JellyCon, Jellyfin Android TV, Jellyfin Roku and Swiftfin (tvOS) as log-in only.

For an SSO-only server that is the shape to plan for. The first sign-in on a household's TV needs a browser somewhere - a phone or a desktop - to complete the SSO login and approve the code, because a TV app that cannot approve cannot bootstrap itself.

If a client is missing here

Add it by running the round trip and recording what happened, including a failure. A result written down is worth more than a row that guesses, and a client nobody has tried belongs in the table as not yet verified rather than out of it.

See also

Clone this wiki locally