• 0 Posts
  • 5 Comments
Joined 3 years ago
cake
Cake day: June 16th, 2023

help-circle
  • to get something that is idiot proof.

    The problem with Jellyfin in particular is that it needs to support binary streaming protocols. You can implement some gateway/firewall-based security in front of Jellyfin, but in the end it is still Jellyfin’s internal mechanisms mostly responsible for its own security. I don’t use Authentik but I have read many good things. The only real “advantage” of it is that it forces your users to somewhat better credential handling. Jellyfin still only supports LDAP, so the users will have to enter their Authentik username and password – very similar to just local accounts managed by Jellyfin. So IMO, not offering you that much extra in terms of security. You will be better served by firewall tools like fail2ban, crowdsec, geo-fencing, etc.

    Depending on where/how your users access Jellyfin you could have something a bit tighter. If they never run it on a TV you could do something more advanced like mTLS where you issue them a certificate with a TTL of several years, walk them through installing it on their phones/laptops, and then have that in a reverse proxy. But at that point you might as well walk them through setting up a VPN mesh network.

    For Seerr, it’s just a standard web app .You could put a reverse proxy in front that requires OIDC with Authentik. Seerr is also pretty close to having native OIDC integration. Personally I prefer having two rounds of OIDC – reverse proxy really narrows what the public can see as a first layer.

    For BookOrbit, I am not familiar enough with the Kobos. My guess is, you could put BookOrbit behind a reverse proxy that enforces OIDC, but you might have to allow a bypass for /api route. Then you’re relying on BookOrbit to authenticate all /api requests through API tokens. This would look like the normal Kobo linking process, so no real difference, but then your BookOrbit web UI is locked behind OIDC authentication.