Authentikとは？Docker Composeでの起動手順とOIDC連携・Blueprints・Keycloakとの選び分け【2026年11月】

Authentikは、ログイン画面・ユーザー管理・トークン発行を自社サーバーで受け持つオープンソースの認証基盤（IdP）です。OIDC、SAML、LDAP、SCIM、RADIUSを1つの製品で提供し、社内向けのシングルサインオンにも自社サービスの会員ログインにも使えます。この記事では、公式のcompose.ymlで手元に立ち上げる手順、OIDCプロバイダーを作って自社アプリをつなぐ設定、Blueprintsで設定をYAMLに残す方法を確認できる、コマンド付きの解説です。そのうえで、無料のOSS版とEnterpriseの機能差を整理し、Keycloakとどちらを選ぶかを条件付きで言い切ります。

まとめ：Authentikを採用する条件とKeycloakやIDaaSを選ぶ場面の結論

社内の業務SaaSや自社システムへのシングルサインオンをセルフホストで組みたい、しかもLDAPやRADIUSで古い機器もまとめて認証したい案件なら、Authentikは第一候補に入ります。OSS版は無料でユーザー数の上限がなく、Docker Composeなら3コンテナで管理画面まで開けます。2026年11月2日時点の最新版は2026.8系（2026.8.5・10月21日公開）です。

一方で、Java系の運用体制がすでにあり大規模な会員基盤を組む案件、24時間のベンダーサポートが調達条件の案件は、Keycloak（Red Hat build of Keycloak）を先に検討してください。Google WorkspaceやMicrosoft Entra IDへのユーザー同期が必須なら、その機能はAuthentikでは有料のEnterpriseに入ります。

Authentikの仕組み：3コンテナの役割分担とアウトポストによる認証処理

Authentikを動かす部品は、画面とAPIを返すserver、裏側の処理を担うworker、データを保存するPostgreSQLの3つです。

server・worker・PostgreSQLの役割と2025.10でのRedis廃止

公式のcompose.ymlでは、serverとworkerが同じイメージghcr.io/goauthentik/server:2026.8.5を使い、起動コマンドだけをserverとworkerで分けています。データベースはpostgres:16-alpineです。

workerは表に示したBlueprintsの適用も担当します。以前の構成にはRedisもありました。2025.10のリリースノートに「authentik no longer uses Redis at all.」とあり、キャッシュやWebSocketの処理はPostgreSQLへ移っています。古い解説記事のRedis入り構成は、2025.10以降には当てはまりません。PostgreSQLへの接続数が増える点は、マネージドDBの接続上限を決めるときに見込んでおきます。

OIDC・SAMLはserverが直接処理しLDAPやProxyはアウトポストで動く

アプリから見ると、AuthentikはOAuth 2.0とOpenID Connectの認可サーバーで、SAMLのIdPでもあります。この2つはserverが直接処理するため、追加の部品は要りません。IDトークンの検証はOIDCのIDトークン検証とOAuth 2.0との違いと同じ手順で実装でき、SAMLの流れはSAMLの認証フローとIdP・SPの仕組みで整理しています。

LDAP、Proxy、RADIUS、RAC（ブラウザからのRDP・SSH接続）は別です。アウトポストという別サービスとして動き、認証APIに届く場所ならどこにでも置けます。ログイン機能を持たない社内ツールの前にProxyアウトポストを立てて認証を挟む、という使い方はKeycloak単体では難しく、Authentikを選ぶ理由になりやすい部分です。

Docker ComposeでAuthentik 2026.8系を起動し管理画面を開く手順

ここからは手元のLinuxマシンにAuthentikを立ち上げます。公式のDocker Compose手順が示す要件は、CPU 2コア以上、メモリ2GB以上、Docker Compose v2またはPodmanです。

compose.ymlの取得とDBパスワード・署名用秘密鍵を生成するコマンド

compose.ymlを取得し、データベースのパスワード（PG_PASS）と署名用の秘密鍵（AUTHENTIK_SECRET_KEY）を.envに書き込んでから起動します。秘密鍵はセッションやトークンの署名に使われるため、後から変えるとログイン中の全員が無効になります。

mkdir authentik && cd authentik
wget https://docs.goauthentik.io/compose.yml

# PostgreSQLのパスワードと秘密鍵を生成して.envへ追記
echo "PG_PASS=$(openssl rand -base64 36 | tr -d '\n')" >> .env
echo "AUTHENTIK_SECRET_KEY=$(openssl rand -base64 60 | tr -d '\n')" >> .env

# 80番・443番で公開したい場合だけ追記する
# echo "COMPOSE_PORT_HTTP=80" >> .env
# echo "COMPOSE_PORT_HTTPS=443" >> .env

docker compose pull
docker compose up -d
docker compose ps

compose.ymlの中のイメージタグは、取得した時点の最新版に固定されています。AUTHENTIK_TAGを.envで上書きしない限り、勝手に新しい版へは上がりません。PostgreSQLのパスワードは99文字以内という制約があり、上の生成コマンドならその範囲に収まります。

初期セットアップでakadminのパスワードを設定する手順と2つの注意点

起動したらブラウザでhttp://<サーバーのIP>:9000を開きます。既定の管理ユーザーakadminのパスワード設定を求められ、設定後に管理画面へ入れます。

注意点は2つあります。1つ目はタイムゾーンです。Authentikは内部処理をすべてUTCで行うため、コンテナの/etc/localtimeをマウントで日本時間に変えると、OAuthやSAMLの検証が失敗すると公式が書いています。2つ目はworkerの権限です。workerはrootで動き、/var/run/docker.sockをマウントしています。アウトポストをDocker上に自動で立てるための設定なので、使わない本番環境ではマウントを外す判断も検討してください。

OIDCプロバイダーを作成して自社アプリのログインをAuthentikへ委ねる手順

Authentikでアプリをつなぐ単位は「プロバイダー」と「アプリケーション」の組です。プロバイダーが認証方式（OIDCやSAML）を、アプリケーションが利用者から見た入口を表します。

管理画面でOIDCプロバイダーとアプリケーションを登録する4ステップ

1. 管理画面の「Applications」から新規作成を選び、名前とslug（例：my-app）を入れる
2. プロバイダーの種類で「OAuth2/OpenID Provider」を選ぶ
3. 認可フローにdefault-provider-authorization-implicit-consentを選び、Client typeをConfidentialにする
4. Redirect URIに自社アプリのコールバックURL（例：https://app.example.com/callback）をStrictで登録し、表示されたClient IDとClient Secretを控える

Redirect URIは正規表現でも登録できますが、ワイルドカードの書き方を誤るとトークンを外部へ流す穴になります。本番ではStrictの完全一致で、使うURLだけを並べるのが安全です。

OpenID Configurationのエンドポイントで連携先の設定値を確かめる

OAuth 2.0 providerのドキュメントによると、認可・トークン・UserInfoの3つは全プロバイダー共通のURLで、JWKSとOpenID Configurationはアプリのslugごとに分かれます。

# slugがmy-appの場合。issuer・各エンドポイント・対応スコープが返る
curl -s https://auth.example.com/application/o/my-app/.well-known/openid-configuration | jq '{issuer, authorization_endpoint, token_endpoint, jwks_uri}'

# 期待される値の形
# authorization_endpoint: https://auth.example.com/application/o/authorize/
# token_endpoint:         https://auth.example.com/application/o/token/
# jwks_uri:               https://auth.example.com/application/o/my-app/jwks/

多くのOIDCライブラリは、このOpenID ConfigurationのURLをissuerとして渡すだけで残りを自動で読み込みます。対応フローは認可コード、クライアントクレデンシャル、デバイスコード、RFC 8693のトークン交換、リフレッシュトークンです。署名鍵を指定しないとIDトークンはクライアントシークレットによるHS256署名になるため、複数のアプリで検証するならプロバイダー設定で証明書を選びRS256にそろえます。トークンの中身の読み方はJWTの構造と署名検証の仕組みが参考になります。

Blueprintsで設定をYAML化しプロバイダーとアプリを再現可能にする方法

管理画面で作った設定は、検証環境と本番環境で手作業がずれる原因になります。Authentikには設定をYAMLで書いて自動適用するBlueprintsという仕組みがあります。

OIDCプロバイダーとアプリケーションを1ファイルで作るBlueprint例

前章の登録内容をBlueprintにすると次のようになります。File structureのドキュメントどおり、version・metadata・entriesの3要素で書きます。

version: 1
metadata:
  name: my-app-oidc
entries:
  - model: authentik_providers_oauth2.oauth2provider
    id: my-app-provider
    identifiers:
      name: my-app-provider
    attrs:
      authorization_flow: !Find [authentik_flows.flow, [slug, default-provider-authorization-implicit-consent]]
      invalidation_flow: !Find [authentik_flows.flow, [slug, default-provider-invalidation-flow]]
      client_type: confidential
      redirect_uris:
        - matching_mode: strict
          url: https://app.example.com/callback
  - model: authentik_core.application
    identifiers:
      slug: my-app
    attrs:
      name: My App
      provider: !KeyOf my-app-provider

!KeyOfは同じファイル内のidを参照し、!Findは既存のフローをslugで探します。stateを省略するとpresent扱いになり、無ければ作成、あればattrsの値による上書きです。1つのBlueprintは1つのDBトランザクションで適用されるため、途中でエラーが出れば全体が取り消されます。

workerへのマウントと60分ごとの自動検出、手動変更との衝突

Blueprintsはコンテナ内の/blueprints配下にある.yamlが自動で検出されます。compose.ymlのworkerに./custom-blueprints:/blueprints/customのボリュームを足し、そこにファイルを置く運用が扱いやすい方法です。

ファイルの変更は監視されて適用されるほか、ディレクトリ全体の再スキャンが既定で60分ごとに走ります。落とし穴は手動変更との衝突です。presentの項目を管理画面で直しても、次の適用でBlueprintの値に戻ります。管理画面での調整を残したい項目はstate: createdにして、初回作成だけをBlueprintに任せてください。

Authentikの料金とライセンス：無料のOSS版とEnterpriseの機能差

Authentikは本体がMITライセンスで、一部の機能だけが有料のEnterpriseに分かれる構成です。

OSS版・Enterprise・Enterprise Plusの価格と有料になる主な機能

公式の料金ページの内容を2026年11月2日時点で整理しました。

Open Sourceでは、表の3方式に加えてSCIM・RADIUS・RACも使えます。Enterpriseの表にあるEntra ID・Google Workspaceは、これらのサービスとの連携機能を指します。

Enterpriseには社内ユーザーとは別に、外部ユーザーを1人月0.02ドルで数える料金があり、サービスアカウントは無料です。会員サイトのように外部ユーザーが10万人いる場合は、外部ユーザー分だけで月2,000ドルの計算になります。OSS版のサポートはDiscordのコミュニティのみで、チケット制のサポートは年額1,000ドルを超える契約から付きます。

MITライセンスの範囲とenterpriseディレクトリの扱い

リポジトリのLICENSEでは、authentik/enterprise/配下は別ライセンス、website/配下はCC BY-SA 4.0で、それ以外がMITと定められています。同じイメージにEnterpriseのコードも入っていますが、ライセンスキーを入れなければ有効になりません。

注意したいのはSCIMです。SCIMのプロバイダー自体はOSS版に含まれ、SCIMの接続先へOAuth2で認証する機能だけがEnterpriseです。「SCIM対応が必須だから有料」と早合点せず、接続先のSaaSがどの認証方式を求めるかを先に確かめてください。

AuthentikとKeycloakの選び分け：採用すべき条件と見送る場面の判断

セルフホストできる認証基盤の比較では、必ずKeycloakが並びます。Keycloakは2026年11月2日時点で26.8.1が最新です。ここでは両者の分かれ目を言い切ります。

Authentikを採用すべき条件：社内SSOを少人数で運用し古い機器も束ねる

採用するのは、社内向けのシングルサインオンが主目的で、運用担当が1〜2人、しかもLDAPやRADIUSでしか認証できないNASやVPN機器、ログイン機能の無い社内ツールまでまとめたい案件です。Authentikならアウトポストでこれらを無料の範囲で扱え、Blueprintsで設定をGit管理できます。GitHubのリポジトリはスター数が約2.6万で、2026.8系と2026.5系に同じ日にパッチが出るなど更新も止まっていません。

Keycloakでも同じことはできますが、Proxyによる認証の前置きは別製品の組み合わせになり、realmやクライアントの設定項目も多くなります。運用の手間の違いはKeycloakのデータベース設定と権限モデルと見比べると具体的になります。

Authentikを見送る場面：大規模会員基盤・ベンダー保守必須・Entra連携

見送るのは次のどれかに当てはまる案件です。数十万人規模の会員基盤で、Java系の運用ノウハウを持つチームがいる。官公庁や大企業の調達で、国内代理店の保守契約や商用サポートが条件になっている。Microsoft Entra IDやGoogle Workspaceへのユーザー同期が必須なのに、Enterpriseの予算が取れない。いずれもKeycloakの方が実績と調達面で有利で、比較の詳細はKeycloakとは：Auth0・Okta・Cognitoとの比較にまとめています。

会員基盤をAPIから操作する設計を重視するならFusionAuthのテナント設計とKeycloakとの選び分け、ログイン画面を自前で作り認可だけを任せたいならOry Hydraのログイン・同意画面の実装も比較に入ります。既存の社内ディレクトリの移行や、複数システムの統合ログインまで含めて基盤を選びたい場合は、認証基盤・ID管理システム開発として製品選定の段階から相談を受けています。

Authentikの導入前によくある質問：本番運用・更新・移行と日本語対応

Authentikの導入検討でよく出る質問に、2026年11月2日時点の公式情報をもとに答えます。

Authentikは無料でどこまで使えますか？

OSS版は無料で、ユーザー数の上限もありません。OIDC・SAMLによるシングルサインオン、LDAP・RADIUS・Proxyのアウトポスト、ブラウザからのRDP・SSH接続、SCIMプロバイダー、TOTPやパスキーによる多要素認証はこの範囲で使えます。有料になるのは、Microsoft Entra IDやGoogle Workspaceへの同期、mTLSのクライアント証明書認証、拡張監査ログ、ベンダーのチケット制サポートなどです。

Authentikのバージョン番号はどう読み、どの頻度で更新されますか？

版番号は「年.月.パッチ」の形で、2026.8が表すのは2026年8月の機能リリースです。GitHubのReleasesでは、2026.8.0が8月18日、2026.8.4が10月14日、2026.8.5が10月21日に公開されています。機能リリースは2026.2、2026.5、2026.8とおよそ3か月ごとで、9月9日には2026.8.2・2026.5.7・2026.2.7が同日に出るなど、旧系統にもパッチが届きます。更新時は新しいcompose.ymlを取り直し、リリースノートの破壊的変更を読んでから上げてください。

本番環境でもDocker Composeで運用してよいですか？

小規模な社内SSOなら運用できますが、PostgreSQLを同じホストに置いたままにするのは避けてください。本番ではデータベースを冗長化されたマネージドサービスへ分け、バックアップの対象をDBと./data・./certsのディレクトリに絞ります。Kubernetesで運用する場合は公式のHelmチャートが用意されています。

KeycloakからAuthentikへ移行できますか？

できますが、移行ツールは公式に用意されていません。ユーザーはAPIやBlueprintsで作成でき、移行期間はKeycloakをOpenID Connectのソース（外部IdP）として登録し、Keycloak経由のログインを受け付ける方法もとれます。難しいのはパスワードと連携アプリの切り替えです。アプリごとにissuerのURLが変わるため、OIDCの設定を1本ずつ差し替える計画を立て、移行期間は両方の基盤を並行稼働させるのが現実的です。

Authentikの管理画面やログイン画面は日本語で表示できますか？

画面の表示言語はブラウザの言語設定に合わせて切り替わり、ユーザーごとの設定画面からも選べます。翻訳はコミュニティによるもので、一部の項目は英語のままです。ログイン画面の文言やロゴは、compose.ymlでマウントされるcustom-templatesや管理画面のブランド設定で差し替えられます。

関連記事

• Keycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】：Authentikと並ぶOSSの認証基盤の比較と導入判断。
• FusionAuthとは？Docker Composeでの起動手順とテナント設計・料金・Keycloakとの選び分け【2026年10月】：同じくセルフホストできる会員基盤の起動手順と料金。
• シングルサインオン（SSO）とは？4つの実現方式とIDトークン検証・IdP選定を実装手順で解説：Authentikで組むSSOの方式と、IdPを選ぶ前の前提整理。
• IDaaSとは？SSO・IdPとの違いとSAML・OIDC・SCIM連携を実装視点で解説：セルフホストかIDaaSかを決めるときの比較軸。
• CIAMとは？顧客ID基盤の設計と会員DB移行・同意管理を実装視点で解説：社内SSOではなく顧客向けの会員基盤を組む場合の設計。