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.