「ログインの仕組み」と「権限チェック」を図でつかむ

🔐認証(Authentication)フロー

ログインフォームの送信から、Guard と User Provider による本人確認、 セッション確立、その後の auth ミドルウェアによる保護、ログアウトまでの流れです。

※ Guard が「どう識別するか」、User Provider が「どこから取り出して照合するか」を担当します。 Web画面は session ガード、APIは token ガード(Sanctumなど)が基本です。

📝登場する部品の役割

⚖️認可(Authorization): Gate と Policy

認証で「ログイン済み」と分かった後、その人がこの操作をしてよいかを判定するのが認可です。判定ルールの置き場所としてGate と Policy の2つがあります。

🧰呼び出し方の使い分け

if ($user->can('update', $post)) { /* ... */ }

@can('update', $post) <a href="...">編集</a> @endcan

$this->authorize('update', $post);

if (Gate::allows('update-post', $post)) { /* ... */ }

💡コード例で一気に見る

// AuthServiceProvider::boot()
Gate::define('admin-only', function ($user) {
    return $user->is_admin;
});

// コントローラ
if (Gate::allows('admin-only')) {
    // 管理者だけの処理
}

// Blade
@can('admin-only')
    <a href="/admin">管理画面</a>
@endcan

// php artisan make:policy PostPolicy --model=Post
class PostPolicy
{
    public function update(User $user, Post $post): bool
    {
        return $user->id === $post->user_id;
    }
}

// コントローラ: 権限なしなら 403
public function update(Post $post)
{
    $this->authorize('update', $post);
    // 自分の投稿だけ更新できる
}

🧭いつどちらを使う?(早見表)

• 🖥️画面でボタンやリンクを出し分けたい→ Blade の @can / @cannot(判定だけ・例外なし)
• 🛂コントローラで「権限がなければ弾く」ようにしたい→ $this->authorize(...)(403 を投げて処理を止める)
• 🔀処理を分岐したい(弾かず true/false で判断)→ $user->can(...) または Gate::allows(...)
• 🗂️1つのモデルに複数の操作権限がある→ Policy にまとめる(view/update/delete などを1クラスに)
• 🎫モデルに紐づかない単発の権限(例: 管理者のみ)→ Gate::define(...) でゲートを1つ定義