Authentikの構築方法：DockerでSSOを導入する手順

ホストするすべてのアプリに1つのログインを使う

Authentik は、セルフホスト型の SSO（シングルサインオン）サーバーです。ユーザーは1回ログインするだけで、Authentik の背後にあるすべてのアプリが個別のパスワードを要求せず、そのセッションを受け入れます。インストールには、公式の Docker Compose ファイルと、生成する2つの Secret を使います。本当に検討が必要なのは、その後です。リバースプロキシから Authentik へ転送し、既存のアプリ1つを forward auth の背後に配置します。

Authentik は、その Compose ファイル内で3つのサービスとして動作します。PostgreSQL データベース、server プロセス、worker プロセスです。server コンテナでは embedded outpost も動作します。これは、保護対象の各アプリに対して「このリクエストはログイン済みか」を応答するコンポーネントです。2026 年 10 月 16 日時点の現行リリースは 2026.8.4 です。これは 2026 年 10 月 14 日に公開された 2026.8 系列の最新パッチであり、2026 年 8 月 18 日に 2026.8.0 で始まった系列です。公式の Compose ファイルでは、2026 年 9 月 17 日の 2026.8.3 に代わるデフォルトのイメージタグになっています。プロジェクトは、少なくとも 2 CPU コアと 2 GB の RAM を備えたホストを求めています。これを最低ラインと考えてください。ホストを1日稼働させると、PostgreSQL と worker はどちらもメモリを保持します。

開始前の準備

Docker Engine と Compose v2 プラグインが必要です。docker compose version を実行して確認してください。バージョン情報ではなくエラーが表示される場合は、先にプラグインをインストールしてください。基本手順については Docker Compose を使用した VPS でのアプリ実行 を参照してください。また、サーバーを指す DNS A レコード（以下の例では auth.example.com）が必要です。Authentik はブラウザが使用したホスト名からリダイレクト URL を生成するためです。

スタックは root ではなく docker グループに所属する一般ユーザーとして実行してください。このグループのメンバーシップはホスト上の root と同等の権限を持つため、デプロイ用のアカウントを1つだけ作成し、VPS における最小権限のユーザーアカウント に従って設定してください。

公式の Compose ファイルでインストールする

sudo install -d -o "$USER" -g "$USER" /opt/authentik
cd /opt/authentik
wget https://docs.goauthentik.io/compose.yml
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env
docker compose pull
docker compose up -d

docker compose ps には 3 つのコンテナが表示されます。postgresql は healthy と server を報告し、worker は running を報告します。初回起動時にはデータベースのマイグレーションが実行されるため、Web インターフェースが応答するまで 1 分ほど待ちます。

生成された 2 つの値は、それぞれ異なる理由で重要です。PG_PASS は PostgreSQL のパスワードです。Authentik のインストール手順では、99 文字を超えるパスワードはサポートされないと説明されています。そのため、自分で選ぶパスワードは 99 文字未満にしてください。生成されたパスワードはそれより大幅に短い値です。AUTHENTIK_SECRET_KEY はセッションとトークンの署名に使用されます。後から変更すると、すべてのユーザーがログアウトされ、発行済みのすべての API トークンが無効になります。.env のモードは 600 のままにし、安全な場所にコピーを保管してください。一致する Secret key なしで復元したデータベースには、誰もログインできません。

Compose ファイルでは、${VAR:?message} 形式を使って両方の値を必須として指定しています。PostgreSQL service では ${PG_PASS:?database password required}、server と worker では ${AUTHENTIK_SECRET_KEY:?secret key required} が指定されています。そのため、ファイルがない場合、Compose は起動を拒否します。間違ったディレクトリで docker compose up -d を実行すると、required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required のような行が表示されて停止します。このメッセージは設定の問題ではなく、パスの問題です。

重要な環境変数

その他の設定はすべて同じ .env ファイルに記述します。Authentik では、2 つのアンダースコアが入れ子になった設定キーに対応するため、AUTHENTIK_EMAIL__HOST は email.host を設定します。アンダースコアが 1 つだけの場合は入れ子になったキーに対応しません。設定が反映されないように見える最も一般的な原因です。

• AUTHENTIK_BOOTSTRAP_PASSWORD は、初回起動時に組み込みの akadmin ユーザーのパスワードを設定します。そのため、公開 Web フォームにパスワードを入力する必要がありません。AUTHENTIK_BOOTSTRAP_EMAIL と AUTHENTIK_BOOTSTRAP_TOKEN も同様に、そのユーザーのアドレスと API トークンを設定します。
• COMPOSE_PORT_HTTP と COMPOSE_PORT_HTTPS は、公開ポートをデフォルトの 9000 と 9443 から変更します。
• AUTHENTIK_EMAIL__HOST、AUTHENTIK_EMAIL__PORT、AUTHENTIK_EMAIL__USERNAME、AUTHENTIK_EMAIL__PASSWORD、AUTHENTIK_EMAIL__USE_TLS、AUTHENTIK_EMAIL__FROM は、送信メールを設定します。これらを設定しない場合、Authentik はポート 25 で localhost への接続を試みます。そのため、パスワードリセットメールの送信は worker のログに接続エラーとして記録されます。
• AUTHENTIK_LOG_LEVEL=debug は、ログインフローに問題があるときに必要な詳細情報を有効にします。問題の調査後は info に戻してください。
• AUTHENTIK_ERROR_REPORTING__ENABLED のデフォルト値は false です。クラッシュレポートを upstream に送信しても問題ない場合に限り、true に設定してください。

これらは平文ファイル内の Secret です。そのため、ディレクトリは他の認証情報ストアと同じように扱ってください。ノートパソコンのメモよりも、self-hosted Vaultwarden インスタンスなどのパスワードマネージャーに復旧用コピーを保存する方が安全です。

初回ログインと管理者アカウント

ブラウザで http://SERVER_IP:9000 を開きます。Authentik の初期セットアップフローが表示され、デフォルトの akadmin ユーザーのパスワード設定を求められます。すでに AUTHENTIK_BOOTSTRAP_PASSWORD を設定済みの場合は、その手順は完了しており、直接ログインページへ遷移します。

Directory の Users から自分用の管理者ユーザーを作成し、authentik Admins グループに追加して、そのアカウントでサインインしてください。akadmin は、オフラインで保管した長いパスワードを持つ緊急用アカウントとして残しておきます。共有の組み込みアカウントで日常業務を行うと、すべてのイベントが akadmin と記録され、誰が操作したか判別できなくなるため、監査ログが機能しなくなります。この論理は Authentik の下流システムにも適用されます。例えば 各人に個別のエージェントを割り当てるセルフホスト型の OneCLI ハーネス のような仕組みも、到達するアイデンティティがチーム共有のログインではなく特定の個人に紐付いていなければ、追跡可能なログは残りません。

リバースプロキシの背後に Authentik を配置する

ポート 9000 をインターネットに公開することはできますが、TLS（トランスポート層セキュリティ）と実際のホスト名を使用したい場合があります。すでに 複数の Compose アプリケーション用の Traefik リバースプロキシ の構成を使用している場合は、override ファイルを使って Authentik を同じ外部 proxy ネットワークに接続します。compose.yml の隣に docker-compose.override.yml を作成します。

services:
  server:
    networks:
      - default
      - proxy
    labels:
      traefik.enable: "true"
      traefik.docker.network: proxy
      traefik.http.routers.authentik.rule: Host(`auth.example.com`)
      traefik.http.routers.authentik.entrypoints: websecure
      traefik.http.routers.authentik.tls.certresolver: le
      traefik.http.services.authentik.loadbalancer.server.port: "9000"

networks:
  proxy:
    external: true

docker compose up -d で適用します。Compose は override を自動的にマージするため、server サービスには公式ファイルの設定がすべて引き継がれ、ラベルが追加されます。curl -I https://auth.example.com/if/user/ で確認すると、HTTP/2 200 が返るはずです。Traefik から 404 page not found が返る場合、リクエストに一致する router がありません。ラベルがコンテナに反映されていること、Host() ルールがホスト名と完全に一致していること、そして router が待ち受ける HTTPS entry point にリクエストが到達していることを確認します。

ホスト名でアクセスできるようになったら、override 内で公開ポートを 127.0.0.1 にバインドし、プロキシ経由だけでアクセスできるようにします。

Forward authによるアプリケーションの保護

Authentikのプロキシプロバイダーには3つのモードがあり、選択を誤ると調査に時間を浪費します。Proxyモードは、Outpost自体がトラフィックをアップストリームのアプリへ転送します。Forward auth (single application)モードは、リバースプロキシがトラフィックを転送し、リクエストがサインイン済みかどうかのみをAuthentikに問い合わせます。Forward auth (domain level)モードは、親ドメイン配下の全アプリを単一のプロバイダーで保護しますが、アプリごとの認可ルール設定はできません。Traefikを前段に置く場合、Forward auth (single application)を選択してください。練習用の具体的なアプリとしては、セルフホスト版AFFiNEワークスペースなどが適しています。これは自身のデバイスからのみアクセス可能にすべき内部ツールの一例です。チーム用ツールであればさらに重要性は増します。セルフホスト版Chatwootサポートデスクを同じプロバイダー配下に置けば、担当者はパスワードを共有することなく、1日の初めに一度サインインするだけで済みます。

Webインターフェースで「Applications」から「Providers」を開き、「Proxy Provider」を作成します。モードに「forward auth single application」を選択し、外部ホストを https://app.example.com に設定してください。そのプロバイダーを指す「Application」を作成します。次に「Outposts」を開き、authentik Embedded Outpost を編集して、作成したアプリケーションを「Selected applications」に追加します。Outpostは割り当てられたアプリケーションに対してのみ応答するため、この手順を忘れると、プロバイダーの設定が正しくても何も返答がありません。

ミドルウェアをAuthentikコンテナ上で一度定義し、保護対象の各アプリから参照します。

      traefik.http.middlewares.authentik.forwardauth.address: http://server:9000/outpost.goauthentik.io/auth/traefik
      traefik.http.middlewares.authentik.forwardauth.trustForwardHeader: "true"
      traefik.http.middlewares.authentik.forwardauth.authResponseHeaders: X-authentik-username,X-authentik-groups,X-authentik-entitlements,X-authentik-email,X-authentik-name,X-authentik-uid,X-authentik-jwt,X-authentik-meta-jwks,X-authentik-meta-outpost,X-authentik-meta-provider,X-authentik-meta-app,X-authentik-meta-version

authResponseHeaders は、TraefikがAuthentikの応答からコピーし、アップストリームへ送信するヘッダーのリストです。これを省略するとアプリは保護されますが、ユーザーIDを認識できません。そのため、自動ログインのために X-authentik-username を読み取る機能はログアウト状態のままとなります。この欠落は、セルフホスト版openGymワークアウトトラッカーのように独自のサインイン機能を持つアプリで顕著です。ヘッダーの有無により、同じページに対して認証プロンプトが1回で済むか、2回必要になるかが決まります。

保護対象のアプリには、1つではなく2つのルーターが必要です。

    labels:
      traefik.enable: "true"
      traefik.http.routers.myapp.rule: Host(`app.example.com`)
      traefik.http.routers.myapp.entrypoints: websecure
      traefik.http.routers.myapp.tls.certresolver: le
      traefik.http.routers.myapp.middlewares: authentik@docker
      traefik.http.routers.myapp-auth.rule: Host(`app.example.com`) && PathPrefix(`/outpost.goauthentik.io/`)
      traefik.http.routers.myapp-auth.entrypoints: websecure
      traefik.http.routers.myapp-auth.tls.certresolver: le
      traefik.http.routers.myapp-auth.priority: "15"
      traefik.http.routers.myapp-auth.service: authentik

2つ目のルーターは忘れられがちな部分です。サインイン後、Authentikはブラウザを auth.example.com ではなく、アプリのホスト名上の /outpost.goauthentik.io/ 配下のパスへリダイレクトします。このパスプレフィックスをAuthentikサービスへ送信するルーターがないと、リクエストはアプリに到達して404エラーとなり、ログインが完了しません。priority を高く設定することで、同一ドメイン上の単純な Host() ルールよりも、特定のパスルールが優先されます。

プライベートブラウズウィンドウでテストしてください。auth.example.com へリダイレクトされ、サインイン後にアプリへ戻れば成功です。Authentik側の docker compose logs -f server には試行ごとに認証イベントが出力されるため、リクエストがAuthentikに到達しているかを確認できます。

実際に発生する障害

アプリケーションとログインページ間での無限リダイレクトループ。 プロバイダー側の外部ホスト名がブラウザ上のものと一致していません。通常、プロバイダー側の http:// とアドレスバーの https:// が不一致です。この場合、セッションクッキーが異なるオリジンに対して設定されるため、リクエストのたびに新規の匿名アクセスとして扱われます。外部ホストの設定を修正し、両方のドメインのクッキーを削除してから再テストしてください。

/outpost.goauthentik.io/start で 404 エラーが発生。 アウトポストのルーターが存在しないか、そのホストに対するキャッチオールルーターよりも優先度が低くなっています。

ログインを求められずにアプリが読み込まれる。 middlewares ラベルで指定したミドルウェアが存在しません。Traefik はこの点について警告を出さないため、authentik@docker の記述ミスは単にミドルウェアが実行されないことを意味します。Traefik ダッシュボードを開き、ルーターに該当のミドルウェアがリストされているか確認してください。

ログイン成功後に Authentik から 403 エラーが返される。 ユーザー認証は完了していますが、認可が拒否されています。アプリケーションにポリシーバインディングやグループ要件が設定されており、そのユーザーが条件を満たしていません。管理インターフェースの Events ログに、拒否の原因となったポリシー名が記録されています。

Keycloak のほうが適している場合

Keycloak は Red Hat が支援する、より古いプロジェクトです。従来型のエンタープライズ ID 基盤では、より強い選択肢です。具体的には、負荷の高い SAML フェデレーション、複数の外部 ID プロバイダーからのログインの同時仲介、realm の export と import を使った文書化済みの移行手順に適しています。背後に商用サポートがあることを、組織によっては形式上重視します。一方、Keycloak には独自のプロキシがありません。そのため、OIDC (OpenID Connect) も SAML も話さないアプリを保護するには、oauth2-proxy のようなものを Keycloak と併用する必要があります。Authentik の組み込みの proxy provider がこの役割を担い、すでに統合されています。そのため、さまざまなアプリが混在する環境を運用する self-hoster の多くは、Authentik を選びます。

バックアップとアップグレード

リストアを可能にするには、PostgreSQL データベース、./data ディレクトリ、および .env の3つが必要です。

cd /opt/authentik
docker compose exec -T postgresql pg_dump -U authentik authentik | gzip > authentik-$(date +%F).sql.gz

このダンプと .env は一緒に保管してください。ダンプだけでは不十分です。セッションやトークンデータを保護する秘密鍵が .env に含まれているためです。

アップグレードはタグの変更で行います。.env 内の AUTHENTIK_TAG に目的のリリースを設定し、docker compose pull を実行してから docker compose up -d を実行してください。AUTHENTIK_TAG を設定していない場合、バージョンは compose.yml 自体に記述されたデフォルト値から取得されます。そのため、そのファイルの新しいコピーをダウンロードすることがアップグレードとなり、公式のアップグレードドキュメントでもこの手順が説明されています。まずリリースノートを読んでください。Authentik は日付ベースのバージョンを採用しており、2026年10月現在、ドキュメントではメジャーリリースの順序に従ってアップグレードする必要があるとされています。現在実行中のシリーズの最新パッチに移行してから、シリーズを飛ばさずに順次新しいシリーズへ進んでください。Authentik はダウングレードをサポートしていないため、必ずプル（pull）の前にデータベースのダンプを取得してください。プルした後に取得してはいけません。

FAQ

Authentik のセルフホストは無料ですか？

オープンソース版は無料で、上記のすべてを利用できます。proxy provider、forward auth、OIDC（OpenID Connect）、SAML、flows engine が含まれます。有料の enterprise tier ではサポートと一部のエンタープライズ機能が追加されますが、ここで説明する構成にライセンスは必要ありません。

Authentik の利用に Traefik は必要ですか？

いいえ。forward auth は、nginx では auth_request を使って、Caddy では forward_auth を使って動作します。どの場合もパターンは同じです。リバースプロキシがリクエストごとに Authentik へ問い合わせ、保護対象のホスト名にあるパスプレフィックス /outpost.goauthentik.io/ をアプリではなく Authentik へルーティングします。

保護したアプリがログインとエラーを延々と繰り返すのはなぜですか？

proxy provider に設定した外部ホストが、ブラウザーで使用している URL と一致していません。多くの場合、http と https の不一致が原因です。セッション Cookie は一方の origin に対して発行され、別の origin で読み取られるため、Authentik は毎回匿名のリクエストとして認識します。外部ホストを修正し、再テストする前に両方のホスト名の Cookie を削除してください。

Authentik にはどの程度の RAM が必要ですか？

2026 年 10 月時点の文書化された最小要件は、2 CPU コアと 2 GB の RAM です。これは PostgreSQL、server、worker を合わせた要件です。2 GB のホストでは、メモリープレッシャーによってカーネルの OOM killer が起動することがあります。OOM killer は、最も高い badness score を持つプロセスを終了させます。このスコアは、おおむね使用している許可メモリの割合に加えて、その oom_score_adj で決まります。worker が終了した場合、ログインページは動作する一方で、バックグラウンドタスクと送信メールが停止する症状が現れます。同じサーバーで保護対象のアプリも実行するなら、4 GB を割り当ててください。