Laravelの主な認証方法

  • 投稿日
  • 更新日
  • 著者 IF233
  • カテゴリー Laravel

Laravelの主な認証方法たち

① Laravel Breeze

  • 🐣 シンプルな認証スターターキット。
  • Blade or Inertia（Vue/React）対応。
  • ログイン、登録、パスワードリセットなど、基本機能がすぐ使える。
  • 学習目的・小〜中規模アプリにぴったり！

② Laravel Jetstream

  • Breezeの進化系。
  • Inertia（Vue）か Livewire が前提。
  • チーム管理、2要素認証、セッション管理など高機能。
  • 大規模 or ユーザー管理が複雑なアプリ向け。
  • UIの自由度はちょっと低め。

③ Laravel Fortify

  • Jetstreamの「バックエンドだけ版」。
  • 自分でフロントを作りたい人向け。
  • APIベースで、SPAやモバイルアプリと相性よし。
  • 独自UIを作るけど認証ロジックは任せたい派向け。

④ Laravel Sanctum

  • API認証用のトークンベース認証（SPAやモバイル向け）。
  • セッションクッキーを使ったSPA向け認証 or APIトークン認証どちらも可。
  • トークン制御が柔軟で、SPA開発によく使われる。

⑤ Laravel Passport

  • OAuth2対応のがっつりAPI認証。
  • 外部サービスへの提供とか、本格的なAPI認証に。
  • 重たい & 学習コスト高め、なので今はSanctumのほうが人気。

⑥ Laravel UI

Laravel 6,7のころからある

Laravel8からはLaravel/uiは非推奨になってますが、jQueryベースでtailwindやvueやLivewireを使用しないで済むという点から使用しているエンジニアもおられます

保守では最新でない場合もあるので、対応しないといけない場合もある

シナリオよく使われる認証方式
通常のWebアプリ（Blade）Breeze 👍
SPA（Vue/React）Breeze + Sanctum or Fortify + Sanctum
チーム・2FAなど高度な機能Jetstream
API単体・OAuth対応が必要Passport

Sanctumでシンプルな認証

トークンベースの認証により、ステートレスなAPI通信が可能

一般的な例

フロントエンドVue、LaravelをAPIとして使用している場合のケース

実行時に自動で personal_access_tokens テーブルが作成

mysql> desc personal_access_tokens;
+----------------+---------------------+------+-----+---------+----------------+
| Field          | Type                | Null | Key | Default | Extra          |
+----------------+---------------------+------+-----+---------+----------------+
| id             | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| tokenable_type | varchar(255)        | NO   | MUL | NULL    |                |
| tokenable_id   | bigint(20) unsigned | NO   |     | NULL    |                |
| name           | text                | NO   |     | NULL    |                |
| token          | varchar(64)         | NO   | UNI | NULL    |                |
| abilities      | text                | YES  |     | NULL    |                |
| last_used_at   | timestamp           | YES  |     | NULL    |                |
| expires_at     | timestamp           | YES  | MUL | NULL    |                |
| created_at     | timestamp           | YES  |     | NULL    |                |
| updated_at     | timestamp           | YES  |     | NULL    |                |
+----------------+---------------------+------+-----+---------+----------------+
10 rows in set (0.10 sec)
GitHub – idw-coder/laravel-rds
Contribute to idw-coder/laravel-rds development by creating an account on GitHub.
github.com

そもそもLaravelの「Route設定の書き方」を確認です。ミドルウェアをグループで複数のルートに適用する記述もするので、そのあたりを理解する必要があります。

Route:: でルート設定を記述しますが、:: は PHP の静的メソッド/プロパティにアクセスする演算子です。フレームワークに組み込まれた便利な機能を利用しているだけなので、これ以上の深い理解は不要かと思います。

シンプルな例
/logout という URL に POST リクエストがあったら AuthController の logout メソッドが呼ばれます。

Route::post('/logout', [AuthController::class, 'logout']);

AuthController::class について補足ですが::class はクラスの完全な取得→実際は”App\Http\Controllers\Api\AuthController”

次はミドルウェアを使用したRoute設定について説明します

Route::middleware('auth:sanctum')->group(function () {
    Route::get('/profile', [UserController::class, 'show']);
});

middleware('auth:sanctum') とは？

「Sanctum 認証を通過したリクエストのみ処理する」という設定

Sanctum 認証を通過について具体的なプロセスは

  • Authorization: Bearer {token} ヘッダーをチェック
  • トークンが有効 → ルート処理へ Route::get(‘/profile’, [UserController::class, ‘show’]);
  • トークンが無効 → 401 Unauthorized を返す

トークンチェックの具体的プロセス

  1. ヘッダーからトークンを取得
    Authorization: Bearer の後ろの文字列を抽出
  2. トークンを分割
    3|abc... を | で分割 → ID と平文トークンに
  3. DB で検索
    personal_access_tokens テーブルから該当レコードを取得
  4. 結果
    • 全てクリア → 認証成功、ルート処理へ
    • いずれか失敗 → 401 エラー