SSD Nodes Learn 🎉 VPS $5.50/月〜
ガイド Matt Connor著者 Matt Connor

セルフホストソフトのSSOが有料になる理由と導入前チェック

無料のセルフホスト型アプリでもOIDCやSAMLが有料プラン限定になる理由を解説します。IdP連携、SCIM、監査ログ、サポート費用を導入前に確認できます。

SSO の追加コストとは

セルフホスト型ソフトウェアにおける SSO の追加コストとは、アプリケーション本体は無料で、シングルサインオン（SSO）だけが購入必須の機能になっている構成です。ライセンスキーもユーザー数の上限もなく、すべてを自分の VPS で運用できます。しかし、ドキュメントの認証に関するページを開くと、OpenID Connect（OIDC）や SAML（security assertion markup language）が有料プランに含まれていることがあります。

これは通常の有料機能より重要な問題です。SSO によって、複数のセルフホストサービスを 1 つのシステムのように運用できるためです。identity provider（IdP）を使うと、ユーザーごとに 1 つのアカウントを用意し、パスワードポリシーを 1 か所で管理し、multi-factor authentication（MFA）を 1 か所で有効化し、ユーザーのアクセスを 1 か所で停止できます。SSO がなければ、各アプリが独自の小さなユーザーデータベースを持つことになり、それぞれを手作業で管理する必要があります。

この慣行は、公開された一覧が存在するほど以前からあります。sso.tax の SSO Wall of Shame には、シングルサインオンに高額な追加料金を請求するベンダーが掲載されています。2018 年からの記録があり、作成者は「SSO の提供による値上げが 10% なら、この一覧には掲載しない」という基準を示しています。この一覧の大半はクローズドソフトウェアです。同じ料金体系が、現在では自分でホストするオープンソースプロジェクトにも現れています。

有料プランにシングルサインオンを含める理由

理由は2つあり、どちらも正当です。SSOのサポートにはコストがかかります。また、大規模な組織が費用を払う数少ない機能の1つでもあります。

サポートコストが現実に発生するのは、IdPとの統合に完了がないためです。IdPごとにクレームの形式が少しずつ異なります。グループマッピング、セッションの有効期間、リダイレクト URL、クロックスキューは、それぞれログイン障害の原因になります。ログイン障害が発生すると全ユーザーが一度に締め出されるため、これらの問い合わせは緊急対応になります。さらに、ネストされたグループ、ロールマッピング、SCIM（system for cross-domain identity management）による自動プロビジョニング、コンプライアンスチームが確認する監査ログなどの追加要望も発生します。

収益面の理由は悪意ではなく、単純な計算です。自社のIdPにアプリを接続できない企業は、そのアプリを導入しません。そのため、SSOは料金を支払うユーザーと支払わないユーザーを明確に分ける機能になります。オープンコアのプロジェクトでは、その境界をどこかに設ける必要があります。SSOは、ほかのほとんどの機能よりもその境界に適しているため、多くのプロジェクトが採用しています。

よくある批判について、1点訂正します。機能が削除されたと判断する前に変更履歴を確認してください。削除であれば、リリースノートに記載されるためです。この投稿のために確認したプロジェクトでは、有料のSSO機能は最初から有料プラン向けに実装されていました。動作していた無料のSSOが後から削除された例は見つかりませんでした。Grafanaが典型的な例です。GrafanaのSAMLページには、「Grafana Enterprise and Grafana Cloudで利用可能です」という1行の注記があります。一方、独自のissuerに対する汎用的なOAuthは、オープンソース版で利用できます。

SSO の負担で実際に発生するコスト

金銭的なコストは、負担全体の半分にも達しません。有料プランはユーザー単位で課金されるため、チームの拡大に伴って料金も増えます。一方、ホスティングとアップグレードは自分で管理する必要があります。

より大きなコストは、ID 管理を手作業で行うことです。主に次の 4 つの問題が発生します。

  • アプリごとにパスワードを保存する必要があり、1 つのパスワードを使い回すと、そのパスワードを共有するすべてのアプリに侵入口が生じます。
  • 退職者のアクセスを記憶だけで削除します。本人が利用したすべてのサービスを思い出す必要があり、削除を忘れたサービスが重大な問題になります。
  • MFA をアプリごとに設定します。そもそも MFA に対応しているアプリでなければ設定できません。
  • 共有ログインを使うようになります。小規模なチームでは、この負担がかかると実際にこの運用になりがちです。

最後の点は、独立した問題として扱う必要があります。チームが document manager で 1 つの administrator アカウントを共有すると、監査証跡にはすべての操作が 1 人の名前で記録されます。そのため、誰が請求書を削除したのか確認できません。ユーザーが 1 人しかいないため、ユーザー単位の権限も機能しなくなります。これが SSO の負担による実際の被害です。小規模なチームを 1 つの共有アカウントへ向かわせるため、ほかの選択肢より悪い結果になります。

導入前に実施するチェックリスト

アプリが 400 件のドキュメントを保持するようになってからではなく、docker compose up の前にこの確認を実施します。

  1. ドキュメントの認証ページを開き、最上部にあるプランに関する注記を読みます。有料機能にはバッジまたは利用可能であることを示す 1 行の説明があります。
  2. アプリが固定された公開プロバイダー一覧ではなく、自分の issuer に対して OIDC または SAML で接続できることを確認します。
  3. ロールとグループのマッピングを確認します。ユーザーの作成は作業の半分にすぎません。残りの半分は権限の割り当てであり、10 個のアプリで手作業を行うと大きな負担になります。
  4. アプリが、信頼できるプロキシからヘッダーで渡された認証済みユーザー名を受け入れるか確認します。また、信頼するプロキシを固定できるかも確認します。
  5. git のライセンス履歴を読み、コントリビューターが CLA（contributor licence agreement）に署名する必要があるか確認します。
  6. オフボーディングを確認します。IdP アカウントを無効化したとき、API（application programming interface）トークンと有効なセッションがどうなるかを調べます。

最も失望しやすいのは項目 2 です。「Sign in with Google」ボタンは、自分の identity provider に対する OIDC ではありません。1 社のベンダーと固定的に連携する機能です。実際に対応している場合は issuer URL の入力を求められ、その他の情報はすべて discovery から取得されます。次の 1 コマンドで、プロバイダー側の設定を確認できます。

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

正常なプロバイダーからは 3 つの URL が返ります。結果が空、または 404 の場合は、通常 discovery パスが誤っています。このパスはプロバイダーごとに異なり、Keycloak では /realms/<realm>/.well-known/openid-configuration に公開されます。アプリに issuer URL の入力欄がまったくない場合、機能一覧に何と書かれていても、そのアプリは IdP と通信できません。

項目 6 は、誰かが退職してから数週間後に問題になります。IdP でアカウントを無効化すると、新しいログインは停止します。ただし、アプリが以前に発行した API トークンは失効しません。アプリはそのトークンを自分で検証し、IdP に確認しないためです。したがって、オフボーディングには 2 つの手順があります。まず IdP でアカウントを無効化し、次に各アプリ内でユーザーまたはそのトークンを削除します。

What the tier badges actually say

These are checked against each project's own documentation in August 2026. Start with the paid side.

Grafana publishes SAML as "Available in Grafana Enterprise and Grafana Cloud", along with team sync and SCIM provisioning. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) and the auth proxy are all in the open source build, so a small self-hoster can still log in through their own provider. The paid line falls at SAML rather than at single sign-on as a whole, which is the nuance the phrase "SSO tax" tends to flatten.

Metabase is blunter. Its documentation says, "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." The open source edition keeps password login and LDAP.

Passbolt marks its SSO documentation Pro and Cloud, so the community edition does not have it. The documented providers include Keycloak and Entra ID.

Now the other side, because this pattern is far from universal.

  • GitLab Self-Managed carries "Tier: Free, Premium, Ultimate" on its SAML page, so SAML against your own GitLab costs nothing.
  • Paperless-ngx configures OIDC through django-allauth with PAPERLESS_SOCIALACCOUNT_PROVIDERS, hides the local login form with PAPERLESS_DISABLE_REGULAR_LOGIN, and maps claims onto groups with PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
  • Planka takes OIDC_ISSUER, OIDC_CLIENT_ID and OIDC_CLIENT_SECRET, defaults its scopes to openid profile email, and promotes administrators from a role claim with OIDC_ADMIN_ROLES.
  • BookStack switches over with AUTH_METHOD=oidc, then maps provider groups onto its own roles with OIDC_USER_TO_GROUPS=true and OIDC_GROUPS_CLAIM.
  • Vaultwarden shipped "support for SSO with OpenID Connect" in 1.35.0 on 27 December 2025, from a pull request by a contributor who had carried the feature in a fork.
  • listmonk has had OIDC login alongside its user roles since v4.0.0.

Use that when you are choosing rather than after you have committed. A Planka kanban board and the other self-hosted Trello alternatives do not all treat identity the same way, and neither do BookStack, Wiki.js and Outline. Free OIDC is a feature you can weigh like storage limits or mobile clients. If you are still drawing up the list, what to self-host in 2026 is a reasonable starting point, and both the Paperless-ngx document manager and Vaultwarden give you free OIDC today.

アプリの前段にリバースプロキシを置いてもシングルサインオンにはならない理由

一般的な回避策は forward auth です。リバースプロキシが各リクエストを保留し、認証サービスにそのブラウザーがサインイン済みかどうかを問い合わせます。認証済みの場合に限り、リクエストをアプリへ渡します。authentik ではこれを proxy provider と呼び、単一のアプリケーション向けの forward auth モードと、ドメイン全体向けのモードを用意しています。Authelia と oauth2-proxy も同じ役割を果たします。

Caddy のサイトブロックは、authentik 公式の例に従うと次のようになります。

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

Caddy では、これらのヘッダー名の大文字・小文字が重要です。名前が一致しないと、空の値として到着するためです。承認したすべてのリクエストで、outpost は X-authentik-username、X-authentik-email、X-authentik-groups などを設定します。

これにより得られる効果は明確です。誰も、最初に ID プロバイダーを通過せずにアプリへ到達できません。そのため、未修正のログインフォームをインターネットに公開せずに済み、プロキシの背後にあるすべての機能に MFA を一括して適用できます。

ただし、アプリ内のアイデンティティが得られるわけではありません。アプリには独自のアカウントがあり、誰がサインインしているかも独自に判断します。全員がプロキシを通過し、1 つの共有管理者アカウントに到達する構成では、入口だけが強固で、その背後には匿名の 1 セッションがある状態です。監査ログにも 1 つの名前しか記録されません。利用者ごとに権限を分けることもできません。この構成を SSO と呼ぶのはセキュリティ上の誤りです。オフボーディングも完全ではないためです。IdP から利用者を削除すれば入口は閉じられますが、その利用者がアプリ内で作成した API token は、アプリへ直接到達できる人なら引き続き使用できます。

ヘッダー認証を安全にする

プロキシからユーザー名を受け取れるアプリもあります。これにより、有料の SSO なしでユーザー単位の識別情報を利用できます。設定名はプロジェクトごとに異なります。

Grafana では auth proxy と呼ばれ、初期状態では無効です。ヘッダー名の初期値は X-WEBAUTH-USER で、プロキシが設定する任意のヘッダーを指定できます。

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist は見落とされやすい設定です。Grafana のドキュメントでは、ユーザーによるヘッダー偽装を防ぐための設定だと明記されています。そのため、ここにはプロキシのアドレスだけを指定してください。Gitea にも同じ機能がありますが、設定名が異なり、より安全な初期値が設定されています。

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES の初期値は 127.0.0.0/8,::1/128 です。REVERSE_PROXY_LIMIT は、Gitea がチェーン内で信頼するプロキシの数です。この上限を 0 にすると、ヘッダー処理が完全に無効になります。

Paperless-ngx には PAPERLESS_ENABLE_HTTP_REMOTE_USER があり、PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME と組み合わせて使用します。ドキュメントには、これらの設定すべてに当てはまる次の警告が記載されています。

リクエストに Remote-User: <username> ヘッダーを追加するだけで認証できるようになります。慎重に使用してください。

ヘッダー認証を安全にするには、到達可能性に関する 2 つのルールを守ります。1 つ目は、アプリへはプロキシ経由でしか到達できないようにすることです。アプリへソケット接続できるユーザーは、そのヘッダーを送信して任意のユーザーになりすませるためです。Docker では、ports: ["8000:8000"] によりすべてのインターフェイスで公開されます。そのため、ports: ["127.0.0.1:8000:8000"] で loopback アドレスにバインドするか、公開ポートを削除してプロキシを同じ Docker ネットワークに配置してください。2 つ目は、プロキシがクライアントから届いたヘッダーをすべて削除することです。これにより、アプリが受け取る値は、認証後にプロキシが設定した値だけになります。

両方を確認してください。最初のコマンドは VPS の外部にあるマシンから実行し、2 つ目のコマンドはサーバー自体で実行します。

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

curl は接続に失敗するはずです。また、ss は 0.0.0.0:8000 ではなく 127.0.0.1:8000 を出力するはずです。最初の行が HTTP/1.1 302 Found の場合、アプリはパブリックインターネットから直接応答しています。その場合、ヘッダーでユーザー名を指定するだけで、誰でも任意のユーザーとしてサインインできます。

無料の SSO がない場合は、文句を言うのではなく判断する

私なら、次の順番で4つの選択肢を検討します。

  1. OIDC を含むアプリを選びます。同じ用途のプロジェクトが2つあり、一方が無料で ID プロバイダーと連携できるなら、それは実際の運用コストに関わる違いです。
  2. forward auth を正しく使います。アカウントが1つで運用担当者も1人の管理ツールなら、前段のプロキシだけで十分です。アプリ内でユーザー単位の ID を管理しても、得られるものはありません。
  3. 支払います。アプリが業務の中心で、ユーザー単位の料金がチームの規模に合うなら、その費用でプロジェクトの保守が続きます。代替手段を自分の夜間に実装するよりも現実的です。
  4. issue tracker を調べてから、upstream に要望を出します。Vaultwarden の OIDC サポートは、コントリビューターの fork と長期間継続した pull request を通じて追加されました。そのため、動作する実装を伴う機能要望が無料版に取り込まれることもあります。

自分で用意した ID プロバイダーがなければ、これらはどれも機能しません。まず構築すべきなのはその部分です。VPS で authentik を運用するでは、OIDC および SAML プロバイダーと、前述の forward auth outpost を用意する方法を説明します。まだ導入を決めたくない場合は、Keycloak、authentik、Zitadel の比較で各選択肢のトレードオフを確認できます。

ライセンスの履歴と、チェックリストに含める理由

最後のチェックリスト項目は将来に関するものです。現在のライセンス構成は、あくまで現時点の状態にすぎないためです。状況が両方向に急速に変化することを示す、十分に文書化された事例が2つあります。HashiCorp は2023年8月10日、今後のすべてのリリースに Business Source License 1.1 を採用しました。一方、それ以前のリリースは MPL 2.0 (Mozilla Public License) のままです。Redis は2024年3月に SSPL (server side public license) へ移行し、その後2025年5月1日に、Redis 8 は AGPLv3 (GNU Affero General Public License) でも提供されると発表しました。

いずれも、動機ではなく仕組みの例として捉えてください。今日確認したライセンスが適用されるのは、今日インストールするバージョンです。また、プロジェクトが著作権をすべて保有していれば、次のリリースからライセンス条件を単独で変更できます。そのため、CLA に関する質問をチェックリストに含めています。広範な著作権の譲渡が、一方的なライセンス変更を可能にするためです。

プロジェクトを基盤として利用する前に、その履歴を自分で確認してください。

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

コミットの数が少なく、その大半が最初のインポート時のものであれば、良い兆候です。ライセンスファイルが何度も書き換えられている場合は、現在の条件を前提に計画する前に、各コミットメッセージを確認してください。

FAQ

SSO 税とは何ですか？

SSO 税とは、製品の他の機能を無料または安価で提供しながら、シングルサインオンをプレミアム機能として課金する慣行です。セルフホスト型ソフトウェアでは、ライセンスキーなしで実行できるオープンソースアプリケーションでありながら、OIDC または SAML によるログインが有料プランに含まれる形で現れます。この名称は、SSO に高額な追加料金を課すベンダーを追跡している sso.tax の SSO Wall of Shame に由来します。セルフホストするユーザーにとっての問題は、各アプリが独自のユーザーデータベースを持ち続けるため、アカウントの作成と削除を手作業で行う必要があることです。

Forward auth を使うリバースプロキシは SSO と同じですか？

いいえ。Forward auth は入口を保護します。プロキシがアイデンティティプロバイダーに確認してから、リクエストをアプリへ転送します。背後のアプリは独自のアカウントを引き続き使用するため、全員が 1 つの共有ログインに到達する構成では、匿名のセッションが 1 つ作られ、監査ログにも 1 つの名前しか記録されません。アプリがヘッダーからユーザー名を読み取る場合に限り、ユーザー単位の識別が実現します。Grafana の auth proxy、Gitea の reverse proxy authentication、Paperless-ngx の PAPERLESS_ENABLE_HTTP_REMOTE_USER はこの方式に対応しています。これらの設定を安全に使用できるのは、アプリへプロキシを経由せずにアクセスできない場合だけです。ヘッダーは単なる文字列であり、どのクライアントでも送信できるためです。

無料版に OIDC を含むセルフホスト型アプリはどれですか？

2026 年 8 月に各プロジェクトのドキュメントで確認した範囲では、Paperless-ngx、Planka、BookStack、Gitea、listmonk、Vaultwarden はすべて無料ビルドで OIDC に対応しています。また、GitLab Self-Managed では SAML が Tier: Free に含まれています。Grafana のオープンソースビルドは独自の issuer に対する汎用 OAuth を処理できますが、SAML は Enterprise 機能です。リリースによって一覧は変わるため、インストール前に各プロジェクトの認証ページで確認してください。

シングルサインオンが有効になるプランに料金を支払うべきですか？

次の 2 つの数字で判断してください。アカウントを必要とする人数と、そうでなければ手作業で管理するアプリの数です。管理者が 1 人または 2 人だけなら、ローカルアカウントの前段に Forward auth を置けば十分であり、有料プランの利点はほとんどありません。人の参加と離脱があるチームでは、退職・異動時に 1 つのアカウントを削除し忘れるコストがライセンス料金を上回る可能性があります。その料金は、利用している保守を支えるものでもあります。価格が合わない場合は、対応していないアプリを回避策で運用するより、OIDC を含むアプリを選ぶのが現実的です。

#sso#oidc#saml#licensing#self-hosting#authentik