認証と認可を分ける
認証はログイン済みか、認可はその操作を許可するかを判断します。ログイン済みでも、他人の投稿の削除まで許可してはいけません。
未ログイン→authで確認→Policyで所有者を確認→操作実行
認証画面は公式スターターキットを利用できます。自分でパスワード保存やセッション管理を作るより、標準の仕組みと公式の更新情報を優先します。
Middlewareで入口を守る
Middlewareは、Controllerへ到達する前に共通の検査を挟む仕組みです。ログイン必須、メール認証済み、レート制限などに使います。
routes/web.phpPHP
Route::middleware(['auth', 'verified'])->group(function () {
Route::get('/dashboard', DashboardController::class)
->name('dashboard');
});Controllerで利用者を得るPHP
public function store(Request $request)
{
$request->user()->posts()->create(
$request->validate($this->rules())
);
}Policyで操作を許可する
Policyは、モデルに対する閲覧・更新・削除などの判断をまとめます。Controllerごとに条件を重複させないために役立ちます。
PolicyPHP
public function delete(User $user, Post $post): bool
{
return $user->is_admin || $user->id === $post->user_id;
}
public function destroy(Post $post)
{
$this->authorize('delete', $post);
$post->delete();
return to_route('posts.index');
}IDを隠すだけでは不十分 連番IDをUUIDへ変えても権限確認の代わりにはなりません。URLから他人のデータを推測できないことと、操作を許可することは別の対策です。
JSONレスポンスを設計する
APIでは、返す項目とステータスコードを決めます。モデルをそのまま返さず、API Resourceで公開する形を明示します。
ResourceCOMMAND / PHP
php artisan make:resource PostResource
public function toArray(Request $request): array
{
return [
'id' => $this->id,
'title' => $this->title,
'author' => $this->user->name,
];
}返却PHP
return PostResource::collection(
Post::with('user')->latest()->paginate()
);Sanctumを使う場面
自分のSPAやモバイルアプリからLaravel APIを呼ぶ場合、SanctumでSPA認証やAPIトークンを扱えます。用途に応じてstatefulなCookie認証とトークン認証を選びます。
認証必須のAPIPHP
Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
return $request->user();
});トークンはログへ出したり、URLへ含めたりしません。権限、失効、HTTPS、CORS、レート制限も含めて設計し、認証の仕組みを理解せずに公開APIを作らないようにします。
練習問題
ログイン利用者が自分のプロフィールをJSONで取得できるGET /api/meを作り、未認証なら401になるテストを書いてください。
確認ポイント
auth:sanctumをルートへ付ける- 公開するプロフィール項目をResourceで限定する
- パスワードやトークンをJSONへ含めない
- 認証済みと未認証の両方をテストする