Feature Suggestion: Multi-User Profile Switching (Smart TV Friendly)

[Laserchrist]

I’d love to see a multi-user system in Jellyfin, similar to what's available on platforms like Netflix, Disney+, or Apple TV+. The idea is to allow multiple user accounts to remain signed in simultaneously, with the ability to easily switch between them, ideally from the home screen (even better if persistent on the top bar), without needing to log out and re-enter credentials each time. Adding an optional PIN code for individual profiles would be great for privacy and parental control.

This would be especially useful on smart TV apps, where typing credentials is cumbersome and quick switching between users is often needed.

[klaki892]

[Proposal] Multi-User Switching / "Who's Watching" Login Flow

Summary

I have implemented a "Who's Watching" style login flow (similar to Android TV Client implementation) to reduce friction for shared devices. This allows users to switch profiles quickly without re-entering credentials every time.

Status: I have a working implementation ready to become a PR here.

---

Visuals & User Flow

User Journeys

The New Experience:

1. Remember Me: On refresh or "Switch User", the user is now brought back to user select screen and can login on click of profile picture:

2025-12-17.00-14-10.mp4

---

2. Sign In Automatically: Same as old "Remember Me" - Skips user select screen entirely.

2025-12-17.00-20-55.mp4

---

3. Switch User Button

2025-12-17.00-23-01.mp4

---

The Problem

Currently, Jellyfin requires a full logout/login cycle to switch users. On shared living room TVs or tablets, this creates significant friction. Users often resort to leaving the a single account logged in permanently, which messes up watch history and is a non-starter for individuals using plugins to manage watch lists.

Implementation Details

I aimed for minimal disruption to the existing auth flow.

• Local Storage:
  • LocalStorage now maintains an array of Users [ UserId, AccessToken] instead of just one of each per server when "remember me" is enabled.
  • A new AutoLoginUserId is stored per server and is used when a user successfully authenticates with "Automatically Sign in". Cleared on sign out.
• Switch User Button
  • Exists in all menus (legacy UI & experimental) above "Sign Out". Including legacy /mypreferencesmenu

Pics of button in other layouts

1.

2. 

---

Trade-offs & Considerations

In implementing this, I had to make a few architectural decisions:

1. Security vs. Convenience:
   • While mentioned in the opening post, I did not implement a PIN to keep this proposal simple.
   • If a hidden user logins with "Remember Me" but not "Sign In Automatically" it will have no effect since they wont have a profile picture to click on.
2. UI Real Estate: Added another checkbox (Sign in automatically). I wanted to keep a legacy option for single user clients, but also rename accordingly for the change in behaviors.
3. Typescript I found the (draft?) web-client contributor guidelines looking through the matrix channel after prototyping. This change is currently in JavaScript but could be ported to TypeScript, but starts to balloon in effort/scope for the feature if I have to rewrite the touched pages in TypeScript.

Request for Feedback

I am looking for specific feedback on:

1. The UI/UX flow.
   • Right now you must "sign out" to see the options again. Would like feedback for any flow improvements here.
2. General approval from maintainers.

References

• Feature Request link
• Related existing (simplier) PR: add remember me option at login #6838

I am happy to adjust the implementation based on community standards before we submitting the PR.

If there aren't any comments within a week, I'll open a PR and adjust accordingly from there.

Edit: PR - #7446

[jbaiter]

How hard would it be to add PIN support for this? I think this is a really important features for families with children, who shouldn't have unrestricted access to the non-age-appropriate content in the main account. Allowing unrestricted switching between parent and children account would be a dealbreaker, at least for me. A TV-friendly, optional, PIN entry dialog would be amazing, especially compared to the current flow where a full login with password is required.

[klaki892]

I didn't include PIN in my proposal to keep the feature scoped to just multi-user profiles. Adding a PIN isn't technically hard, but it comes with a lot of design questions and additional work:

1. Where to store the PIN?
   Jellyfin used to have LAN-based PIN support but was removed because of security concerns.
   In my opinion if Jellyfin wanted to re-introduce PIN support, it shouldn't be network-based it would have to be individual-device based. So if we move forward assuming it's individual device based...

2. Who are we protecting from?
   Currently if "Remember Me" is enabled, the access token is stored in the browser (or app) storage. It's not encrypted so anyone with dev tools open can access it. If we introduce a PIN, there's basically an easy way and a "more correct" way:

   • Easy Way (UI gate) - We create the flow for a user to add a PIN to their device for their account. Then we make a flow for using said PIN when you want to access the account on that device. Without additional changes to the login system, the PIN isn't protecting anything other than the intended login form of entry. The PIN is just a barrier to using the access token that's already visible. This protects against non-tech-savvy kids and honest people. I likely imagine this is "good enough" but that determination is only answerable by Jellyfin maintainers.
   • "more correct" (PIN Encryption) - Essentially the easy way but we have to put more effort into it for to actually keep people out. We still have to make a UX flow for adding PINs and signing in with a PIN. But now, we need to add encryption so that when you make a PIN it's secured even from local attacks (XSS, devtools, etc.) and more tech-savvy kids. This would likely look like:
     1. On PIN creation, Salt the PIN.
        • (We now would need need to include a client-side encryption solution that works across all uses of jellyfin-web)
     2. Encrypt the login access token
     3. Store only the encrypted access token, to be opened when someone gives a PIN.

3. Recovery (using either solution) on the surface seems straightforward but it's not:

   • User forgot PIN? - Okay, enter password to re-login. Then create a new flow for user to enter a new PIN.
   • User uses manual login (for whatever reason) - Sure, but this invalidates our old access token. Now, we have to prompt the user to set a new pin or enter their old one again. - Additional Flow.
   • User changes account password on another device - Same as above, but now the flow is enter PIN, server says give password again, enter password, store PIN from first entry in memory to re-apply encryption - Additional flow
   • (optional) someone trying to brute force your PIN? - We could drop the token after a certain number of tries, or do nothing and let them eventually crack it.

Another flow is needed for "remove PIN".

So in short, PIN support just expands the scope of the changes needed for the feature.

[Linux-oiD]

@klaki892 appreciate your work under this feature!
What is the current status of PR. Do we have any blockers? Do you need any help?

[klaki892]

Sorry for the long silence for updates around this, thanks @Linux-oiD for the ping waking me up.

TL;DR - UI/UX team must approve changes like this, and UI/UX Would like to see bigger changes to the login flow as part of this change then I am currently motivated to do - So this is stalled once again on someone motivated enough to make the change.

Back in March after looking for feedback in the Client Development Matrix Chat(in January) I saw someone else was directed to bring up feature discussion in the UI/UX Matrix Chat to get UX eyes on proposals. (after my initial reach out received no feedback) The messaging was that currently all features must go through UI/UX approval or else a contributor is highly likely to not look at it.
UI/UX was responsive once I brought it up in chat and was gracious enough to give their design opinions on the current PR and draw diagrams of what they would like changed.
However I realized during the discussion that the changes they would like to see as part of this is larger than I had in mind. When I made my PR I was aiming to make as minimal of change to the overall flow as possible. UI/UX preferred a more complete change. Instead of just adding “Switch Users” functionality, they wanted a complete “Who’s Watching” flow redesign for the login process.

I’ve linked the matrix discussion, but I can pull quotes from the overall discussion and TODO items with the images UI/UX provided:

if you choose to "switch a signed-in user", the UI can't take you to a "sign in" page, but a new one that presents you with all the signed-in available users.

---

if you select a different server, you will also switch the user
if you switch the user, you might also switch the server...
--> these two should be combined into a new flow

---

Now the webapp holds a set of users (from multiple servers) - the process becomes user(account)-first.

Break the username and password inputs into their own pages.
We get a modular page that can be inserted into the flow whenever we need to unlock an account.

The unlock screen doesn't show the username field again:

• when you select a user that requires a password
• when you add a visible account that has a password
• when you add a manual account; you first input the username, then asks for password, if account exists
  And gets skipped:
• when user's credentials are stored
• when an account is passwordless
  It's not about speed, it's about friction
  because you aren't prompted to rewrite the username

And the "forgot password button" isn't shown on the login page, but on the "unlock"/"password" page.

This is the incomplete sequence diagram I made for the mentioned changes (didn’t remake it after the talk about separating user/pass page):

There might be more changes needed, but one would have to discuss with the UX/UI team more about it.

Nothing UI/UX mentioned is something that I disagree with, but IMO, re-vamping the entire login flow felt like scope-creep for this feature. It would definitely make it more unified with what the Android TV Client has done and would provide a more streaming service like experience.

My current PR definitely has some theoretical confusing edge flows, but I’ve been using it on my instance and it’s solved the problem for me and my users. I might come back to this again later when I want to upgrade versions, but for now I’m low on motivation to make a bigger change than what I’ve already done. As the UI/UX wanted changes are substantial since it’s a re-work of the entire jellyfin login flow in both the old and new UI themes.

Hopefully I’ve provided a good jump start to anyone wanting to take a go at this.

[Martogh-wq]

Thanks for your work on this. It would be great to see implemented.