認証まわりって、後回しにしがちですよね。
とりあえず動くものを作って、「認証はあとで足せばいい」と思っているうちに、社内ツールが5本になり、ユーザーアカウントが5倍に膨らんでいる。
そういう状況で「やっぱり一元管理したい」となったとき、選択肢をどう絞るかが悩みどころです。
セルフホスト型の認証基盤 Authentik を使って、既存の社内ツールに認証を後付けする手順を実務ベースで整理します。
Docker Compose での起動から OIDC 連携・プロキシプロバイダーによる認証後付けまで、手を動かしながら読める構成にしています。
「Auth0 は高い、でも自前実装は重い」という判断軸から出発して、Authentik が現実的な第三の選択肢になる理由を実装を通して見ていきます。
Auth0 は高い、自前実装は重い——Authentik が「第三の選択肢」になる理由
Auth0 や Okta はよくできたサービスです。
ドキュメントも充実しているし、SDK も揃っている。
ただ、MAU ベースの料金体系は、社内ツールのような「ユーザー数は少ないが機能要件は複雑」なケースと相性が悪いことがあります。
認証ログやユーザーデータを外部 SaaS に預けることへの抵抗感を持つ組織も少なくありません。
だからといって、認証を自前で実装するのはかなり重い選択です。
セッション管理・トークン検証・MFA・パスワードリセットフロー……これらをセキュアに作り込むには相当な工数がかかります。
「認証を作る」ことが本来の目的ではないプロジェクトで、そこに時間を使うのはもったいない。
Authentik は、そのあいだを埋める選択肢です。
オープンソースのセルフホスト型 IdP（Identity Provider）で、OIDC・SAML・LDAP といった標準プロトコルに対応しています。
自分のインフラで動かすのでデータは外に出ず、ライセンスコストもかかりません。
同じ文脈でよく名前が挙がるのが Logto です。
Logto は開発者体験を重視した設計で、セットアップが軽く、CIAM やマルチテナント向けのユースケースに強みがあります。
どちらも Auth0 の代替として機能しますが、目的が少し違います。
Authentik が特に光るのは、「既存のアプリに認証を後付けしたい」というシナリオです。
その中心にある機能が Flow エンジン と プロキシプロバイダー の2つ。
Flow エンジンは認証フローを細かくカスタマイズできる仕組みで、プロキシプロバイダーは認証コードを一切持たないアプリにも SSO を被せられる機能です。
この2つについては後の節で実務シナリオを交えて詳しく見ていきます。
Docker Compose で Authentik を立ち上げる
Authentik の公式ドキュメントは Docker Compose による起動手順を提供しています。
構成要素は server（認証 UI・API を提供するメインプロセス）、worker（バックグラウンドタスクを処理するプロセス）、postgresql（データストア）の3つです。
ひとつ重要な変化があります。
Authentik 2025.10 以降、Redis が不要になりました。
それまでキャッシュ・タスクキュー・WebSocket 接続に Redis を使っていた部分が、すべて PostgreSQL に統合されています。
ネット上の古いガイドには Redis コンテナが含まれているものが多いので、バージョンを確認しながら読む必要があります。
バージョンは固定することを強くおすすめします。
Authentik はメジャーバージョン間で破壊的変更が入ることがあり、latest を追いかけると思わぬところで詰まります。
以下は 2025.10 以降を想定した最小構成の例です。
# docker-compose.yml（要点抜粋）
services:
postgresql:
image: docker.io/library/postgres:16-alpine
restart: unless-stopped
healthcheck:
test: ["CMD-SHELL", "pg_isready -d $${POSTGRES_DB} -U $${POSTGRES_USER}"]
interval: 5s
timeout: 5s
retries: 5
environment:
POSTGRES_PASSWORD: ${PG_PASS}
POSTGRES_USER: ${PG_USER:-authentik}
POSTGRES_DB: ${PG_DB:-authentik}
volumes:
- database:/var/lib/postgresql/data
server:
image: ghcr.io/goauthentik/server:2025.10.2
restart: unless-stopped
command: server
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
volumes:
- ./media:/media
- ./custom-templates:/templates
ports:
- "9000:9000"
depends_on:
postgresql:
condition: service_healthy
worker:
image: ghcr.io/goauthentik/server:2025.10.2
restart: unless-stopped
command: worker
environment:
AUTHENTIK_SECRET_KEY: ${AUTHENTIK_SECRET_KEY:?secret key required}
AUTHENTIK_POSTGRESQL__HOST: postgresql
AUTHENTIK_POSTGRESQL__USER: ${PG_USER:-authentik}
AUTHENTIK_POSTGRESQL__NAME: ${PG_DB:-authentik}
AUTHENTIK_POSTGRESQL__PASSWORD: ${PG_PASS}
volumes:
- ./media:/media
depends_on:
postgresql:
condition: service_healthy
volumes:
database:
# .env の最小構成
PG_PASS=your_postgres_password
PG_USER=authentik
PG_DB=authentik
AUTHENTIK_SECRET_KEY=your_generated_secret_key
AUTHENTIK_SECRET_KEY は必須項目で、未設定のままだと起動時にエラーが出て止まります。
生成には openssl コマンドが便利です。
openssl rand -base64 60
出力された文字列をそのまま .env に貼り付ければ OK です。
起動後、ブラウザで http://localhost:9000/if/flow/initial-setup/ にアクセスすると、管理者アカウントの初期設定画面が表示されます。
ここで管理者のメールアドレスとパスワードを設定すれば、Admin UI にログインできます。
worker コンテナが起動しない場合は、まず以下のコマンドでログを確認してください。
docker compose logs worker
SECRET_KEY が .env から正しく読み込まれていない・postgresql の healthcheck が通る前に worker が起動しようとしている、というケースが多いです。
9000 番ポートが別プロセスに使われているときは .env に COMPOSE_PORT_HTTP=9080 のように書けば回避できます。
OIDC プロバイダーを設定して既存 Web アプリと連携する
Authentik の Admin UI を開くと、左メニューに「Applications」と「Providers」という項目があります。
この2つの関係を最初に整理しておくと、その後の設定がぐっとわかりやすくなります。
Provider は「どの認証方式を使うか」の定義です。
OIDC なのか SAML なのか、どのスコープを返すか、トークンの有効期限はどうするか、といった認証プロトコルレベルの設定がここに入ります。
Application は「誰がアクセスできるか」のポリシー単位です。
どの Provider を使うか・どのグループにアクセスを許可するか・アイコンや説明文といった UI 上の情報もここで管理します。
Provider を作ってから Application に紐付ける、という順番で設定します。
OIDC Provider を作成する際に設定する主な項目はこの3つです。
- Client ID / Client Secret: 自動生成されます。連携先アプリに渡す値です。
- Redirect URIs: 認証後にリダイレクトされる URL。NextAuth.js なら https://your-app.example.com/api/auth/callback/authentik のような形式になります。
- Scopes: openid・email・profile を最低限含めます。
NextAuth.js と連携する場合、providers の設定は以下のようになります。
// pages/api/auth/[...nextauth].ts
import NextAuth from "next-auth";
export default NextAuth({
providers: [
{
id: "authentik",
name: "Authentik",
type: "oauth",
wellKnown:
"https://authentik.example.com/application/o/your-app-slug/.well-known/openid-configuration",
clientId: process.env.AUTHENTIK_CLIENT_ID,
clientSecret: process.env.AUTHENTIK_CLIENT_SECRET,
authorization: { params: { scope: "openid email profile" } },
idToken: true,
profile(profile) {
return {
id: profile.sub,
name: profile.name,
email: profile.email,
image: profile.picture,
};
},
},
],
});
wellKnown の URL にある your-app-slug は、Authentik 側で Application を作成したときに設定したスラッグです。
この URL にアクセスすると OIDC Discovery エンドポイントが返ってくるので、NextAuth.js が自動的に必要なエンドポイント情報を取得してくれます。
ここで Flow エンジン の話を入れておきます。
Authentik の認証フローは「Flow → Stage → Policy」という構造で成り立っています。
Flow がフロー全体の器で、Stage が各ステップ（パスワード入力・MFA 確認・招待コード検証など）、Policy がそのステップを実行する条件の制御です。
ユーザー招待フローを作りたい場合は Invitation Stage を使います。
管理者が招待リンクを発行し、そのリンクを踏んだユーザーだけが登録フローに進める、という仕組みです。
Flows & Stages のメニューから Enrollment 用の Flow を作成し、Invitation Stage と User Write Stage をバインドしていく形で組み立てます。
招待なしでの登録を防ぎたいなら、Invitation Stage の「Continue flow without invitation」のチェックを外すだけで制御できます。
このあたりの柔軟さが、Authentik の Flow エンジンの実用的なところです。
認証コードのないアプリに認証を「後付け」する——プロキシプロバイダーの仕組み
Authentik の中でも特に実務で刺さる機能が、プロキシプロバイダー（Forward Auth モード）です。
一言で言うと、「認証の仕組みを一切持たないアプリの前に Authentik を立たせて、認証済みのリクエストだけを通す」という動きをします。
アプリ側のコードには一切手を入れません。
リバースプロキシ（Nginx Proxy Manager など）が認証の判断を Authentik に委譲する、というアーキテクチャです。
リクエストの流れはこうなります。
- ユーザーがブラウザから社内ツールの URL にアクセスする
- Nginx Proxy Manager（NPM）がリクエストを受け取り、Authentik の Forward Auth エンドポイントに確認リクエストを投げる
- Authentik がセッションを確認し、認証済みなら 200 を返す。NPM は元のアプリにリクエストを転送する
- 未認証の場合、Authentik は 401 を返し、NPM がユーザーを Authentik のログイン画面にリダイレクトする
- ログイン完了後、元の URL に戻ってくる
この仕組みを動かすには、Authentik 側で Outpost を設定する必要があります。
Outpost は Authentik のプロキシ機能を実際に処理するコンポーネントで、シンプルな構成なら Embedded Outpost（Authentik サーバー内蔵）で十分です。
NPM 側の設定は、対象のプロキシホストの Advanced タブにある「Custom Nginx Configuration」に Forward Auth の設定を追記します。
Authentik の Admin UI で Outpost を開き、対象 Provider を選ぶと「Nginx (Proxy Manager)」向けのコードスニペットが表示されるので、それをそのままコピーして貼り付けるだけです。
このユースケースが特に効くのは、Grafana OSS・静的サイト・古い社内ツールのように「認証機能を後から追加するのが難しい or コストが高い」アプリです。
Grafana は OIDC 連携もできますが、OSS 版では機能制限があります。
プロキシプロバイダーを使えば、Grafana 側の設定をほぼ触らずに SSO を被せられます。
Flow エンジンとの組み合わせも効いてきます。
プロキシプロバイダーに紐付ける認証 Flow をカスタマイズすることで、特定グループのユーザーだけ通す・MFA を必須にする、といった制御が追加できます。
認証基盤を一箇所に集約しながら、アプリごとにポリシーを変えられる——これが Authentik の設計思想です。
Logto と使い分けるための判断軸
Logto と Authentik はどちらも Auth0 の代替として語られますが、設計の重心が違います。
Logto は 開発者体験 を前面に出しています。
セットアップが軽く、管理 UI がシンプルで、SDK も整っている。
CIAM やマルチテナントの SaaS を作るときに、素早く立ち上げられる点が強みです。
Authentik は 柔軟性と後付け に強みがあります。
Flow エンジンで認証フローを細かく制御でき、プロキシプロバイダーで認証コードを持たないアプリにも SSO を被せられる。
その分、設定の複雑さは Logto より上です。
Flow・Stage・Policy・Outpost といった概念を理解するまでに、多少の学習コストがかかります。
決定的な差になるのが、プロキシプロバイダーの有無です。
Logto にはこの機能がありません。
「認証を後付けしたい」「既存アプリのコードに触れずに SSO を被せたい」という要件が出た瞬間に、Authentik 一択になります。
判断軸を整理するとこうなります。
- プロキシ認証が必要か: 必要なら Authentik。Logto では対応できない
- Flow のカスタマイズ幅: 招待フロー・条件分岐・MFA の細かい制御が必要なら Authentik。シンプルな OIDC 連携で十分なら Logto でも十分
- セットアップの速さ: 素早く立ち上げたいなら Logto。設定の複雑さを許容できるなら Authentik
- CIAM・マルチテナント SaaS: Logto の方が向いている
- データ主権: どちらもセルフホスト可能。この軸では差はない
「社内ツールを一元ログイン化したい」という要件であれば、Authentik を第一候補にするのが自然です。
プロキシプロバイダーで認証コードのないツールも巻き込めるし、Flow エンジンで組織のポリシーに合わせた認証フローを組める。
設定の複雑さはありますが、一度構築してしまえば運用は安定します。
逆に、エンドユーザー向けのプロダクトで認証を素早く足したいなら、Logto を先に検討する方が現実的です。
認証基盤は「作り直しにくいもの」の筆頭なので、要件の解像度を上げてから選ぶのが一番の近道だと思います。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援・DX 推進に取り組んでいます。
Authentik のような OSS ツールの導入支援や、社内認証基盤の設計・構築もご相談いただけます。
気になることがあれば、お気軽に お問い合わせ からどうぞ。