Laravelで認証を実装する方法：SanctumとPassportの使い分けと実装手順

Laravelにおける認証実装は、要件を整理してから方式を選ばないと構成が破綻しやすい。SanctumはSPAや自社クライアント向けの軽量な認証を得意とし、PassportはOAuth2準拠の本格的な認可サーバを必要とするケースに向いている。どちらを採用するかは「誰が」「どこから」「どの粒度の権限で」APIへアクセスするかで判断する。

SanctumとPassportの選択基準

Sanctumが適しているのは、同一組織が管理するSPAやモバイルアプリからAPIへアクセスするケース。Cookieベースのセッション認証や、簡易なAPIトークン発行が中心となる。
Passportが必要になるのは、第三者アプリとの連携やOAuth2の正式なフロー（認可コード、スコープ管理、クライアント管理）が求められる場合。

認証でトラブルが起きやすい発生条件

Sanctumでは、statefulドメイン設定漏れ、CSRF Cookie未取得、CORSやCookie属性の不整合が原因で401や419が発生しやすい。
Passportでは、キー未生成、クライアント未作成、OAuth2フローの誤解によってトークンが発行できないケースが多い。

SanctumによるSPA認証の基本フロー

SanctumをSPAで利用する場合、Cookieベースのセッション認証を前提とする。最初にCSRF用Cookieを取得し、その後ログイン処理を行う。

// SPA側の基本的な流れ（例：axios）
await axios.get('/sanctum/csrf-cookie', { withCredentials: true });

await axios.post('/login', {
  email: 'user@example.com',
  password: 'password'
}, { withCredentials: true });

const response = await axios.get('/api/me', { withCredentials: true });

Sanctumで401になる場合の最優先確認ポイント

SPAが動作するドメインが stateful として認識されていないと、Laravel側でステートレス扱いされ、Cookie認証が無効になる。

// config/sanctum.php
'stateful' => explode(',', env('SANCTUM_STATEFUL_DOMAINS', 'localhost,localhost:3000')),

Laravel 11以降のミドルウェア設定の注意点

Laravel 11の新しい構成では、従来の app/Http/Kernel.php ではなく bootstrap/app.php にミドルウェア定義が集約されている。SanctumのSPA認証では、フロントエンドリクエストをステートフルとして扱うミドルウェアが正しく登録されているかを確認する必要がある。

SanctumのAPIトークン認証（モバイル・バッチ向け）

Cookieを使わず、BearerトークンでAPIを叩く用途では、Personal Access Tokenを利用する。

// トークン発行例
$token = $user->createToken('mobile')->plainTextToken;

// クライアントは Authorization: Bearer {token} を付与

Passportを使ったOAuth2認証の基本構成

PassportはLaravelアプリをOAuth2認可サーバとして動作させる。導入後は、キー生成とクライアント作成が必須となる。

composer require laravel/passport
php artisan migrate
php artisan passport:install

Passportで発生しやすいエラー条件

・passport:install 未実行
・OAuth2のgrant typeの選択ミス
・クライアントID・シークレットの不一致
・Passport用テーブルのマイグレーション漏れ

これらはいずれも「OAuth2の構造を理解せずに実装を進めた場合」に起こりやすい。

SanctumとPassportを併用すべきでない理由

同一APIでSanctumとPassportを混在させると、ガード設定や認証方式が複雑化し、保守性が著しく低下する。原則としてプロジェクト単位でどちらかに統一する。

設計方針のまとめ

・同一運営のSPAやモバイルアプリ → Sanctum
・外部連携やOAuth2準拠が必須 → Passport
・認証方式は「最初に要件を固めてから」決める
・ハマりどころはドメイン設定、CSRF、ミドルウェア、OAuth2フローの理解不足

認証は後から変更すると影響範囲が大きいため、初期設計の段階で用途を明確にすることが重要になる。