ホームでのシングルサインオンの設定

Created 2025-01-15 Updated 2025-10-18

なぜホームで SSO を使うのか？
SSO の基礎を理解する
セルフホスト vs 外部アイデンティティプロバイダー
SSO ソリューションの選択
Authelia のセットアップ
多要素認証の追加
SSO 有効化後もローカルアカウントを保持すべきか？
結論
Authentik のセットアップ
アプリケーションの統合
ユーザー管理
高度：LDAP 統合
セキュリティのベストプラクティス
トラブルシューティング
監視とメンテナンス
比較：SSO ソリューション
リソース

あなたは印象的なホームラボを構築しました——Nextcloud、Jellyfin、Home Assistant、Portainer、Grafana、そして他の十数個のサービス。それぞれが素晴らしいです。しかし、それぞれに独自のログインページがあります。そして独自のパスワード。そして独自のセッションタイムアウト。

聞き覚えがありますか？パスワード疲労の世界へようこそ。

一度ログインするだけですべてにアクセスできたらどうでしょうか？それがシングルサインオン（SSO）であり、もはや企業専用ではありません。

なぜホームで SSO を使うのか？

問題：

15+ のサービス = 15+ の覚えるべきパスワード（または再利用 😱）
各サービスに個別にログインすると時間の無駄
集中型ユーザー管理がない
必要なときにアクセスを取り消すのが困難
パスワードリセットは悪夢

解決策：

SSO が提供するもの：

1回のログインですべてのサービスにアクセス
集中型認証 - 1か所でユーザーを管理
より良いセキュリティ - MFA を一度強制すれば、どこでも適用される
簡単なオンボーディング - 家族/友人を一度にすべてのサービスに追加
迅速な取り消し - 1つのアカウントを無効にすれば、どこでもロックアウト

SSO の基礎を理解する

シングルサインオンとは？

SSO は、ユーザーが一度ログインして、再認証なしで複数のアプリケーションにアクセスできる認証スキームです。

簡単な例：

SSO なし：Nextcloud にログイン → Grafana にログイン → Jellyfin にログイン（3回のログイン）
SSO あり：一度ログイン → 3つのサービスすべてにアクセス（1回のログイン）

主要コンポーネントの説明

SSO を複数の VIP ルームがあるナイトクラブのように考えてください。各コンポーネントを分解してみましょう：

1. アイデンティティプロバイダー（IdP）- 用心棒

**役割：**あなたが誰であるかを検証する中央認証機関。

**現実世界のアナロジー：**ナイトクラブの入口で ID をチェックし、リストバンドを渡す用心棒のようなもの。

あなたのホームラボでは：

Authelia、Authentik、または Keycloak が用心棒として機能
任意のサービスにアクセスしようとすると、まずここにリダイレクトされます
ユーザー名/パスワードと MFA をチェック
検証されると、「トークン」（リストバンドのようなもの）が与えられます

フロー例：

あなた → Nextcloud にアクセスしようとする
Nextcloud → 「あなたを知りません、用心棒に聞いてください」
あなた → Authelia ログインページにリダイレクト
Authelia → 「認証情報を見せてください」
あなた → パスワード + MFA コードを入力
Authelia → 「検証済み！これがあなたのトークンです」

2. サービスプロバイダー（SP）- VIP ルーム

**役割：**IdP を信頼してユーザーを認証する実際のアプリケーション。

**現実世界のアナロジー：**ナイトクラブの VIP ルームのようなもの。ID はチェックせず、用心棒からのリストバンドだけを見ます。

あなたのホームラボでは：

**あなたのアプリ：**Nextcloud、Grafana、Jellyfin、Home Assistant
パスワードを自分で処理しない
IdP の決定を信頼
「Authelia からの有効なトークンを持っていますか？」とだけチェック

例：

あなた → Grafana にアクセス（Authelia からのトークン付き）
Grafana → 「Authelia からの有効なトークンを持っていますね」
Grafana → 「Authelia によると、あなたは 'admins' グループの 'alice' です」
Grafana → 「ようこそ！」

3. ユーザーディレクトリ - ゲストリスト

**役割：**ユーザー情報（ユーザー名、パスワード、グループ）を保存。

**現実世界のアナロジー：**用心棒がチェックするゲストリスト。

あなたのホームラボでは：

**シンプル：**ユーザー名とハッシュ化されたパスワードを含む YAML ファイル
**高度：**LDAP サーバー（ユーザーのデータベースのようなもの）
含まれるもの：ユーザー名、パスワード、メール、グループメンバーシップ

構造例：

users:
  alice:
    password: (hashed)
    email: alice@home.local
    groups: [admins, users]
  bob:
    password: (hashed)
    email: bob@home.local
    groups: [users]

4. 認証 vs 認可

**認証：**あなたが誰であるかを証明する（「あなたは Alice ですか？」）
**認可：**あなたが何ができるかを決定する（「Alice は管理パネルにアクセスできますか？」）

現実世界のアナロジー：

認証 = 21歳以上であることを証明するために ID を提示する
認可 = 用心棒が VIP セクションに入れるかどうかを決定する

SSO では：

IdP が認証を処理：「はい、これは正しいパスワードを持つ Alice です」
アプリが認可を処理：「Alice は ‘admins’ グループにいるので、管理者アクセスを許可します」

5. 認証プロトコル - 言語

**役割：**IdP とアプリが通信するための標準化された方法。

**現実世界のアナロジー：**用心棒と VIP ルームが通信するために使用する異なる言語のようなもの。

OIDC（OpenID Connect）- モダンで推奨：

認証：「あなたは誰ですか？」
認可：「どのグループに所属していますか？」
JSON を使用（読みやすい）
OAuth2 上に構築
ほとんどのモダンなアプリがサポート
可能な限りこれを使用

OIDC トークンの例：

{
  "sub": "alice",
  "email": "alice@homelab.local",
  "groups": ["admins", "users"],
  "exp": 1705334400
}

SAML - エンタープライズ標準：

正式な法律用語を話すようなもの
XML を使用（冗長）
古いエンタープライズアプリが使用
より複雑だが広くサポートされている
企業環境で一般的

Windows 統合認証（WIA）- Windows のみ：

Kerberos/NTLM を使用
Windows ドメインユーザーの自動ログイン
ドメイン上であればパスワードプロンプトなし
**以下でのみ動作：**Active Directory + Windows クライアント
フェデレーションではない - 外部 SaaS アプリと統合できない
ホームラボには不適切、Windows Server ドメインを実行している場合を除く

6. フェデレーション vs 非フェデレーション認証

フェデレーションとは？

フェデレーションは、異なる組織/システムが互いの認証を信頼できるようにします。

現実世界のアナロジー：

**非フェデレーション：**ジムの会員資格は自分のジムでのみ有効
**フェデレーション：**パスポートは複数の国で有効（互いに信頼している）

非フェデレーション認証（WIA、基本認証）：

あなたのホームラボ IdP → ホームラボサービスでのみ動作
❌ 外部 SaaS（GitHub、AWS など）に認証できない

フェデレーション認証（OIDC、SAML）：

あなたのホームラボ IdP ↔ 外部 SaaS（サポートしている場合）
✅ あなたの IdP を信頼するサービスに認証できる

シナリオ例：

非フェデレーション（WIA）：

あなた → Windows ドメインコントローラー → ホームラボアプリ ✅
あなた → Windows ドメインコントローラー → GitHub ❌（GitHub はあなたの DC を信頼しない）

フェデレーション（OIDC/SAML）：

あなた → Authentik → ホームラボアプリ ✅
あなた → Authentik → GitHub Enterprise ✅（設定されている場合）
あなた → Authentik → AWS ✅（設定されている場合）

ホームラボの落とし穴：

ほとんどの SaaS プロバイダーはエンタープライズサブスクリプションでのみフェデレーションをサポート：

サービス	無料/個人	エンタープライズ
GitHub	SSO なし	SAML による SSO
AWS	SSO なし	SAML による SSO
Google Workspace	SSO なし	SAML による SSO
Microsoft 365	SSO なし	SAML による SSO
Slack	SSO なし	SAML による SSO

コストの現実：

GitHub Enterprise：$21/ユーザー/月
AWS SSO：AWS Organizations が必要
Google Workspace：$12-18/ユーザー/月（SSO 用）
Microsoft 365：$22/ユーザー/月（SSO 用）

⚠️ ホームラボ SSO の制限

あなたのホームラボ SSO が動作するもの：

✅ セルフホストサービス（Nextcloud、Grafana、Jellyfin）
✅ あなたが管理するサービス
✅ 制限なしで OIDC/SAML をサポートするアプリ

あなたのホームラボ SSO が動作しないもの：

❌ 無料ティア SaaS（GitHub、Gmail、Slack）
❌ エンタープライズサブスクリプションが必要なサービス
❌ カスタム IdP をサポートしないサービス

これによりホームラボ SSO は内部サービスのみに制限されますが、10-20 のセルフホストアプリを管理するには依然として価値があります！

比較：

プロトコル	最適な用途	複雑さ	フェデレーション	ホームラボフレンドリー
OIDC	モダンアプリ	低	✅ はい	✅ はい
SAML	エンタープライズアプリ	高	✅ はい	⚠️ 必要な場合
WIA	Windows ドメイン	中	❌ いいえ	❌ 過剰

💡 プロトコルの選択

ホームラボの場合：

OIDC を使用 サポートするアプリ用（Grafana、Nextcloud、Portainer）
フォワード認証を使用（Authelia）OIDC サポートのないアプリ用
WIA をスキップ すでに Active Directory を実行している場合を除く（そして SaaS では動作しない）
SAML を使用 特定のアプリが必要とする場合のみ
**制限を受け入れる：**あなたの SSO は無料ティア SaaS（GitHub、Gmail など）では動作しない

視覚的比較：

すべてをまとめる

SSO なし（現在の状態）：

あなた → Nextcloud → Nextcloud のパスワードを入力
あなた → Grafana → Grafana のパスワードを入力
あなた → Jellyfin → Jellyfin のパスワードを入力
（15 のサービス = 15 のパスワード！）

SSO あり（設定後）：

あなた → Nextcloud → Authelia にリダイレクト → 一度ログイン
あなた → Grafana → すでにログイン済み（トークンが存在）
あなた → Jellyfin → すでにログイン済み（トークンが存在）
（1回のログイン = すべてにアクセス！）

**魔法：**Authelia にログインすると、セッションが作成されます。すべてのアプリが Authelia に確認します：「このユーザーはログインしていますか？」Authelia が「はい！」と答え、アクセスを許可します。

🎯 重要なポイント

IdP（Authelia） = ログインする唯一の場所
サービスプロバイダー（あなたのアプリ） = IdP の決定を信頼
ユーザーディレクトリ = ユーザー名/パスワードが保存される場所
プロトコル（OIDC/SAML） = 互いに通信する方法

IdP で一度ログインすれば、すべてのアプリがそのログインを信頼します。

セルフホスト vs 外部アイデンティティプロバイダー

セルフホストソリューションに飛び込む前に、「なぜ Google、Microsoft、または GitHub を IdP として使わないのか？」と疑問に思うかもしれません。

外部 IdP（Google、Microsoft、GitHub、Auth0）

長所：

メンテナンス不要
すでにアカウントを持っている
エンタープライズグレードのセキュリティ
個人使用は無料
組み込み MFA
SaaS とフェデレーション可能（エンタープライズサブスクリプションがある場合）

短所：

プライバシーの懸念 - 外部プロバイダーがホームラボへのすべてのログインを見る
インターネット依存 - インターネットがダウンすると認証できない
サービス停止 - サービスがダウンするとホームラボが壊れる
アカウントリンク - 外部アカウントなしでユーザーを追加できない
利用規約 - 彼らのルールと変更に従う
データ主権 - 認証データがネットワークを離れる
エコシステムに制限 - Google SSO を Microsoft サービスに使用できない

セルフホスト IdP（Authelia、Authentik、Keycloak）

長所：

完全なプライバシー - 外部追跡なし
オフラインで動作 - インターネット停止がローカルサービスに影響しない
完全な制御 - あなたのルール、あなたのユーザー
カスタムユーザー - Google アカウントを必要とせずに家族/友人を追加
ベンダーロックインなし - 認証インフラストラクチャを所有
学習機会 - SSO の仕組みを理解
フェデレーションプロトコル - OIDC/SAML を使用（標準プロトコル）

短所：

セットアップとメンテナンスが必要
セキュリティに責任を持つ
バックアップを管理する必要がある
「Google でログイン」ボタンより複雑
SaaS 統合が制限される - ほとんどの SaaS は高価なエンタープライズプランが必要

ハイブリッドアプローチ

両方の長所を活かす：

# Authentik は外部 IdP をソースとして使用可能
# ユーザーは選択できる：ローカルアカウント OR Google OR GitHub

ユースケース：

セルフホストをプライマリ + 外部をバックアップ
家族用のローカルアカウント + ゲスト用の外部
機密サービス用のセルフホスト + 低リスクアプリ用の外部

💡 外部 IdP を使用するタイミング

外部 IdP を使用する場合：

Google/Microsoft にログインアクティビティを見られても構わない
ホームラボが常にインターネットに接続されている
自分だけの認証が必要
メンテナンス不要を望む
エンタープライズサブスクリプションがあり、SaaS と統合したい

セルフホストを使用する場合：

プライバシーが重要（外部追跡なし）
オフライン機能が必要
複数のユーザー（家族/友人）を管理する必要がある
インフラストラクチャを学び、制御したい
外部プロバイダーに公開すべきでないサービスがある
セルフホストサービスのみに SSO が必要（一般的なホームラボのケース）

実世界の例：

シナリオ 1 - ISP 停止：
外部 IdP では、ローカルの Home Assistant にログインしてセキュリティカメラをチェックできません。セルフホスト SSO では、ローカルネットワーク上ですべてが動作します。

シナリオ 2 - SaaS 統合：
ホームラボ SSO を GitHub に使用したい。GitHub はカスタム SAML IdP を受け入れるために Enterprise（$21/ユーザー/月）が必要です。ホームラボには高すぎるため、代わりに GitHub 自身の認証を使用します。

SSO ソリューションの選択

オプション 1：Authelia（軽量、プロキシベース）

**最適な用途：**シンプルなセットアップ、リバースプロキシユーザー

長所：

軽量（単一バイナリ）
任意のリバースプロキシで動作（Traefik、nginx）
シンプルな YAML 設定
組み込み LDAP/ファイルベース認証
優れたドキュメント

短所：

限定的な OIDC サポート（基本）
管理 UI なし（設定ファイルのみ）
Authentik より統合が少ない

オプション 2：Authentik（フル機能、モダン）

**最適な用途：**複雑なセットアップ、複数のプロトコルが必要

長所：

美しい管理 UI
完全な OIDC および SAML サポート
組み込みユーザー管理
カスタマイズ可能なログインフロー
活発な開発

短所：

より重いリソース使用
より複雑なセットアップ
PostgreSQL/Redis が必要

オプション 3：Keycloak（エンタープライズグレード）

**最適な用途：**大規模ホームラボ、エンタープライズ機能

長所：

業界標準
包括的な機能
優れた SAML/OIDC サポート
ユーザーフェデレーション

短所：

重いリソース使用（Java ベース）
複雑な設定
小規模ホームラボには過剰

比較表

機能	Authelia	Authentik	Keycloak
リソース使用	低	中	高
セットアップの複雑さ	低	中	高
OIDC サポート	基本	完全	完全
SAML サポート	❌ なし	✅ あり	✅ あり
管理 UI	❌ なし	✅ あり	✅ あり
MFA	✅ TOTP、WebAuthn	✅ TOTP、WebAuthn、Passkey	✅ すべてのタイプ
最適な用途	小規模ラボ	中規模ラボ	エンタープライズ

💡 推奨

Traefik/nginx を使用していてシンプルさを求めるなら Authelia から始める
OIDC/SAML と UI が必要なら Authentik を選択
エンタープライズ機能が必要か、すでに知っている場合のみ Keycloak を使用

Authelia のセットアップ

アーキテクチャ

flowchart TD User["👤 ユーザー"] Proxy["🚪 リバースプロキシ (Traefik/nginx)"] Authelia["🔐 Authelia"] LDAP["📚 ユーザーディレクトリ (YAML/LDAP)"] subgraph Services[" "] App1["📦 Nextcloud"] App2["🎬 Jellyfin"] App3["📊 Grafana"] end User --> Proxy Proxy --> Authelia Proxy --> Services Authelia -.-> LDAP style Authelia fill:#e3f2fd style Proxy fill:#fff3e0 style LDAP fill:#f3e5f5 style Services fill:#e8f5e9

前提条件

Docker と Docker Compose
リバースプロキシ（Traefik または nginx）
ドメイン名（またはローカル DNS）

ステップ 1：ディレクトリ構造の作成

mkdir -p authelia/{config,secrets}
cd authelia

ステップ 2：シークレットの生成

# JWT シークレット
tr -cd '[:alnum:]' < /dev/urandom | fold -w "64" | head -n 1 > secrets/jwt_secret

# セッションシークレット
tr -cd '[:alnum:]' < /dev/urandom | fold -w "64" | head -n 1 > secrets/session_secret

# ストレージ暗号化キー
tr -cd '[:alnum:]' < /dev/urandom | fold -w "64" | head -n 1 > secrets/storage_encryption_key

ステップ 3：設定の作成

# config/configuration.yml
---
theme: dark
default_2fa_method: "totp"

server:
  host: 0.0.0.0
  port: 9091

log:
  level: info

totp:
  issuer: homelab.local
  period: 30
  skew: 1

authentication_backend:
  file:
    path: /config/users_database.yml
    password:
      algorithm: argon2id
      iterations: 1
      salt_length: 16
      parallelism: 8
      memory: 64

access_control:
  default_policy: deny
  rules:
    - domain: "*.homelab.local"
      policy: two_factor

session:
  name: authelia_session
  domain: homelab.local
  expiration: 1h
  inactivity: 5m
  remember_me_duration: 1M

regulation:
  max_retries: 3
  find_time: 2m
  ban_time: 5m

storage:
  encryption_key_secret_file: /secrets/storage_encryption_key
  local:
    path: /config/db.sqlite3

notifier:
  filesystem:
    filename: /config/notification.txt

ステップ 4：ユーザーの作成

# config/users_database.yml
users:
  alice:
    displayname: "Alice Smith"
    password: "$argon2id$v=19$m=65536,t=3,p=4$..." # 生成：authelia crypto hash generate argon2 --password 'yourpassword'
    email: alice@homelab.local
    groups:
      - admins
      - users
  
  bob:
    displayname: "Bob Jones"
    password: "$argon2id$v=19$m=65536,t=3,p=4$..."
    email: bob@homelab.local
    groups:
      - users

パスワードハッシュの生成：

docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'yourpassword'

ステップ 5：Docker Compose

# docker-compose.yml
version: '3.8'

services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    volumes:
      - ./config:/config
      - ./secrets:/secrets
    ports:
      - 9091:9091
    environment:
      - TZ=America/New_York
    restart: unless-stopped

ステップ 6：Traefik との統合

# docker-compose.yml（既存の Traefik セットアップに追加）
services:
  authelia:
    image: authelia/authelia:latest
    container_name: authelia
    volumes:
      - ./authelia/config:/config
      - ./authelia/secrets:/secrets
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.authelia.rule=Host(`auth.homelab.local`)"
      - "traefik.http.routers.authelia.entrypoints=websecure"
      - "traefik.http.routers.authelia.tls=true"
      - "traefik.http.services.authelia.loadbalancer.server.port=9091"
      
      # Authelia ミドルウェア
      - "traefik.http.middlewares.authelia.forwardauth.address=http://authelia:9091/api/verify?rd=https://auth.homelab.local"
      - "traefik.http.middlewares.authelia.forwardauth.trustForwardHeader=true"
      - "traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups,Remote-Name,Remote-Email"
    restart: unless-stopped

  # 保護されたサービスの例
  nextcloud:
    image: nextcloud:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.nextcloud.rule=Host(`nextcloud.homelab.local`)"
      - "traefik.http.routers.nextcloud.entrypoints=websecure"
      - "traefik.http.routers.nextcloud.tls=true"
      - "traefik.http.routers.nextcloud.middlewares=authelia@docker"
    restart: unless-stopped

ステップ 7：サービスの起動

docker-compose up -d

https://auth.homelab.local にアクセスしてログインページを確認します。

認証フローの理解

Authelia をセットアップしたので、保護されたサービスにアクセスしたときに何が起こるかを正確に見てみましょう：

sequenceDiagram participant User as ユーザー participant App as アプリケーション (Nextcloud) participant SSO as SSO プロバイダー (Authelia) participant LDAP as ユーザーディレクトリ (YAML/LDAP) User->>App: 1. アプリケーションにアクセス App->>User: 2. SSO ログインにリダイレクト User->>SSO: 3. 認証情報 + MFA を入力 SSO->>LDAP: 4. 認証情報を検証 LDAP->>SSO: 5. ユーザー認証済み SSO->>App: 6. 認証トークンを返す App->>User: 7. アクセスを許可 Note over User,App: ユーザーがログイン済み！ User->>App: 8. 別のアプリにアクセス (Jellyfin) App->>SSO: 9. 既存のセッションをチェック SSO->>App: 10. 有効なセッションが存在 App->>User: 11. アクセスを許可（ログイン不要）

舞台裏で何が起こるか：

最初のアクセス：nextcloud.homelab.local にアクセス
**Traefik が傍受：**Authelia に確認 - 「このユーザーは認証済みですか？」
**未認証：**Authelia が auth.homelab.local にリダイレクト
**ログイン：**ユーザー名、パスワード、MFA コードを入力
**Authelia が検証：**ユーザーデータベースに対して認証情報をチェック
**セッション作成：**Authelia がセッション Cookie を作成
**リダイレクトバック：**Nextcloud に戻される
**アクセス許可：**Traefik が有効なセッションを確認し、アクセスを許可

2番目のサービスアクセス：

grafana.homelab.local にアクセス
Traefik が Authelia に確認 - 「このユーザーは認証済みですか？」
Authelia が既存のセッション Cookie を確認 - 「はい、Alice です！」
すぐにアクセス許可 - ログイン不要

これが SSO の魔法です - 一度のログインで、どこでもアクセス！

多要素認証の追加

MFA オプションの概要

方法	セキュリティ	利便性	コスト	フィッシング耐性
Passkey (WebAuthn)	最高	高	無料	✅ はい
ハードウェアキー	最高	中	$25-50	✅ はい
TOTP (認証アプリ)	高	中	無料	❌ いいえ
SMS	低	高	SMS ゲートウェイが必要	❌ いいえ

1. Passkey (WebAuthn) - 推奨

Passkey とは？

Passkey は、生体認証（指紋、顔、PIN）を使用したパスワードの現代的な代替品です。

**現実世界のアナロジー：**パスワードを入力する代わりに、指紋でスマートフォンのロックを解除するようなもの。

仕組み：

デバイスが暗号化キーを保存
生体認証（指紋/顔）またはデバイス PIN で認証
盗まれたりフィッシングされたりするパスワードがない
クラウド同期でデバイス間で動作（iCloud キーチェーン、Google パスワードマネージャー）

Authentik セットアップ：

ユーザーメニュー → 設定
MFA デバイス → 登録
WebAuthn または Passkey を選択
ブラウザのプロンプトに従う：
- **モバイル：**指紋/Face ID を使用
- **ラップトップ：**Touch ID/Windows Hello を使用
- **デスクトップ：**スマートフォンを Passkey として使用、またはハードウェアキー

Authelia セットアップ：

保護されたサービスにログイン
「セキュリティキーを登録」をクリック
Passkey オプションを選択
生体認証で認証

サポートされているプラットフォーム：

✅ iPhone/iPad (iOS 16+) - Face ID/Touch ID
✅ Android (9+) - 指紋/顔認証
✅ macOS (Ventura+) - Touch ID
✅ Windows (10+) - Windows Hello
✅ Chrome/Edge/Safari - 組み込みサポート

2. ハードウェアセキュリティキー

認証用の物理デバイス：

Authentik：

ユーザーメニュー → 設定
MFA デバイス → 登録
WebAuthn を選択
セキュリティキー（YubiKey など）を挿入
プロンプトが表示されたらキーにタッチ

人気のハードウェアキー：

YubiKey 5 ($45-50) - USB-A/C、NFC
YubiKey 5C Nano ($55) - USB-C ポートに常駐
Google Titan ($30) - USB-A/C、Bluetooth
Feitian ($20-30) - 予算オプション

3. TOTP（認証アプリ）

アプリからの時間ベースのコード：

Authelia（組み込み）：

保護されたサービスにログイン
「デバイスを登録」をクリック
認証アプリで QR コードをスキャン
6桁のコードを入力して確認

Authentik：

ユーザーメニュー → 設定
MFA デバイス → 登録
TOTP を選択
QR コードをスキャン

推奨される認証アプリ：

Aegis (Android) - オープンソース、暗号化バックアップ
Raivo OTP (iOS) - オープンソース、iCloud 同期
2FAS (iOS/Android) - 無料、クラウドバックアップ
Authy (iOS/Android) - マルチデバイス同期
Google Authenticator (iOS/Android) - シンプル、クラウドバックアップ

💡 MFA ベストプラクティス

優先順位：

Passkey - 最も安全で便利（生体認証を使用）
ハードウェアキー - 非常に安全、物理デバイスが必要
TOTP アプリ - 安全だが、フィッシングされる可能性あり
SMS を避ける - SIM スワッピングに脆弱

推奨事項：

管理者には MFA を必須に（Passkey またはハードウェアキーを使用）
家族にはオプション（摩擦を減らす、Passkey は簡単）
バックアップコード - 生成して安全に保存
複数の方法 - Passkey + TOTP をバックアップとして登録
Passkey 同期 - iCloud/Google を使用してすべてのデバイスからアクセス

SSO 有効化後もローカルアカウントを保持すべきか？

短い答え：はい、常にバックアップとしてローカルアカウントを保持してください。

なぜローカルアカウントを保持するのか？

**SSO は単一障害点です。**SSO システムがダウンすると、すべてからロックアウトされます。

SSO が失敗する実世界のシナリオ：

SSO コンテナがクラッシュ - Docker/Kubernetes の問題
データベースの破損 - Authelia/Authentik データベースの問題
設定エラー - 設定のタイプミスが認証を壊す
証明書の期限切れ - HTTPS 証明書が期限切れ、SSO に到達不可
ネットワークの問題 - DNS の問題、リバースプロキシがダウン
誤削除 - 間違ったコンテナを削除

ローカルアカウントなしの場合：

SSO ダウン → 何にもログインできない → SSO にアクセスして修正できない → ロックアウト

バックアップとしてローカルアカウントがある場合：

SSO ダウン → ローカル管理者アカウントを使用 → SSO を修正 → 通常に戻る

ローカルアカウントのベストプラクティス

🔒 重要：ローカルアカウントを保護する

ローカルアカウントは SSO をバイパスするため、保護する必要があります：

強力なパスワード - パスワードマネージャーを使用、20文字以上
ローカルアカウントで MFA を有効化 - 多くのサービスがサポート
ローカルアカウントを制限 - 管理者/緊急アクセス用のみ作成
異なるパスワード - SSO パスワードを再利用しない
認証情報を文書化 - 安全に保存（パスワードマネージャー、暗号化ファイル）

💡 ゴールデンルール

常に安全なバックドアを維持：

SSO は正面玄関（便利、安全）
ローカルアカウントは非常口（めったに使わないが、常に利用可能）
両方とも MFA で保護すべき
両方を定期的にテスト

家の外に隠しておいた予備の鍵のようなものと考えてください - めったに必要ありませんが、必要なときにそこにあることを喜ぶでしょう！

結論

ホームで SSO をセットアップすると、ホームラボが個別のサービスのコレクションから統一されたプラットフォームに変わります。初期セットアップの投資は、利便性とセキュリティの向上ですぐに報われます。

重要なポイント：

SSO は複数のサービスにわたるパスワード疲労を解消
Authelia はシンプルなセットアップに最適 リバースプロキシと共に
Authentik は完全な機能を提供 美しい UI と共に
フォワード認証は任意のサービスを保護
MFA は重要なセキュリティレイヤーを追加
LDAP 統合は大規模デプロイメントに対応
定期的なバックアップが不可欠（SSO は単一障害点）
ホームラボ SSO はセルフホストサービスに制限される - SaaS 統合には高価なエンタープライズプランが必要
フェデレーション（OIDC/SAML）はシステム間で SSO を可能にするが、WIA は非フェデレーション

クイックスタート推奨：

ほとんどのホームラボの場合：

Authelia + Traefik から始める（最もシンプルな道）
最初はファイルベース認証を使用
管理者アカウントに MFA を追加
徐々にサービスを SSO に移行
後で OIDC/SAML が必要な場合は Authentik を検討

2-3 のサービスから始めて、フローに慣れてから拡張してください。もう何十ものパスワードをやりくりしなくて済むようになったとき、未来の自分が感謝するでしょう！🔐

Authentik のセットアップ

ステップ 1：Docker Compose でインストール

# 公式 compose ファイルをダウンロード
wget https://goauthentik.io/docker-compose.yml
wget https://goauthentik.io/.env

# シークレットを生成
echo "PG_PASS=$(openssl rand -base64 36)" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60)" >> .env

# サービスを起動
docker-compose up -d

ステップ 2：初期セットアップ

http://localhost:9000/if/flow/initial-setup/ にアクセス
管理者アカウントを作成
セットアップウィザードを完了

ステップ 3：アプリケーションの作成

Applications → Create
- Name: Nextcloud
- Slug: nextcloud
- Provider: 新しい OIDC プロバイダーを作成
OIDC プロバイダーの設定
- Client Type: Confidential
- Redirect URIs: https://nextcloud.homelab.local/apps/oidc_login/oidc
- Signing Key: 自動生成
認証情報をメモ：
- Client ID: (自動生成)
- Client Secret: (自動生成)

ステップ 4：アプリケーションの設定（Nextcloud の例）

// nextcloud/config/config.php
'oidc_login_provider_url' => 'https://auth.homelab.local/application/o/nextcloud/',
'oidc_login_client_id' => 'your-client-id',
'oidc_login_client_secret' => 'your-client-secret',
'oidc_login_auto_redirect' => true,
'oidc_login_button_text' => 'Log in with SSO',
'oidc_login_hide_password_form' => true,
'oidc_login_attributes' => [
    'id' => 'sub',
    'name' => 'name',
    'mail' => 'email',
    'groups' => 'groups',
],

アプリケーションの統合

ネイティブ OIDC サポートを持つアプリケーション

Grafana：

# grafana.ini
[auth.generic_oauth]
enabled = true
name = SSO
client_id = grafana-client-id
client_secret = grafana-client-secret
scopes = openid profile email
auth_url = https://auth.homelab.local/application/o/authorize/
token_url = https://auth.homelab.local/application/o/token/
api_url = https://auth.homelab.local/application/o/userinfo/

Portainer：

Settings → Authentication
OAuth → Enable
Authentik からエンドポイントを設定

Home Assistant：

# configuration.yaml
auth_providers:
  - type: homeassistant
  - type: command_line
    command: /config/auth_script.sh
    args: ["--username"]
    meta: true

OIDC サポートのないアプリケーション

Authelia/Traefik でフォワード認証を使用：

# 任意のサービスを保護
labels:
  - "traefik.http.routers.myapp.middlewares=authelia@docker"

アプリケーションサポートマトリックス

アプリケーション	OIDC	SAML	フォワード認証	難易度
Nextcloud	✅ はい	✅ はい	✅ はい	簡単
Grafana	✅ はい	❌ いいえ	✅ はい	簡単
Portainer	✅ はい	❌ いいえ	✅ はい	簡単
Jellyfin	⚠️ プラグイン	❌ いいえ	✅ はい	中
Home Assistant	⚠️ カスタム	❌ いいえ	✅ はい	中
Proxmox	✅ はい	❌ いいえ	❌ いいえ	中
TrueNAS	❌ いいえ	✅ はい	✅ はい	難

ユーザー管理

ユーザーの追加（Authelia）

# config/users_database.yml
users:
  newuser:
    displayname: "New User"
    password: "$argon2id$v=19$m=65536,t=3,p=4$..."
    email: newuser@homelab.local
    groups:
      - users

変更後に Authelia を再起動します。

ユーザーの追加（Authentik）

Directory → Users → Create
詳細を入力
グループに割り当て
パスワードを設定（または招待を送信）

グループベースのアクセス制御

Authelia：

# config/configuration.yml
access_control:
  rules:
    - domain: "admin.homelab.local"
      policy: two_factor
      subject:
        - "group:admins"
    
    - domain: "*.homelab.local"
      policy: two_factor
      subject:
        - "group:users"

Authentik：

グループを作成：admins、users、family
ユーザーをグループに割り当て
アプリケーションポリシーでグループメンバーシップをチェック

高度：LDAP 統合

大規模なセットアップの場合、LDAP を中央ユーザーディレクトリとして使用します。

OpenLDAP のインストール

# docker-compose.yml
services:
  openldap:
    image: osixia/openldap:latest
    environment:
      - LDAP_ORGANISATION=Homelab
      - LDAP_DOMAIN=homelab.local
      - LDAP_ADMIN_PASSWORD=admin_password
    volumes:
      - ldap_data:/var/lib/ldap
      - ldap_config:/etc/ldap/slapd.d
    ports:
      - "389:389"
      - "636:636"

  ldap-admin:
    image: osixia/phpldapadmin:latest
    environment:
      - PHPLDAPADMIN_LDAP_HOSTS=openldap
    ports:
      - "8080:80"
    depends_on:
      - openldap

volumes:
  ldap_data:
  ldap_config:

Authelia を LDAP で設定

# config/configuration.yml
authentication_backend:
  ldap:
    url: ldap://openldap:389
    base_dn: dc=homelab,dc=local
    username_attribute: uid
    additional_users_dn: ou=users
    users_filter: (&({username_attribute}={input})(objectClass=person))
    additional_groups_dn: ou=groups
    groups_filter: (&(member={dn})(objectClass=groupOfNames))
    user: cn=admin,dc=homelab,dc=local
    password: admin_password

Authentik を LDAP で設定

Directory → Federation & Social → LDAP Sources
新しい LDAP ソースを作成
接続の詳細を設定
属性をマッピング

セキュリティのベストプラクティス

⚠️ 重要なセキュリティ対策

SSO システムを保護：

SSO は単一障害点 - しっかり保護する
強力な管理者パスワードを使用
すべての管理者アカウントで MFA を有効化
ソフトウェアを最新に保つ
認証ログを監視
設定を定期的にバックアップ

セキュリティチェックリスト：

[ ] すべてのアカウントに強力なパスワード
[ ] 管理者に MFA を有効化
[ ] すべての場所で HTTPS（プライベート CA を使用）
[ ] レート制限を有効化
[ ] ログイン失敗の通知
[ ] 定期的なセキュリティ監査
[ ] 認証データベースのバックアップ
[ ] 復旧手順を文書化
[ ] アカウント復旧フローをテスト
[ ] 不審なアクティビティを監視

ネットワークセキュリティ：

# Authelia レート制限
regulation:
  max_retries: 3
  find_time: 2m
  ban_time: 5m

セッションセキュリティ：

# 短いセッションタイムアウト
session:
  expiration: 1h
  inactivity: 15m

トラブルシューティング

問題：リダイレクトループ

**原因：**フォワード認証またはセッション Cookie の設定ミス

解決策：

# セッションドメインが一致することを確認
session:
  domain: homelab.local  # ドメインと一致する必要がある

問題：「Invalid Redirect URI」

**原因：**アプリケーションのリダイレクト URI が OIDC 設定と一致しない

解決策：
アプリケーションログで実際のリダイレクト URI を確認し、IdP で更新します。

問題：ログイン後にユーザーがアクセスできない

**原因：**認可ヘッダーが欠落

解決策：

# Traefik - ヘッダーが転送されることを確認
- "traefik.http.middlewares.authelia.forwardauth.authResponseHeaders=Remote-User,Remote-Groups"

問題：セッションの有効期限が早すぎる

解決策：

# セッション期間を延長
session:
  expiration: 12h
  inactivity: 2h
  remember_me_duration: 1M

監視とメンテナンス

ログ監視

# Authelia ログ
docker logs -f authelia

# ログイン失敗を監視
docker logs authelia 2>&1 | grep "authentication failed"

バックアップ戦略

#!/bin/bash
# backup-sso.sh

BACKUP_DIR="/backups/sso/$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR

# Authelia をバックアップ
cp -r /path/to/authelia/config $BACKUP_DIR/
cp -r /path/to/authelia/secrets $BACKUP_DIR/

# Authentik データベースをバックアップ
docker exec authentik-postgres pg_dump -U authentik > $BACKUP_DIR/authentik.sql

echo "バックアップ完了: $BACKUP_DIR"

ヘルスチェック

# docker-compose.yml
services:
  authelia:
    healthcheck:
      test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:9091/api/health"]
      interval: 30s
      timeout: 3s
      retries: 3

比較：SSO ソリューション

側面	Authelia	Authentik	Keycloak
RAM 使用量	~50MB	~500MB	~1GB
セットアップ時間	30分	1時間	2時間以上
設定方法	YAML	Web UI	Web UI
ユーザーストレージ	ファイル/LDAP	データベース	データベース/LDAP
OIDC	基本	完全	完全
SAML	❌	✅	✅
学習曲線	低	中	高
コミュニティ	活発	非常に活発	巨大

リソース

**Authelia ドキュメント：**完全な Authelia ガイド
**Authentik ドキュメント：**Authentik のセットアップと設定
**Keycloak ドキュメント：**エンタープライズ SSO ガイド
**OIDC 説明：**OpenID Connect の理解