ここ2日間の顛末、認証基盤をつくろうとしてできず

IT

Auth0導入に挑戦して、やっぱり削除した話

AWS EC2 上の Docker 構成で WordPress を運用している中で、会員専用ページを作るために
Auth0 を試してみました。
しかし結果としては 「全ページが Auth0 ログインにリダイレクトされる」 状態になり、
最終的に撤去することに。
この 2 日間の顛末と、同じハマり方をしないためのメモです。

この記事のゴール

  • なぜ Auth0 を入れようとしたのか
  • どんな状態になって詰んだのか
  • どうやって管理画面に戻ったか
  • 最終的にどういう構成に落ち着いたか

1. なぜ Auth0 を試したのか

要求はシンプルで、「会員専用ページを作りたい」 というものでした。

  • WordPress 標準ログインだけだと、ユーザー管理がやや面倒
  • 理想は「メンバーは Auth0 でログイン」「管理者は通常の WP ログイン」

そこで Auth0 の公式プラグインを導入し、クライアント ID とドメインを設定してテストを開始しました。

2. 発生した問題

設定直後から、/wp-admin/ や /wp-login.php にアクセスしても、
すべて Auth0 のログイン画面に飛ぶようになりました。

つまり、WordPress 管理画面に入れない。

原因になっていた設定

  • Auth0 側で「Auto-login」「Force redirect」を ON にしていた
  • wps-hide-login プラグインも併用しており、標準のログイン URL がすぐに思い出せない

3. 緊急対応：管理画面に戻るまで

慌てつつも、Docker コンテナに入ってプラグインを止めるところから始めました。

① Auth0 / wps-hide-login プラグインを物理的に無効化

WordPress のプラグインディレクトリに入り、フォルダ名をリネームします。

cd /var/lib/docker/volumes/wordpress_wp_data/_data/wp-content/plugins

mv auth0 auth0.disabled
mv wps-hide-login wps-hide-login.disabled

② wp-config.php に緊急停止フラグを追加

Auth0 には、環境変数で動作をオフにできる AUTH0_ENV_OFF フラグがあります。
これを wp-config.php の末尾に追記。

define('AUTH0_ENV_OFF', true);

③ コンテナを再起動して動作確認

Docker コンテナを再起動します。

docker compose restart

その結果、

https://k-stone.click/wp-login.php

で WordPress 標準のログイン画面が復活 し、無事ダッシュボードに戻ることができました。

4. 最終判断：Auth0 を完全削除

いったん冷静に考えてみると、今回作りたかったのは
「シンプルなメンバー制サイト」 でした。

Auth0 のような大規模 ID 基盤は、ユーザー規模や要件に対して
明らかにオーバースペック。
そのため、Auth0 はいったん完全に撤去し、WordPress 標準ログイン運用に戻す 判断をしました。

削除時に行った作業（要約）

  • Auth0 関連フォルダを削除（plugins / mu-plugins）
  • wp-config.php の AUTH0_ENV_OFF 行を削除
  • .htaccess / nginx 設定 / DB 内を検索し、Auth0 関連の残骸を削除

最終確認に使ったコマンド

grep -RniE "auth0|oidc|oauth" /var/lib/docker/volumes/wordpress_wp_data/_data
docker compose exec nginx sh -lc \
'grep -RniE "auth0|authorize|openid|oidc|oauth" /etc/nginx /etc/nginx/conf.d 2>/dev/null'

上記で Auth0 関連の記述がすべて消えていることを確認し、
wp-login.php → WordPress 標準ログインへの完全復帰を確認しました。

5. 今回学んだこと

  • Auth0 の「強制リダイレクト」は強力すぎる：まずは別環境で実験するべき。
  • AUTH0_ENV_OFF は緊急停止フラグ：トラブル時の一時的な救済策になる。
  • バックアップは必須：mysqldump + tar で事前バックアップを取っておくと安心。
  • 本格的な認証基盤はインフラ層で扱う：
    たとえば Azure AD B2C + ALB (OIDC) のように、アプリの手前で統合認証する方が安全。

6. 今後の方針

現時点では、次のようなシンプル構成で運用する予定です。

  • WordPress 標準ログイン
  • ＋ 2 要素認証プラグイン
  • ＋ 会員限定プラグイン（Members / Content Control など）

小規模サイトであれば、このくらいの構成が
もっともシンプルで安定 していそうです。

次のステップとしては、
Azure AD B2C などのクラウド ID を「リバースプロキシ（nginx）」側で統合認証する
設計を試してみたいと考えています。
今回の反省として、アプリ側（WordPress）をあまり複雑にしない ことを意識します。

（記録日：2025年11月7日 / 環境：AWS EC2 Ubuntu / Docker Compose / nginx / WordPress）