AuthentikをDocker Composeで構築する方法

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

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

Authentik は、その Compose ファイルで3つのサービスとして起動します。PostgreSQL データベース、server プロセス、worker プロセスです。server container では embedded outpost も実行されます。これは、保護対象の各アプリに対して「このリクエストはサインイン済みか」を判定するコンポーネントです。2026.5 は2026年7月時点の現行リリースです。プロジェクトでは、少なくとも2 CPU cores と2 GBの RAMを備えたホストを求めています。これを最低要件と考えてください。ホストを1日稼働させると、PostgreSQL と worker はどちらもメモリを使用します。

開始前に必要なもの

Docker Engine と Compose v2 plugin が必要です。docker compose version でインストール済みか確認できます。バージョンではなくエラーが表示された場合は、先に plugin をインストールしてください。基本的な手順は VPS で Docker Compose を使ってアプリを実行する で説明しています。また、サーバーを指す 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 のパスワードで、長さは最大 99 文字です。AUTHENTIK_SECRET_KEY はセッションとトークンへの署名に使われるため、後から変更するとすべてのユーザーがログアウトされ、発行済みのすべての API トークンが無効になります。.env のモードは 600 のままにし、安全な場所にコピーを保管してください。一致する秘密鍵なしで復元したデータベースには、誰もログインできません。

Compose ファイルは ${PG_PASS:?database password required} 形式で両方の値を読み込みます。このため、ファイルがない場合、Compose は起動を拒否します。誤ったディレクトリから docker compose up -d を実行すると、required variable AUTHENTIK_SECRET_KEY is missing a value: secret key required と表示されて停止します。これは設定の問題ではなく、パスの問題です。

重要な環境変数

それ以外の設定は、同じ .env ファイルに記述します。Authentik では、二重アンダースコアがネストした設定キーに対応するため、AUTHENTIK_EMAIL__HOST は email.host を設定します。単一のアンダースコアは警告なしで無視されます。設定が反映されないように見える原因として、これが最も一般的です。

• 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 です。クラッシュレポートを上流へ送信しても問題ない場合に限り、true に設定してください。

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

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

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

Directory、Users の順に開き、自分用の通常の管理者ユーザーを作成します。そのユーザーを authentik Admins グループに追加し、そのアカウントでログインします。akadmin は緊急用アカウントとして残し、長いパスワードをオフラインで保管します。共有の組み込みアカウントで日常の作業を行うと、監査ログが役に立たなくなります。すべてのイベントが akadmin と記録され、実際に操作した人物が分からなくなるためです。この問題は Authentik の下流にも当てはまります。たとえば 各ユーザーに専用のエージェントを提供する自己ホスト型 OneCLI ハーネスでも、接続元の ID がチーム全体で共有するログインではなく、1 人のユーザーに対応している場合にだけ、追跡可能なログを残せます。

リバースプロキシの背後に 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 が返る場合、コンテナが proxy ネットワークに接続されていないため、Traefik は到達できないコンテナへルーティングできません。

ホスト名でアクセスできることを確認したら、override 内で公開ポートを 127.0.0.1 にバインドします。これにより、アクセス経路をプロキシ経由だけにできます。

Forward auth で 1 つのアプリを保護する

Authentik の proxy provider には 3 つのモードがあり、選択を誤ると 1 時間を失います。Proxy は、outpost 自体が upstream のアプリへトラフィックを転送するモードです。Forward auth (single application) は、使用している reverse proxy が引き続きトラフィックを転送し、リクエストがサインイン済みかどうかだけを Authentik に問い合わせるモードです。Forward auth (domain level) は、1 つの親ドメイン配下にあるすべてのアプリを 1 つの provider で保護するモードですが、アプリ単位の認可ルールを設定できなくなります。Traefik を前段に置く場合は、forward auth (single application) を選択します。具体的に試すアプリが必要なら、自己ホストの AFFiNE ワークスペースのようなものが最初の候補として適しています。自分のデバイスからだけ到達できるようにしたい内部ツールだからです。チーム向けのツールなら、自己ホストの Chatwoot サポートデスクも同じ provider の背後に置くと、受信箱を担当する全員がその日の最初に 1 回サインインするだけで済み、パスワードをさらに共有する必要がなくなります。

Web インターフェースで Applications、次に Providers を開き、Proxy Provider を作成します。forward auth single application モードを選択し、external host に https://app.example.com を設定します。その provider を参照する Application を作成します。次に Outposts を開き、authentik Embedded Outpost を編集して、新しいアプリケーションを selected applications に追加します。outpost は割り当てられたアプリケーションに対してのみ応答します。そのため、最後の手順を省くと、provider が正しく設定されていても何も返りません。

middleware は Authentik コンテナ上で 1 回だけ定義し、保護する各アプリから参照します。

      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-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 は、Authentik の応答から Traefik が取得し、upstream に送るリクエストへ付加するヘッダーの一覧です。これを省略してもアプリ自体は保護されますが、アプリはユーザーを認識できません。そのため、automatic login 用に X-authentik-username を読み取る機能はログアウト状態のままになります。この差は、独自のサインイン機能を持つアプリの前段で特に明確になります。たとえば 自己ホストの openGym ワークアウトトラッカーとその passkey login では、同じページに対するプロンプトが 1 回で済むか 2 回になるかをヘッダーが左右します。

保護するアプリ自体には、router が 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 つ目の router は、誰もが設定から漏らす部分です。サインイン後、Authentik はブラウザーを /outpost.goauthentik.io/ 配下のパスへ戻します。戻り先は アプリの hostname であり、auth.example.com ではありません。そのパスプレフィックスを Authentik service へ送る router がないと、リクエストはアプリに到達し、アプリが 404 を返すため、ログインが完了しません。高い priority を設定すると、同じドメイン上の単純な Host() ルールよりも、特定のパスルールが優先されます。

プライベートブラウザーウィンドウでテストします。auth.example.com へリダイレクトされ、サインイン後にアプリへ戻ることを確認します。Authentik 側の docker compose logs -f server には試行ごとに認可イベントが表示されるため、リクエストが Authentik まで到達したかどうかを確認できます。

実際に遭遇する障害

アプリとログインページの間でリダイレクトループが終わらない。 プロバイダー側の外部ホストが、ブラウザーで使用しているホストと一致していません。通常は、プロバイダー側の http:// とアドレスバーの https:// が異なります。そのため、セッション Cookie が別のオリジンに設定され、戻るたびに新しい未認証リクエストとして扱われます。外部ホストを修正し、再テストする前に両方のドメインの Cookie を削除してください。

/outpost.goauthentik.io/start で 404 が返る。 outpost router が存在しないか、その優先度が同じホストの catch-all router より低くなっています。

ログインを要求されないままアプリが読み込まれる。 middlewares ラベルが、存在しない middleware を指定しています。Traefik はこの状態を警告しないため、authentik@docker のタイプミスがあると middleware は実行されません。Traefik dashboard を開き、router に middleware が一覧表示されていることを確認してください。

ログインには成功したのに Authentik から 403 が返る。 ユーザーは認証されていますが、認可されていません。アプリケーションに、このユーザーが満たしていない policy binding または group 要件が設定されています。管理インターフェースの Events log に、拒否した policy が表示されます。

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

Keycloak は Red Hat が支援する歴史の長いプロジェクトです。従来型のエンタープライズ ID 管理では、こちらのほうが有力です。特に、SAML フェデレーション、複数の外部 identity provider からのログインを同時に仲介する構成、文書化された移行手段としての realm の export と import に適しています。商用サポートがあることを、組織によっては重要視します。

一方、Keycloak には独自の proxy がありません。OIDC (OpenID Connect) に対応していないアプリを保護するには、Keycloak と併せて oauth2-proxy などを実行する必要があります。Authentik には、この機能に相当する組み込みの proxy provider があり、すでに統合されています。そのため、さまざまなアプリを混在させて運用する self-host 環境では、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を一緒に保管します。ダンプだけでは不十分です。セッションとトークンのデータを保護する Secret key が.envに保存されているためです。

アップグレードはタグの変更です。.envでAUTHENTIK_TAGを目的のリリースに設定し、docker compose pullを実行してからdocker compose up -dを実行します。Auth...

FAQ

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

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

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

いいえ。forward auth は auth_request を使用した nginx でも、forward_auth を使用した Caddy でも動作します。どの場合も構成は同じです。リバースプロキシが各リクエストについて Authentik に確認し、保護対象ホスト名のパスプレフィックス /outpost.goauthentik.io/ をアプリではなく Authentik にルーティングします。

保護対象のアプリがログインとエラーの間を無限に行き来するのはなぜですか？

プロキシプロバイダーに設定した外部ホストが、ブラウザーで使用している URL と一致していません。最も多いのは http と https の不一致です。セッション Cookie は一方のオリジン向けに発行され、別のオリジンで読み取られるため、Authentik は毎回匿名リクエストとして扱います。外部ホストを修正し、再テストする前に両方のホスト名の Cookie を削除してください。

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

2026 年 7 月時点で、文書化されている最小要件は CPU 2 コアと RAM 2 GB です。PostgreSQL、server、worker を合わせた要件です。RAM 2 GB のホストでは、メモリープレッシャーがかかったときに最初に kernel が終了させるプロセスは worker です。その場合、ログインページは動作していても、バックグラウンドタスクと送信メールが停止します。同じサーバーで保護対象のアプリも実行する場合は、RAM 4 GB を割り当ててください。