Zenn
🔏

【Laravel】一般ユーザーと管理者画面の認証を分離する際のポイント

に公開
Laravel
auth
tech

はじめに

Laravelでは認証機能が充実しており、管理画面と一般ユーザー画面の共存は比較的簡単に実装できます。
しかし、プロジェクトが中規模以上になる場合は、認証画面を分離したほうが望ましいです。

本記事では、Laravelで「管理者画面とユーザー画面を認証から完全に分離」する際の各関連ファイルの見直すポイントを解説します。

対象者

  • 管理者とユーザーの画面を役割ベースで明確に分離したいエンジニア
  • Laravel認証構成を中規模以上のアプリケーション向けに拡張したい方
  • Laravelでの認証・ルーティング周りの概念を学びたい方

構成要素

これらはLaravelにおける認証構成の核となる要素です。

仕組み

これらの仕組みは連携して動作しており、責務を正しく分離することで、より安全で保守性の高いアプリケーション構成を実現できます。

用語 説明
Kernel（カーネル） 全ルートに共通して適用されるミドルウェアや、ミドルウェアグループを管理する中心的な設定クラス（Http\Kernel.php）
Guard（ガード） 認証処理を切り替えるための仕組み。ユーザー種別（例：一般ユーザー、管理者）ごとにセッションや認証ロジックを分ける役割を持つ
Middleware（ミドルウェア） リクエストとレスポンスの処理の前後に実行されるフィルター機構。アクセス制限やリダイレクト判定に活用される
ServiceProvider（サービスプロバイダ） アプリケーション起動時に各種初期化処理（例：ルート定義、イベント登録、ビュー共有など）を行うクラス

主要なファイル/ディレクトリ

Laravelで管理者とユーザーの認証を分離する際に関わる主要なファイルやフォルダ構成と、その役割を簡単に説明します。
これらのファイルを理解することで、Laravelにおける認証構成の仕組みがより明確になると思います。

ファイル・ディレクトリ 役割
routes/web.php / routes/admin.php 一般ユーザー用・管理者用のルートを定義するファイル
config/auth.php Guard や Provider を定義する設定ファイル
app/Http/Middleware/ ミドルウェアを定義・設置する場所。認証ロジックなどを記述
app/Http/Kernel.php 全体のミドルウェア登録・ルーティンググループの定義を行うカーネルクラス
app/Http/Controllers/Auth/ ログイン・ログアウト・登録・パスワードリセットなど、認証に関する処理を担うコントローラー群。ユーザーと管理者で分離して持つことが望ましい。例：LoginController.php, AdminLoginController.php
app/Http/Requests/ フォームリクエストバリデーション用クラスを格納。例えば、ログイン時の入力チェックなど。役割ごとに AdminLoginRequest や UserLoginRequest を分けることで、責務が明確になります。
app/Providers/ 各種初期化や共通ロジックをまとめる ServiceProvider の設置場所

Laravelで認証を分離する際に起きやすい問題

Laravelでは認証機能が強力に整備されており、一般ユーザー画面と管理画面を共存させたシステムを構築しやすい設計になっていますが、実務の現場では、次第に次のような課題が生じることがあります。

  • ミドルウェアやカーネルが肥大化し、役割が不明瞭になる
  • Viewやルーティングが煩雑になり、保守性が落ちる
  • Kernelで定義された共通ミドルウェアがすべてのルートに適用されてしまい、管理者ルートに干渉する

複数のGuard を設定する際に起きやすい問題

特に、複数のGuardをauth.phpで設定することができますが、以下のような実装上の曖昧さ生じやすいです。

  • authミドルウェアがwebガード前提で動作してしまい、意図通りにadminガードが効かない
  • Kernelで定義された共通ミドルウェアがすべてのルートに適用されてしまい、管理者ルートに干渉する
  • 管理者用ログイン処理とユーザー用ログイン処理が曖昧で、セッションが干渉する

よくある実装例

web.php
Route::middleware(['auth', 'admin'])->group(function () {
    Route::get('/admin/dashboard', 'AdminController@index');
});

見直すポイント

上記のような問題を起こさないために以下のようなポイントに注意すると良いと思います。

1. Guardの定義を分離して行う

config/auth.phpにて、ユーザーと管理者で使用するGuard・Providerを分離して定義します。

auth.php
'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],
    'admin' => [
        'driver' => 'session',
        'provider' => 'admins',
    ],
],

2. カスタムMiddlewareを作成

管理者のみがアクセスできるルートを保護するカスタムミドルウェアを用意します。

$ php artisan make:middleware EnsureUserIsAdmin
EnsureUserIsAdmin.php
public function handle($request, Closure $next)
{
    if (!Auth::guard('admin')->check()) {
        return redirect('/admin/login');
    }
    return $next($request);
}

3. Kernelでのミドルウェアを登録する

App\Http\Kernelにミドルウェアを適切に登録・分類します。

Kernel.php
protected $routeMiddleware = [
    'auth.admin' => \App\Http\Middleware\EnsureUserIsAdmin::class,
];

必要に応じて$middlewareGroupsをuserやadmin向けに定義し、干渉を避ける設計にします。

4. RouteServiceProviderでのルーティングを分離する

routes/web.phpとroutes/admin.phpを完全に分離し、ServiceProviderで設定を切り替えます。

RouteServiceProvider.php
Route::middleware('web')
    ->namespace($this->namespace)
    ->group(base_path('routes/web.php'));

Route::prefix('admin')
    ->middleware('web')
    ->namespace($this->namespace . '\\Admin')
    ->group(base_path('routes/admin.php'));

5. ServiceProviderでのロール別で初期化処理する

ServiceProviderでは、ロールに応じた共通ロジックを役割別に分離して管理できます。
このように責務を切り出すことで、開発者が構造を理解しやすくなり、保守性が向上します。

AdminServiceProvider
public function boot()
{
    View::composer('admin.*', function ($view) {
        // 管理者向け共通処理
    });
}

おわりに

Laravelは柔軟で高機能な認証システムを備えていますが、その柔軟性ゆえに設計を誤ると破綻しやすい部分でもあります。

私自身、ユーザーと管理者の境界が曖昧な設計で大きなトラブルを経験しました。しかし、今回ご紹介したファイルを適切に切り分けて設計し直すことで、無事にアプリを再構築することができました。

この記事が、同じように認証構成見直しを検討中のエンジニアにとっての参考になれば嬉しく思います。

株式会社ONE WEDGE

【Serverlessで世の中をもっと楽しく】
ONE WEDGEはServerlessシステム開発を中核技術としてWeb系システム開発、AWS/GCPを利用した業務システム・サービス開発、PWAを用いたモバイル開発、Alexaスキル開発など、元気と技術力を武器にお客様に真摯に向き合う価値創造企業です。
https://onewedge.co.jp/

GitHubで編集を提案

Discussion