https://www.hdserver.info/blog/x0htc81b9/
以前の記事で、自分だけのメディアサーバとしてPlexを使ったサイトを作ってみた、みたいなのを公開しました。(もう8年前w)
実は最近までずっと運営していたのですが、Plexさんがサービスの改悪変更をしたみたいで、使い勝手が一気に悪くなりました。
Plexのよかったところと経緯
plexって何?という方は上記の公式サイトを見ていただくか、私が昔書いた記事をご覧ください。
無料で簡単に自分だけのメディアサーバを構築できるのが大変魅力的で、快適な動画ライフを過ごせる強みがありました。
- 対応プラットフォームが豊富
- ライブラリの自動整理
- リモートアクセス可能
- 認証方法はPlexネイティブアカウント、Google、Appleなどが用意されている。
特に最後の認証方式は強くて、認証・認可機能を自前のPlexサーバに置かなくて済むので、外部公開におけるセキュリティ面で安心でした。
有料版も用意されていますが、無料版でも上記の機能が揃っていて個人的には最強....!
ところが、今年の3月頃にPlexさんからメールが...
Dear Plex Users,
It’s been almost a year since we first shared some important updates about the future of remote streaming on Plex, including the introduction of the Remote Watch Pass. Since then, we've been rolling out these changes platform by platform, starting with mobile and most recently on Roku.
Today, we're writing to let you know that starting March 23, 2026, remote streaming of personal media will require a Plex Pass or Remote Watch Pass on Plex for Smart TV devices. This includes Plex running on supported TVs like Samsung, LG, Vizio, and more, as well as on PlayStation and Xbox gaming consoles.要約すると、リモートアクセス(外部からメディア鑑賞)する場合は、有料のPlex PassかRemote Watch Passを買えよ、ということみたいです。
な...なんだと。。ここ金取ってくるか...
とはいえ仕方ない部分もあるんです。
そもそもPlexはOSSではないし、最近は著作権の観点からも締め付けが厳しくなっているので、無法ユーザを排除する動きなんだと思います。にしても結構な頻度で機能の有料化を推進していくので銭ゲバな印象ですが
ここを塞がれるとメディアサーバとしての役目が弱くなってしまうので、この通知を機にOSS版のJellyfinに移行しました。
実は使い方としてはPlexもJellyfinも変わらなくて、自宅のNASサーバにアプリをインストールしてServerとして解放しているだけなんです。
セットアップや機能面に関してはJellyfinもPlexと遜色なくて、自動整理までしてくれるので、あまり強いストレスは感じませんでした。
ただ1点だけ、jellyfinにどうしても不満があった機能がありました。ユーザの認可・認証機能です。
jellyfinはユーザ情報をサーバ内に保持する
まぁ、OSSなんで当然ちゃ当然。
WordPress運営している方とかは「なにをそんな」と思うかもしれませんが、これが結構厄介でして。
昨今はサイバーセキュリティのニュースを沢山目にすると思いますが、やはり外部公開されている箇所に攻撃を仕掛けてくるんですね。
しっかり対策をしていても、脆弱性を突かれて侵入を許してしまった、といったケースもあるんじゃないでしょうか。これはとっても怖い。
なので、なるべく認証・認可の部分は外部連携するのが一番いいんですね。SSOなりIDaaSなり。
Plexはこの点、外部連携で標準ログイン設計になっていたのが素晴らしいのですが、Jellyfinにはなく...
Redditみても同じような質問がいくつか立てられていました。
LDAPやADという手法もあるようですが、正直これの為だけに構築・運用するのはしんどみの鎌足。
1つだけコミュニティでSSO-Auth プラグインが公開されていたのを目にしたので、
気になってPoCをしてみたところ、ある程度理想の状態まで持っていけることがわかったので、今回はこちらの内容について記事にまとめます。
SSO-Auth プラグインについて
こちらで公開されている、jellyfin-plugin-ssoというプラグインになります。
最初に注意点だけお伝えしますと、このリポジトリは 2026/05/12にパブリックアーカイブとなっています。
つまり、今後アップデートは行われず、サポートや保証もない、ということです。
なので、これからJellyfinでこのプラグインを使ってSSO化をする、という方がいましたら、すべて自己責任であることを念頭に置いてくださいませ。
※プラグイン利用により生じたいかなる損害についても、当サイト運営者は一切の責任を負いません。
初期セットアップ方法
https://github.com/9p4/jellyfin-plugin-sso#installing
基本はREADMEにあるinstallingの項を進める。
Jellyfinのダッシュボードからplugin repositoriesを登録すると、GUI上でプラグインがインストールできるみたいです


ログイン画面にSSOログインボタンを設置する
https://github.com/9p4/jellyfin-plugin-sso#examples
jellyfinにはカスタムCSSが使えるようで、そこでSSOログインボタンのboxを追加する感じ
最下部にSSOログイン用のボタンが表示されるようになります。
ASIS

TOBE

Google Oauthトークンの発行と連携
今回OIDCの連携先はGoogleにしました。他のOIDCプロバイダーは未検証ですが、SCIM対応していればいけるんじゃね
なお、Google Oauthを利用するには、Google Cloud Platformアカウントが必要になるので開設しておきます。
(大丈夫、お金はかかりませぬ)
Google Cloud 側の設定
- Google Cloud Consoleで OAuth同意画面 を作成
- 認証情報 から OAuth クライアントID を作成(種類は ウェブアプリ)
- 承認済みのリダイレクトURI に次を追加
https://あなたのJellyfinドメイン/sso/OID/redirect/google - 作成された クライアントID と クライアントシークレット を控える
Jellyfinプラグイン側の設定
- Jellyfin に管理者でログイン
- ダッシュボードを開く-> プラグイン-> マイプラグイン -> SSO Auth(または SSO Authentication)を開く
- 設定ページ内の OpenID Provider で Add / Update Provider Configuration を入力
- Provider名は google にする(任意だが分かりやすい)
- 主な項目を設定
- OidEndpoint:
https://accounts.google.com - OidClientId:
Googleで作成したクライアントID - OidSecret:
Googleで作成したクライアントシークレット - Enabled:
true
- OidEndpoint:
- Google向けの重要設定
Do Not Validate OpenID Endpointsを有効化
(このプラグインではGoogle利用時に必要になることがある)- Jellyfin が内部 http で動いていて、外部が https の場合(プロキシ使っているケースが該当)
- プラグインが http の redirect_uri を生成することがあります。
その場合は SSO プラグインでSchemeOverride=https(必要ならPortOverride=443)を設定してください。
- プラグインが http の redirect_uri を生成することがあります。
- 保存
続いて、カスタムCSSで設定した内容を追加修正します
Jellyfin管理画面の Branding の Login disclaimer に、SSO開始URLへ飛ぶボタンを置くhttps://あなたのJellyfinドメイン/sso/OID/start/google
動作確認
- シークレットウィンドウで Jellyfin ログイン画面を開く
- SSOでログインを選択
- Google認証後に Jellyfin に戻ってログイン完了するか確認
ここまでで、Googleアカウントでログインできるようになります。
おめでとうございましたー。
問題
実はここまでだと、とある問題が発生します。
- Googleアカウントを持つユーザは、Jellyfinにユーザがなくてもアクセスできてしまう(自動的にJellyfin側にユーザが作成される)
- 作成されたJellyfinユーザはGoogleアドレスや名前を踏襲せず、ランダムな文字列で生成される(
09434876621みたいなユーザ名になる)
2.はプラグインの作者も言及している問題っぽい。
致命的なのは1.で、Googleアカウント持っている人はだれでも入れちゃうという異次元のノンセキュア環境になってしまう。
公開用のJellyfinサーバならまだしも、プライベートサーバとして運用している場合は意味わからないことになります。
どうにか対策をしないといけません。
Google Auth側で本番公開せずテストユーザで絞ればいいのでは?
Google Auth Platformでは「公開ステータス」があり、「テスト中」の場合だと特定のユーザのみアプリにアクセスできる、と公式では説明があります。
外部ユーザータイプと「テスト中」の公開ステータスで OAuth 同意画面が構成されている Google Cloud Platform プロジェクトには、
7 日後に期限切れとなる更新トークンが発行されます。
ただし、リクエストされた OAuth スコープが名前、メールアドレス、ユーザー プロファイル(userinfo.email, userinfo.profile, openidスコープまたはその OpenID Connect の同等物)のサブセットのみである場合は除きます。
最後の一文に注目いただきたいのですが、リクエストされたスコープがメアド、プロファイル、IDだけの場合はテストユーザの絞り込みができません。

画面上で「テストユーザの追加」と一丁前に表示されていますが
少なくともJellyfin SSOプラグインでは、ここに追加したユーザだけ認証を通す、といったことはできませんでした。
検証でテストユーザ外からログインしてみたのですが、軒並みすり抜けてJellyfinのダッシュボードアクセスできちゃって笑っちゃった。
じゃあどーすんの
AIに聞いてみました
このプラグインは Google 認証で openid と profile しか使っていません。
つまり、Google 側で「テストユーザー以外は絶対に通さない」ための強い制御にはなりません。
テストユーザーの制限は、主に未検証の敏感/制限付きスコープに対するもので、Google の基本的なサインイン用途では効き方が弱いです。
なので、Google で認証に成功した時点で、Jellyfin 側はそのユーザーを受け入れてしまいます。
さらに、このプラグインは Google から返ってきた識別情報で Jellyfin ユーザーを再取得または再作成します。
だから、Jellyfin 側でユーザーを消しても、Google 認証さえ通ればまた入ってきます。
要するに、今見えている挙動は「バグというより仕様寄り」です。
Google アカウント単位で本当に絞りたいなら、Google ではなく authentik や Keycloak みたいにロールやグループを返せる IdP に変えるのが確実です。mjd?いみねーじゃんかあああ
せっかく入れたのに無駄になってしまいました
なんとかなりませんか
なんか方法があるはず...と色々調べた結果、Oauth側でRBAC制御するのは難しいそう、なのでプラグイン側で制御する方法を取りました。
- Jellyfin に管理者でログイン
- ダッシュボード → プラグイン → マイプラグイン → SSO-Auth
- OpenID Connect のプロバイダ一覧で Google の設定を開く(Add か Edit)
- Request Additional Scopes:
email - Role Claim:
email - Roles: 許可したいGmailアドレスを追加
- ついでに DefaultUsernameClaim を email にすると、数値ユーザー名問題を回避できる
- Request Additional Scopes:
- Save 後、Jellyfin を再起動
イメージはRolesの中身を
のようにすると、一覧にないアカウントは、Google認証が成功してもプラグイン側で拒否される模様。
文字列は完全一致比較っぽい
動作確認 ver2
Roleに追加していないアカウントで、Google認証後に拒否されるかを確認します。

わかりづらいですが、ブラウザの表示です。
うまくいったみたいですね。やったぜ!!!
ちなみに、Roleに追加したGoogleアカウントであれば、正常にアクセス可能で、ユーザIDもメールアドレスで登録されるようになります。
ログインフォームの最終調整
ここまでいければネイティブ認証の入口は塞いでも問題ないと思うので、SSO認証とクイックコネクトの二種類だけに絞りました。
カスタムCSSを調整して、最終的に以下のような画面になっています。

クイックコネクトはアプリ経由のログイン用に残しています。
ブラウザからのアクセスは基本Googleで使える、といった感じですん。
問題点
ここまでやって安心、かと思いきやそうでもないです。
- ネイティブ認証はJellyfinのcoreで塞いだわけではなく、カスタムCSSで隠しているだけなので、APIとかURLでcurl叩かれたらログインできると思われる
- ブレークグラスが用意されていない(パスワードを忘れたボタンも消した)
- Googleアカウントの許可ユーザの追加・更新・削除がちょっとだけ面倒(アプリの再起動あり)
という様な問題もあります。
まぁ、個人でほそぼそと管理しているサーバで、なんかあってもいいと思っているので、このままにしてます。
パッケージの最新化、強固なパスワード、海外アクセス制御などもやっているので、今回の秘匿化でも十分でしょう。きっと。
おわり
この前、AWS Summit Japan 2026に行ってきたのでAI関連の記事でも書こうと思ったのですが
ネタが思い浮かばなかったので、低俗的な記事になりました。
ってかこの記事AI使わずに手で書いてるけど、時間もかかるし頭も使うし大変だねこりゃ。
私もいつの間にかドパガキになってしまったようだぁ