Infrastructure & Engineering

AuthentikからPocketIDへ：パスキー導入と軽量化で実現する快適なHomeLab認証

Otama
5分で読了
Progress 9 / 18
目次

HomeLabの認証基盤をAuthentikからPocketIDへ移行しました。

これまでは機能が豊富なAuthentikを使っていましたが、個人で運用するには設定項目が多く、リソース消費も無視できないレベルになっていました。今回の移行の最大の目的は、認証の「軽量化」と「パスキー（Passkeys）の導入」です。

移行の決定打はパスキーの導入

PocketIDへ移行した一番の理由は、パスキーを非常に簡単に導入できる点にあります。

パスキーは、スマートフォンの生体認証やセキュリティキーなど、パスワードレスなデバイスがあれば利用できるモダンな認証方式です。PocketIDではこの設定が非常にスムーズで、一度登録してしまえば、ログインのたびに複雑なパスワードを入力したり、MFAアプリを開いたりする手間から解放されます。

シンプルな機能と使いやすいUI

Authentikに比べて機能は限定的ですが、それが逆にメリットとして働いています。

  • 迷わない設定: 機能が絞り込まれているため、「どのアドバンス設定をいじればいいのか」と迷うことがなくなりました。
  • 直感的なUI: UIが非常にシンプルかつモダンにデザインされており、ユーザー管理やクライアント設定がストレスなく行えます。
  • 低リソース: Kubernetes上で稼働させていますが、Authentikに比べてリソース消費が劇的に抑えられています。

Kubernetesへのデプロイ構成

PocketIDをKubernetes上にデプロイした際のマニフェスト例です。非常にシンプルに構築できます。

Deployment

データベースの接続設定やAPP_URLなどを環境変数で指定します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pocket-id
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: pocket-id
          image: "pocketid/pocket-id:latest"
          env:
            - name: APP_URL
              value: "https://id.example.com"
            - name: TRUST_PROXY
              value: "true"
            - name: FILE_BACKEND
              value: "true"
            - name: DB_CONNECTION_STRING
              valueFrom:
                secretKeyRef:
                  name: pocket-id-secrets
                  key: DB_CONNECTION_STRING

Service

内部通信用にServiceを作成します。デフォルトでは1411ポートを使用します。

apiVersion: v1
kind: Service
metadata:
  name: pocket-id
spec:
  type: ClusterIP
  ports:
    - port: 80
      targetPort: 1411
  selector:
    app: pocket-id

OIDC連携の共通パターンと注意点

AuthentikからPocketIDへの移行にあたって、各種アプリケーション（Gitea, Paperless-ngx, Vaultwarden等）との連携も行いました。多くのアプリに共通する「ハマりどころ」を紹介します。

Discovery URLの指定

多くのアプリでは .well-known/openid-configuration を自動で見つけに行きますが、明示的に指定が必要な場合は https://id.example.com/.well-known/openid-configuration となります。

Issuer URLの末尾スラッシュ

Issuer URLの末尾に / を含めるかどうかで、バリデーションエラーになることがあります。環境全体で統一（なしが推奨）しておくのがトラブルを避けるコツです。

既存ユーザーのOIDC切り替え

既に別のOIDCプロバイダ（Authentik等）で登録済みのユーザーがいる場合、連携を解除せずに新しいプロバイダに切り替えるとログイン不能になるケースがあります。多くのOSSでは「一つのアカウントに複数のOIDCを紐付ける」ことが難しいため、**「旧プロバイダの連携解除 → 新プロバイダでの初回ログイン」**という手順を徹底するのがスムーズな移行のコツです。

今後の展望：TinyAuthとTraefikへの移行

今回の移行で課題として残ったのが、OIDCにネイティブ対応していないアプリケーションの保護です。Authentik Outpostのようなプロキシ認証機能がPocketIDには備わっていないため、別途「TinyAuth」を導入してこの穴を埋める計画です。

TraefikのMiddleWareと併せて利用することで簡単にForwardAuthが可能になるため、これを機にリバースプロキシ自体もIngress-NginxからTraefikへ一気にリプレイスしてしまおうと考えています。

この移行を行えば、ちょうど2026年3月に予定されている「Ingress-Nginxのサポート終了問題」もついでに解決できるため、HomeLab全体の構成をよりモダンかつ持続可能な形へアップデートできる絶好の機会になりそうです。

まとめ

認証基盤を軽量なPocketIDに変えたことで、パスキーという強力な武器と、迷いのない運用環境を手に入れることができました。HomeLabという限られたリソースで、実用性とセキュリティ、そして使い勝手のバランスを取るには非常に良い選択肢だと感じています。

関連記事