Authentik vs ZITADEL vs Keycloak：セルフホスト SSO はどれを選ぶべきか？

VPS 上で 8 つの Docker コンテナが動いているとします。Gitea、Nextcloud、Grafana、Vaultwarden、n8n、Portainer、ステータスページ、そして自作の社内アプリが 1 つ。それぞれに個別のログインがあります。毎朝パスワードマネージャーからパスワードをコピー＆ペーストしているうちに、シングルサインオンは運用コストに見合うのだろうかと考え始めます。

たいていの場合、見合います。問題は、どのアイデンティティプロバイダーを運用するかです。

Keycloak はおなじみのデフォルトですが、より適した選択肢は、スタックの構成、管理するユーザー数、そして既存のソフトウェアを連携させるのか自前のアプリケーションに認証を組み込むのかによって変わります。

このセルフホスト SSO 比較では、Authentik、ZITADEL、Keycloak、Authelia を、デプロイ後に重要になる判断軸で見ていきます。プロトコル対応、ユーザー管理、開発者のワークフロー、リソース要件、そしてアイデンティティプロバイダーがダウンしたときに何が起きるか、です。

セルフホスト SSO が重要な理由

複数のアプリケーションが同じユーザーとグループに依存するようになると、個別ログインは便利ではなくなります。セルフホストのアイデンティティプロバイダーがあれば、アカウント、MFA、グループ所属、アクセスポリシーを一か所で管理でき、アプリケーションごとに個別に設定する必要がなくなります。

トレードオフも同じくらい重要です。IdP は他のアプリケーションが依存するインフラになります。IdP が利用できないと新規ログインやトークン更新が失敗しうるため、バックアップ、復旧用アクセス、アップグレード、稼働率は、通常のセルフホストアプリよりもずっと重みを持ちます。

要約

最良のデフォルトを求めるなら Authentik を選ぶ

ホームラボ、社内ツール群、あるいは既存アプリケーションを OIDC や SAML で接続する小規模チームにとって、Authentik は最も堅実なデフォルトです。管理ワークフローは Keycloak より取っつきやすく、複数の連携方式に対応し、公式の Docker Compose 構成は CPU 2 コアと RAM 2 GB から始められます。

アプリを開発しているなら ZITADEL を選ぶ

認証が自社で開発するプロダクトの一部であるなら、ZITADEL を選びましょう。組織モデル、API、マルチテナンシー、OIDC、SAML、パスキー、MFA、LDAP アイデンティティプロバイダー対応は、一般的なホームラボよりも SaaS や B2B アプリケーションのチームに向いています。

エンタープライズ向けの ID 機能が必要なら Keycloak を選ぶ

より深い LDAP や Active Directory とのフェデレーション、複数のレルム、きめ細かな認可ポリシー、あるいはすでに Keycloak を中心に構築された環境が必要なら、Keycloak を選びましょう。ドキュメントでは、小規模な本番向け Keycloak コンテナに 2 GB のメモリ上限を推奨しています。PostgreSQL も同居させるオールインワンの VPS には、さらに余裕が必要です。

別の選択肢：主にログインの壁が欲しいなら Authelia を選ぶ

主な課題が、完全な ID 基盤の運用ではなくリバースプロキシ層でのアプリケーション保護であるなら、Authelia を選びましょう。OpenID Connect プロバイダーとしても動作しますが、重心はあくまでリバースプロキシでの認証にあります。

SSO ツールを選ぶ前に確認すること

機能を比較する前に、各ツールを、すでにサポートが必要なアプリケーション、プロトコル、ID ソースと照らし合わせましょう。

SSO が必要なアプリはいくつあるか？

アイデンティティプロバイダーではなくアプリケーションから始めましょう。すでに OIDC や SAML に対応した 6 つのアプリケーションからなるスタックと、どちらのプロトコルも知らない古い社内ツールのスタックとでは、問題がまったく異なります。前者は完全な IdP に向かい、後者はリバースプロキシ層での認証が必要になるかもしれません。

アプリは OIDC か SAML に対応しているか？

OIDC はモダンな Web アプリケーションで一般的な選択肢です。SAML はエンタープライズソフトウェアや古い連携ではまだ重要です。LDAP は、アプリケーションが Web ベースの SSO フローではなくディレクトリを期待している場合に意味を持ちます。間に入る IdP を選ぶ前に、各アプリケーションが実際に何を受け付けるのかを確認してください。

ユーザーを管理するのか、アプリにログインを組み込むのか？

既存アプリケーションを接続しながら、作業のほとんどが管理画面で行われるなら、Authentik が自然な出発点です。認証が開発中のプロダクトの一部で、組織、ユーザー、権限をコードでプロビジョニングする想定なら、ZITADEL のほうがそのワークフローにずっと近いです。

LDAP、Active Directory、高度なポリシーは必要か？

Authentik、ZITADEL、Keycloak はいずれも何らかの形で LDAP ベースの ID ソースに接続できるため、LDAP だけでは比較の決め手になりません。Keycloak が魅力を増すのは、ディレクトリフェデレーションに複数レルム、詳細なマッパー、同期要件、リソースレベルの認可ポリシーが組み合わさるときです。

Authentik vs ZITADEL vs Keycloak vs Authelia

4 つのツールは SSO という点では重なりますが、アイデンティティへのアプローチは異なります。アプリケーション連携、プロダクトの ID、エンタープライズ IAM、リバースプロキシ経由のアクセス、です。

Authentik

Authentik のコアデプロイは、サーバー、ワーカー、PostgreSQL データベースで構成されます。 Redis はもうスタックの一部ではありません。Authentik は 2025.10 リリースでこの依存関係を完全に取り除きました。 現行の Docker Compose ドキュメントでは、CPU 2 コア以上、RAM 2 GB 以上のホストが必要とされています。

決定的な特徴は管理 UI です。Authentik のフローエンジン、アプリケーションのプロビジョニング、グループベースのポリシーは、Keycloak の幅広い設定モデルよりも取っつきやすいものです。Keycloak で OIDC アプリケーションを設定した後、なぜトークンのクレームが欠けているのかを調べるのに時間を費やした経験があれば、その違いはすぐに分かります。

SAML、OAuth2/OIDC、LDAP、RADIUS に対応しています。セルフホストアプリのスタックを運用するホームラボや小規模なエンジニアリングチームにとって、適切なデフォルトです。

ZITADEL

ZITADEL は主に Go で書かれ、AGPL-3.0 ライセンスで、リリースラインは v4.x です。 デプロイは Go の API、Next.js のログイン UI、PostgreSQL で構成され、現行の要件では PostgreSQL 14 から 18 までをサポートしています。 公式の Docker Compose ドキュメントでは、RAM 2 GB 以上のホストが必要とされています。

決定的な特徴は API です。ZITADEL は gRPC と REST で完全な ID サーフェスを公開し、最初からマルチテナントモデルの上に構築されています。SaaS プロダクトを開発していて、ログイン層をプログラム可能、自動化可能、そしてデフォルトでマルチテナントにしたいなら、ZITADEL は他の選択肢よりも求めるものに近いはずです。

OIDC、SAML、パスキー、MFA、LDAP アイデンティティプロバイダー、そして現在 Preview 扱いの SCIM v2 インターフェースに対応しています。 組織モデルと API ファーストのワークフローにより、単純なホームラボよりもプロダクトチームに適しています。

Keycloak

Keycloak は Quarkus 上で動作する Java 製のアイデンティティ・アクセス管理プラットフォームです。 ここで挙げた他の選択肢よりも設定範囲が広く、特に Realms、Clients、Roles、ユーザーフェデレーション、Authorization Services が絡むとその傾向が強まります。

公式のコンテナドキュメントでは、小規模な本番向けデプロイに 2 GB のメモリ上限を推奨しています。 この数値は Keycloak コンテナ自体のものです。PostgreSQL が同じ VPS に同居するなら、ホストにはさらに余裕を持たせてください。

その複雑さを受け入れる理由は具体的です。 Keycloak は LDAP と Active Directory のディレクトリをフェデレーションし、ユーザーと管理者のイベントを記録し、RBAC、ABAC、ユーザーベース、コンテキストベースなどのポリシータイプによるきめ細かな認可を適用できます。 こうした制御が必要なら、追加の設定には意味があります。

Authelia

Authelia は 4 つの中で最も小さく、Apache 2.0 ライセンス、単一の Go バイナリで、現在は v4.39.x です。 アーキテクチャは他の 3 つとは異なります。Authelia はリバースプロキシ（nginx、Traefik、Caddy、HAProxy）の手前に位置し、リクエストをバックエンドに通してよいかを判断します。

Authelia には OpenID Connect プロバイダーも含まれています。 ドキュメントでは OIDC 実装をまだオープンベータと表現していますが、プロバイダーは Basic OP、Implicit OP、Hybrid OP、Form Post OP、Config OP の各プロファイルで OpenID 認定を取得しています。OIDC の機能は、Authentik や Keycloak が ID 管理向けに提供するものより限定的で、だからこそ Authelia はリバースプロキシでの認証が主な仕事である場合に最も理にかなっています。

Authelia については後で専用のセクションで改めて取り上げます。要点だけ言えば、Authelia の重心はリバースプロキシでのゲート制御であって、完全な ID 管理ではありません。

機能比較

以下の表では、デプロイと日々の管理に影響する違いに絞って比較しています。

どのツールがどのスタックに合うか？

最適な選択は、誰が IdP を運用し、アプリケーションがどう連携するかで変わります。

ホームラボに最適な選択肢

ほとんどのアプリケーションがすでに OIDC か SAML に対応しているホームラボでは、Authentik がデフォルトです。Keycloak の幅広い IAM モデルを採用しなくても、完全なアイデンティティプロバイダーが手に入ります。スタックの大半がネイティブ SSO ではなくリバースプロキシでのログイン画面を必要とするなら、Authelia のほうが単純な選択かもしれません。

小規模ビジネスのスタックに最適な選択肢

Authentik は、特に Grafana、Gitea、Nextcloud、Vaultwarden といったツールを一つの ID 層でまとめたい場合など、ほとんどの小規模な社内アプリケーションスタックに合います。既存のディレクトリ、複数レルム、より深い認可ポリシーが要件に含まれるなら、Keycloak の魅力が増します。

開発者と SaaS プロダクトに最適な選択肢

認証が開発中のプロダクトの一部であるなら、ZITADEL が最適です。ユーザーとテナントを主に管理パネルからではなくアプリケーションコードからプロビジョニングする必要がある場合、その組織モデル、マルチテナンシー、API、自動化のサーフェスが活きます。

読む

B2B SaaS 開発者に最適なセルフホスト型 CIAM

エンタープライズやコンプライアンス要件の厳しいチームに最適な選択肢

要件に複雑なディレクトリフェデレーション、複数レルム、詳細な認可ポリシーが含まれ、追加の IAM の複雑さを運用できるチームがいるなら、Keycloak は理にかなっています。Keycloak をセルフホストしても、それだけで環境がコンプライアンスに適合するわけではありません。バックアップ、可用性、ログ記録、アクセスレビュー、変更管理は引き続きチームの責任です。

ネイティブ SSO のないアプリに最適な選択肢

リクエストがアプリケーションに届く前に認証を行う必要があるなら、Authelia が最も明快な選択です。OIDC や SAML を自身では扱えない古い社内ツール、ダッシュボード、サービスをリバースプロキシで保護する用途に特に向いています。

SSO をセルフホストする難しさ

SSO が必須になると、設定ミスや復旧の失敗が複数のアプリケーションに一度に影響しかねません。

インストールと設定

コンテナを起動するのは最初の一歩にすぎません。DNS、TLS、リダイレクト URI、トークンのクレーム、グループのマッピング、メール配信、復旧用アクセスこそ、SSO のデプロイが「もう一つの Docker アプリ」からインフラへと変わるポイントです。

サーバーリソース

IdP はリソース予算の一部にすぎません。PostgreSQL、リバースプロキシ、ワーカー、パスワードハッシュ、ログ、ディレクトリ同期は、1 台の VPS を共有すると CPU とメモリを取り合います。

データベースとバックアップの管理

Authentik、ZITADEL、そして通常の本番 Keycloak デプロイはデータベースに依存します。そのデータベースをサーバーの外にバックアップし、復元手順を文書化し、復元をテストしてください。バックアップジョブの成功は、機能する復旧手順があることとは別物です。

ロックアウトと復旧のリスク

誤ったリダイレクト URI、期限切れのクライアントシークレット、切れたディレクトリ接続、厳しすぎるポリシーは、他の全員と一緒に管理者まで締め出しかねません。修理しようとしている認証フローに依存しない復旧経路を確保しておきましょう。

IdP の可用性を保つ

IdP の障害が、既存のアプリケーションセッションをすべて即座に終わらせるとは限りません。既存セッションは自身のトークンやクッキーが切れるまで続くかもしれませんが、新規ログインとトークン更新は失敗しえます。スタック全体で SSO を必須にする前に、この障害モードをテストしてください。

SSO をセルフホストすべきでないとき

チームがアプリケーションの求める信頼性で ID 層を復旧・運用できないなら、セルフホストは割に合わなくなります。

マネージド ID のほうが安全なとき

IdP を運用するコストがセルフホストで得られる制御を上回るなら、マネージド ID にお金を払う価値があります。Auth0、Clerk、WorkOS、Microsoft Entra ID といったサービスは、プラットフォームの可用性、パッチ適用、インフラ保守の多くをプロバイダー側に移します。

アプリケーションの設定、権限、復旧計画は引き続き自分の責任ですが、ID プラットフォーム自体を稼働させ続ける責任はなくなります。

チームがダウンタイムに対処できないとき

障害中に IdP を復旧し、PostgreSQL を修理し、期限切れのシークレットを差し替え、失敗したフェデレーション接続を診断できる人がチームに誰もいないなら、ID のセルフホストは誤った運用上のトレードオフかもしれません。

障害は利用できないアプリケーション 1 つにとどまりません。複数のアプリケーションで新規ログインとトークン更新が同時に失敗しえます。

コンプライアンス要件が高すぎるとき

セルフホストの ID は規制の厳しい環境でも使えますが、ソフトウェアを自分で動かしても、監査人が期待する統制や証跡が自動的に生まれるわけではありません。ログ記録、アクセスレビュー、バックアップ、変更管理、可用性、インシデント対応、そして該当するフレームワークが求める文書はすべて、引き続きチームの責任です。

セルフホスト SSO はステータスシンボルではありません。チームが ID 層を安全に運用できないなら、マネージド ID にお金を払うほうが優れたエンジニアリング上の判断になりえます。

Cloudzy が役立つところ

Cloudzy が変えるのはデプロイ層です。上で説明した ID の設定作業と運用作業がなくなるわけではありません。

手動での SSO デプロイの問題

手動での SSO デプロイとは、サーバーを準備し、アプリケーションとデータベースをインストールし、リバースプロキシを設定し、DNS と TLS を整え、そこでようやく ID 自体の設定に取りかかることを意味します。そのどれも、その後に来る OIDC、SAML、ディレクトリ、ポリシーの作業の代わりにはなりません。

Cloudzy でのワンクリック SSO デプロイ

Cloudzy には Authentik と Keycloak のワンクリックデプロイがあります。 Authentik のワンクリックアプリは Cloudzy マーケットプレイスにあります。 Keycloak のワンクリックアプリも Cloudzy マーケットプレイスにあります。 ZITADEL は現在マーケットプレイスにないため、標準的な VPS 上で Docker Compose 構成を使ってデプロイしてください。ワンクリックインストールでベースのアプリケーションは動き出しますが、ID の設定、DNS、バックアップ、アップグレード、ポリシー、復旧テストは引き続きあなたの管理下にあります。

IdP に別の VPS を使うべきとき

IdP をアプリケーションと同居させるのは、ダウンタイムが許容されるホームラボでは妥当です。ビジネスクリティカルなスタックでは、アイデンティティプロバイダーを分離することで明らかな共有障害ドメインがなくなります。アプリケーションサーバーの再起動、リソース枯渇、侵害が、そのまま ID 層を道連れにすることはなくなります。

別の VPS は高可用性と同じではありませんが、IdP に独自のリソース予算、保守スケジュール、復旧境界を与えます。

VPS サイジングの推奨

特に PostgreSQL とリバースプロキシが同じ VPS を共有する場合は、IdP プロセスだけでなくスタック全体でサイズを決めてください。

Authentik の VPS 要件

Authentik の公式 Docker Compose ドキュメントでは、CPU 2 コア以上、RAM 2 GB 以上のホストが必要とされています。小規模なデプロイにはこれが正しい出発点です。PostgreSQL、追加のアウトポスト、ディレクトリ同期、より多いログイントラフィックが同じホストに同居するなら、サーバーに余裕を持たせてください。

ZITADEL の VPS 要件

ZITADEL の公式 Docker Compose デプロイでは、ホストに RAM 2 GB 以上が必要です。Go のサービス単体で考えるのではなく、ZITADEL、そのログイン UI、PostgreSQL、リバースプロキシをまとめたオールインワン VPS としてサイズを決めてください。

Keycloak の VPS 要件

Keycloak のコンテナドキュメントでは、小規模な本番向け Keycloak デプロイに 2 GB のメモリ上限を推奨しています。この数値は Keycloak コンテナ自体に適用されるもので、PostgreSQL も動かす VPS 全体のものではありません。

Keycloak と PostgreSQL が 1 台の VPS を共有するなら、システム RAM 4 GB が妥当な出発点です。これは Keycloak の公式な最小要件ではなく、ホストに関する実践的な目安として扱ってください。

Authelia の VPS 要件

Authelia は、直接比較できる 1 GB や 2 GB といったサーバー最小要件を公表していません。リバースプロキシ、ストレージバックエンド、ユーザーディレクトリ、その他マシンを共有するサービスとあわせて Authelia のホストをサイジングしてください。

Authelia のデプロイフットプリントは、一般に完全な IdP と PostgreSQL を並べて動かすより小さいですが、実際の VPS 要件はスタックの残りの部分次第です。

設定例：Authentik と Vaultwarden

Vaultwarden は 2025 年 12 月のバージョン 1.35.0 で、ネイティブの OpenID Connect SSO 対応を追加しました。 Authentik が良い例になるのは、この連携で、他のアプリケーションでも出会う OIDC の構成要素、つまりリダイレクト URI、クライアント資格情報、スコープ、発行者 URL、復旧用アクセスが一通り登場するからです。

Authentik の基本設定

Authentik 側で：

1. Vaultwarden 用にカスタムのメールスコープマッピングを作成します。 Vaultwarden は、email スコープが email_verified: true を返すか、email_verified の値をまったく返さないことを要求しますが、Authentik のデフォルトのメールスコープは現在 false を返します。
2. OAuth2/OpenID Connect のアプリケーションとプロバイダーのペアを作成します。
3. https://vault.example.com/identity/connect/oidc-signin を、厳密一致の Authorization リダイレクト URI として追加します。
4. 利用可能な署名鍵のいずれかを選択します。
5. Client ID、Client Secret、アプリケーションのスラッグを控えます。
6. アクセストークンの有効期間を 5 分より長く設定します。
7. Authentik の offline_access マッピングを選択済みスコープに追加します。
8. デフォルトのメールマッピングを、手順 1 で作成した検証済みメール用のカスタムマッピングに置き換えます。

Vaultwarden の基本的な OIDC 設定

次を使います：

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

例のドメイン、アプリケーションのスラッグ、クライアント ID、クライアントシークレットを自分のデプロイの値に置き換え、Vaultwarden を再起動します。

読む

Bitwardenパスワードマネージャーのセルフホスト: 完全ガイド

SSO を強制する前にテストすること

ログイン、ログアウト、トークン更新、アカウントの照合、復旧をテストする間は、SSO_ONLY を false のままにしておきます。Authentik が一時的に利用できなくなったときに何が起きるかもテストしてください。

SSO と復旧の両方が期待どおりに動いたら、すべてのログインで SSO を必須にすることが自分のデプロイにとって妥当かを判断できます。

同じ OIDC の考え方は他のセルフホストアプリケーションにも当てはまりますが、リダイレクト URI、スコープ、クレーム、ライセンスは異なります。Vaultwarden の設定をそのまま流用するのではなく、各アプリケーションの SSO ドキュメントを確認してください。

完全な IdP より Authelia が向いているとき

アプリケーションがアイデンティティプロバイダーをまったく理解する必要がないとき、Authelia はより魅力的になります。

リバースプロキシでの認証

Authelia は主にリバースプロキシ層でアプリケーションを保護するために設計されています。アクセス制御ルールを定義すると、アプリケーション自身が認証を処理する前に、Authelia がリクエストをバックエンドに通すべきかを判断します。

OIDC のないアプリを保護する

これは OIDC や SAML に対応していない古い社内ツール、ダッシュボード、サービスに有効です。各アプリケーションを改修する代わりに、リバースプロキシでその手前に認証を置けます。

Authelia は OIDC プロバイダーとしても動作しますが、主な強みはリバースプロキシでの認証にあります。

Authelia と Authentik を併用する

OIDC や SAML に対応したアプリケーションには Authentik を、リバースプロキシでの認証が必要なアプリケーションには Authelia を使うことができます。

必ずしも両方は要りません。Authentik もプロキシベースのアプリケーション保護に対応しているので、Authelia を併用する意味があるのは、Authelia のリバースプロキシワークフローがスタックの特定の部分をよりきれいに解決する場合だけです。

よくある質問

Authentik は Keycloak より優れているか？

ほとんどのホームラボや小規模なセルフホストアプリケーションスタックでは、Authentik のほうが取っつきやすいです。管理ワークフローはアプリケーション、プロバイダー、グループ、ポリシーに焦点を当てており、IAM の複雑さを一度に大量にさらけ出しません。

より深いフェデレーション、レルムモデル、Authorization Services が明確に必要なら、Keycloak のほうが理にかなっています。よりシンプルなセルフホスト SSO には Authentik が堅実なデフォルトで、Keycloak はそうした追加の制御を必要とする環境に向いています。

ZITADEL は Keycloak より優れているか？

プロダクトを開発していて、API 駆動の ID、組織、マルチテナンシーが欲しいなら ZITADEL のほうが適しています。より深い認可モデル、広範なフェデレーション制御、あるいはすでに Keycloak を中心に構築された環境が必要なら Keycloak のほうが適しています。

Authentik と Authelia の違いは何か？

Authentik は、ユーザー、グループ、アプリケーション、プロバイダー、フロー、ポリシーを中心に構築された完全なアイデンティティプロバイダーです。アプリケーションは OIDC や SAML などのプロトコルで直接連携できます。

Authelia はリバースプロキシでの認証とアクセス制御が中心です。OIDC プロバイダーも含まれますが、主なユースケースはリバースプロキシでの保護のままです。

アプリケーションが IdP と直接連携するなら Authentik を、認証を主にトラフィックがアプリケーションに届く前に行う必要があるなら Authelia を選びましょう。

1 GB の VPS で Authentik を動かせるか？

サポートされる出発点としては動かせません。Authentik の現行 Docker Compose ドキュメントでは CPU 2 コア以上、RAM 2 GB 以上が必要です。現行のコアデプロイは Authentik サーバー、ワーカー、PostgreSQL を使用し、Redis は Authentik 2025.10 で完全に取り除かれました。

小規模なインストールでは 2 GB を最小限の出発点とし、他のサービスがマシンを共有する場合は余裕を足してください。

Vaultwarden は OIDC SSO に対応しているか？

はい。Vaultwarden は 2025 年 12 月のバージョン 1.35.0 で OpenID Connect SSO 対応を追加しました。Authentik、Keycloak、ZITADEL などの外部 OIDC プロバイダーが必要です。

具体的な設定はプロバイダーによって異なります。現行の Authentik リリースでは、文書化された連携にカスタムの検証済みメールスコープマッピング、offline_access、クライアント資格情報、Authentik アプリケーションの発行者 URL が含まれます。

IdP はアプリと同じ VPS で動かすべきか？

ダウンタイムが許容されるホームラボなら、同居も妥当でしょう。ビジネスクリティカルなアプリケーションでは、別の VPS がアイデンティティプロバイダーに独自のリソース予算を与え、アプリケーションサーバーを共有障害ドメインから外します。

それだけで高可用性が得られるわけではありませんが、アプリケーションサーバーの再起動、リソース問題、侵害が自動的に IdP を道連れにすることはなくなります。

最も使いやすいセルフホスト SSO はどれか？

既存のセルフホストアプリケーションを接続するほとんどの人にとって、Authentik が最も取り組みやすい出発点です。管理 UI により、アプリケーション、プロバイダー、グループ、ポリシーが、Keycloak の幅広いレルム・認可モデルよりも扱いやすくなっています。

リバースプロキシでの認証だけが必要なら、Authelia のほうが単純かもしれません。ID を設定する人が主に API 経由で作業する開発者なら、ZITADEL のほうが理にかなっています。