認証 (Authentication)

• Introduction
  • スターターキット
  • データベースに関する考慮事項
  • 生態系の概要
• 認証クイックスタート
  • スターターキットをインストールする
  • 認証されたユーザーの取得
  • ルートを守る
  • ログインスロットル
• ユーザーを手動で認証する
  • ユーザーを記憶する
  • その他の認証方法
• HTTP基本認証
  • ステートレスHTTP基本認証
• ログアウトする
  • 他のデバイスのセッションを無効にする
• パスワードの確認
  • Configuration
  • Routing
  • ルートを守る
• カスタムガードの追加
  • 閉鎖リクエストガード
• カスタム ユーザー プロバイダの追加
  • ユーザープロバイダ契約
  • 認証可能な契約
• パスワードの自動再ハッシュ
• ソーシャル認証
• Events

導入 (Introduction)

多くの Web アプリケーションは、ユーザーがアプリケーションで認証して「ログイン」する方法を提供します。この機能を Web アプリケーションに実装することは、複雑で潜在的に危険な作業となる可能性があります。このため、Laravel は、認証を迅速、安全、簡単に実装するために必要なツールを提供するよう努めています。

Laravel の認証機能の中核は、「ガード」と「プロバイダ」で構成されています。ガードは、各リクエストに対してユーザーが認証される方法を定義します。たとえば、Laravel には、セッションストレージと Cookie を使用して状態を維持する session ガードが付属しています。

プロバイダは、永続ストレージからユーザーを取得する方法を定義します。 Laravel には、Eloquent とデータベース クエリビルダを使用したユーザーの取得のサポートが付属しています。ただし、アプリケーションの必要に応じて追加のプロバイダを自由に定義できます。

アプリケーションの認証構成ファイルは、config/auth.php にあります。このファイルには、Laravel の認証サービスの動作を調整するための、十分に文書化されたオプションがいくつか含まれています。

ガードとプロバイダを「ロール」と「権限」と混同しないでください。権限によるユーザーアクションの承認の詳細については、authorization ドキュメントを参照してください。

スターターキット

すぐに始めたいですか?新しい Laravel アプリケーションに Laravelアプリケーションスターターキット をインストールします。データベースを移行した後、ブラウザーで /register またはアプリケーションに割り当てられているその他の URL に移動します。スターター キットは、認証システム全体の足場を整えます。

最終的な Laravel アプリケーションでスターター キットを使用しないことを選択した場合でも、スターターキット のインストールは、Laravel のすべての認証機能を実際の Laravel プロジェクトに実装する方法を学ぶ素晴らしい機会になります。 Laravel スターター キットには認証コントローラ、ルート、ビューが含まれているため、これらのファイル内のコードを調べて、Laravel の認証機能がどのように実装されるかを学ぶことができます。

データベースに関する考慮事項

デフォルトでは、Laravel には app/Models ディレクトリに App\Models\User Eloquent モデル が含まれています。このモデルは、デフォルトの Eloquent 認証ドライバとともに使用できます。

アプリケーションが Eloquent を使用していない場合は、Laravel クエリビルダを使用する database 認証プロバイダを使用できます。アプリケーションが MongoDB を使用している場合は、MongoDB の公式 Laravelユーザー認証ドキュメント を確認してください。

App\Models\User モデルのデータベース スキーマを構築するときは、パスワード列の長さが少なくとも 60 文字であることを確認してください。もちろん、新しい Laravel アプリケーションに含まれる users テーブルの移行では、この長さを超える列がすでに作成されています。

また、users (または同等の) テーブルに、NULL 許容の 100 文字の文字列 remember_token 列が含まれていることを確認する必要があります。この列は、アプリケーションにログインするときに「記憶する」オプションを選択したユーザーのトークンを保存するために使用されます。繰り返しますが、新しい Laravel アプリケーションに含まれるデフォルトの users テーブル移行には、この列がすでに含まれています。

生態系の概要

Laravel は認証に関連するパッケージをいくつか提供しています。続行する前に、Laravel の一般的な認証エコシステムを確認し、各パッケージの意図された目的について説明します。

まず、認証がどのように機能するかを考えてみましょう。 Web ブラウザを使用する場合、ユーザーはログイン フォームを介してユーザー名とパスワードを入力します。これらの資格情報が正しい場合、アプリケーションは認証されたユーザーに関する情報をユーザーの session に保存します。ブラウザに発行される Cookie にはセッション ID が含まれているため、アプリケーションへの後続のリクエストでユーザーを正しいセッションに関連付けることができます。セッション Cookie を受信すると、アプリケーションはセッション ID に基づいてセッション データを取得し、認証情報がセッションに保存されていることに注意して、ユーザーを「認証済み」と見なします。

リモート サービスが API にアクセスするために認証が必要な場合、Web ブラウザがないため、通常は認証に Cookie は使用されません。代わりに、リモート サービスはリクエストごとに API トークンを API に送信します。アプリケーションは、受信したトークンを有効な API トークンのテーブルと照合して検証し、その API トークンに関連付けられたユーザーによって実行されたリクエストを「認証」します。

Laravelの組み込みブラウザ認証サービス

Laravel には、組み込みの認証サービスとセッション サービスが含まれており、通常は Auth および Session ファサードを介してアクセスされます。これらの機能は、Web ブラウザから開始されたリクエストに対して Cookie ベースの認証を提供します。これらは、ユーザーの資格情報を確認し、ユーザーを認証できるメソッドを提供します。さらに、これらのサービスは、ユーザーのセッションに適切な認証データを自動的に保存し、ユーザーのセッション Cookie を発行します。これらのサービスの使用方法については、このドキュメントに記載されています。

アプリケーション スターター キット

このドキュメントで説明したように、これらの認証サービスと手動で対話して、アプリケーション独自の認証層を構築できます。ただし、より迅速に開始できるように、認証レイヤー全体の堅牢で最新の足場を提供する 無料のスターターキット をリリースしました。

LaravelのAPI認証サービス

Laravel は、API トークンの管理と API トークンを使用して行われたリクエストの認証を支援する 2 つのオプション パッケージ (Passport と Sanctum) を提供します。これらのライブラリとLaravelの組み込みCookieベースの認証ライブラリは相互に排他的ではないことに注意してください。これらのライブラリは主に API トークン認証に焦点を当てており、組み込みの認証サービスは Cookie ベースのブラウザ認証に焦点を当てています。多くのアプリケーションは、Laravel の組み込み Cookie ベースの認証サービスと、Laravel の API 認証パッケージの 1 つの両方を使用します。

Passport

Passport は OAuth2 認証プロバイダであり、さまざまなタイプのトークンを発行できるさまざまな OAuth2 「許可タイプ」を提供します。一般に、これは API 認証用の堅牢かつ複雑なパッケージです。ただし、ほとんどのアプリケーションは OAuth2 仕様によって提供される複雑な機能を必要としないため、ユーザーと開発者の両方にとって混乱を招く可能性があります。さらに、開発者はこれまで、Passport などの OAuth2 認証プロバイダを使用して SPA アプリケーションやモバイル アプリケーションを認証する方法について混乱してきました。

Sanctum

OAuth2 の複雑さと開発者の混乱に応えて、私たちは Web ブラウザーからのファーストパーティ Web リクエストとトークン経由の API リクエストの両方を処理できる、よりシンプルで合理化された認証パッケージの構築に着手しました。この目標は、Laravel Sanctum のリリースによって実現されました。これは、API に加えてファーストパーティの Web UI を提供するアプリケーション、またはバックエンドの Laravel アプリケーションとは別に存在するシングルページ アプリケーション (SPA) によって動作するアプリケーション、またはモバイル クライアントを提供するアプリケーションにとって、優先および推奨される認証パッケージと見なされるべきです。

Laravel Sanctum は、アプリケーションの認証プロセス全体を管理できるハイブリッド Web/API 認証パッケージです。これが可能なのは、Sanctum ベースのアプリケーションがリクエストを受信すると、Sanctum が最初にリクエストに認証されたセッションを参照するセッション Cookie が含まれているかどうかを判断するためです。 Sanctum は、前に説明した Laravel の組み込み認証サービスを呼び出すことでこれを実現します。リクエストがセッション Cookie によって認証されていない場合、Sanctum は API トークンのリクエストを検査します。 API トークンが存在する場合、Sanctum はそのトークンを使用してリクエストを認証します。このプロセスの詳細については、Sanctum の 「仕組み」 ドキュメントを参照してください。

まとめとスタックの選択

要約すると、アプリケーションがブラウザを使用してアクセスされ、モノリシックな Laravel アプリケーションを構築している場合、アプリケーションは Laravel の組み込み認証サービスを使用します。

次に、アプリケーションがサードパーティによって使用される API を提供する場合は、アプリケーションに API トークン認証を提供するために Passport または Sanctum のいずれかを選択します。一般に、Sanctum は、「スコープ」または「能力」のサポートを含め、API 認証、SPA 認証、およびモバイル認証のシンプルで完全なソリューションであるため、可能な限り推奨されます。

Laravel バックエンドを利用するシングルページ アプリケーション (SPA) を構築している場合は、Laravel Sanctum を使用する必要があります。 Sanctum を使用する場合は、独自のバックエンド認証ルートを手動で実装する を実行するか、登録、パスワードリセット、電子メール検証などの機能のルートとコントローラを提供するヘッドレス認証バックエンド サービスとして Laravel の強化 を利用する必要があります。

アプリケーションが OAuth2 仕様で提供されるすべての機能を絶対に必要とする場合は、Passportを選択できます。

また、すぐに始めたい場合は、Laravel の組み込み認証サービスの優先認証スタックを既に使用している新しい Laravel アプリケーションを簡単に開始する方法として、当社のアプリケーションスターターキット をお勧めします。

認証クイックスタート (Authentication Quickstart)

ドキュメントのこの部分では、Laravelアプリケーションスターターキット を介したユーザーの認証について説明します。これには、すぐに開始できるようにする UI スキャフォールディングが含まれています。 Laravel の認証システムと直接統合したい場合は、ユーザーを手動で認証する のドキュメントを確認してください。

スターターキットをインストールする

まず、Laravelアプリケーションスターターキットをインストールする を実行する必要があります。私たちのスターター キットは、新しい Laravel アプリケーションに認証を組み込むための美しくデザインされた出発点を提供します。

認証されたユーザーの取得

スターター キットからアプリケーションを作成し、ユーザーがアプリケーションに登録して認証できるようにした後、多くの場合、現在認証されているユーザーと対話する必要があります。受信リクエストの処理中に、Auth ファサードの user メソッドを介して認証されたユーザーにアクセスできます。

use Illuminate\Support\Facades\Auth;

// Retrieve the currently authenticated user...
$user = Auth::user();

// Retrieve the currently authenticated user's ID...
$id = Auth::id();

あるいは、ユーザーが認証されると、Illuminate\Http\Request インスタンス経由で認証されたユーザーにアクセスできます。タイプヒント付きクラスはコントローラのメソッドに自動的に挿入されることに注意してください。 Illuminate\Http\Request オブジェクトをタイプヒントすることにより、リクエストの user メソッドを介して、アプリケーション内の任意のコントローラ メソッドから認証されたユーザーに簡単にアクセスできるようになります。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class FlightController extends Controller
{
    /**
     * Update the flight information for an existing flight.
     */
    public function update(Request $request): RedirectResponse
    {
        $user = $request->user();

        // ...

        return redirect('/flights');
    }
}

現在のユーザーが認証されているかどうかを確認する

受信 HTTP リクエストを行っているユーザーが認証されているかどうかを確認するには、Auth ファサードで check メソッドを使用できます。ユーザーが認証されている場合、このメソッドは true を返します。

use Illuminate\Support\Facades\Auth;

if (Auth::check()) {
    // The user is logged in...
}

check メソッドを使用してユーザーが認証されているかどうかを判断することは可能ですが、通常は、ユーザーに特定のルート/コントローラへのアクセスを許可する前に、ミドルウェアを使用してユーザーが認証されていることを確認します。これについて詳しくは、ルートを保護する のドキュメントを参照してください。

ルートを守る

ルートミドルウェア を使用すると、認証されたユーザーに特定のルートへのアクセスのみを許可できます。 Laravel には、auth ミドルウェアが同梱されています。これは、Illuminate\Auth\Middleware\Authenticate クラスの ミドルウェアのエイリアス です。このミドルウェアはすでに Laravel によって内部的にエイリアス化されているため、必要なのはミドルウェアをルート定義にアタッチすることだけです。

Route::get('/flights', function () {
    // Only authenticated users may access this route...
})->middleware('auth');

認証されていないユーザーのリダイレクト

auth ミドルウェアは、認証されていないユーザーを検出すると、ユーザーを login 名前付きルート にリダイレクトします。アプリケーションの bootstrap/app.php ファイル内で redirectGuestsTo メソッドを使用して、この動作を変更できます。

use Illuminate\Http\Request;

->withMiddleware(function (Middleware $middleware): void {
    $middleware->redirectGuestsTo('/login');

    // Using a closure...
    $middleware->redirectGuestsTo(fn (Request $request) => route('login'));
})

認証されたユーザーのリダイレクト

guest ミドルウェアは、認証されたユーザーを検出すると、ユーザーを dashboard または home という名前のルートにリダイレクトします。アプリケーションの bootstrap/app.php ファイル内で redirectUsersTo メソッドを使用して、この動作を変更できます。

use Illuminate\Http\Request;

->withMiddleware(function (Middleware $middleware): void {
    $middleware->redirectUsersTo('/panel');

    // Using a closure...
    $middleware->redirectUsersTo(fn (Request $request) => route('panel'));
})

ガードの指定

auth ミドルウェアをルートにアタッチする場合、ユーザーの認証にどの「ガード」を使用するかを指定することもできます。指定したガードは、auth.php 構成ファイルの guards 配列内のキーの 1 つに対応する必要があります。

Route::get('/flights', function () {
    // Only authenticated users may access this route...
})->middleware('auth:admin');

ログインスロットル

アプリケーションスターターキット のいずれかを使用している場合、ログイン試行にレート制限が自動的に適用されます。デフォルトでは、ユーザーは数回試行しても正しい認証情報を入力できなかった場合、1 分間ログインできなくなります。スロットリングは、ユーザーのユーザー名/電子メール アドレスおよび IP アドレスに固有です。

アプリケーション内の他のルートをレート制限したい場合は、レート制限に関するドキュメント を確認してください。

ユーザーを手動で認証する (Manually Authenticating Users)

Laravel の アプリケーションスターターキット に含まれる認証スキャフォールディングを使用する必要はありません。このスキャフォールディングを使用しないことを選択した場合は、Laravel 認証クラスを直接使用してユーザー認証を管理する必要があります。心配しないでください、それは簡単です!

Auth facade 経由で Laravel の認証サービスにアクセスするため、クラスの先頭に Auth ファサードをインポートする必要があります。次に、attempt メソッドを確認してみましょう。 attempt メソッドは通常、アプリケーションの「ログイン」フォームからの認証試行を処理するために使用されます。認証が成功した場合は、セッション固定 を防ぐためにユーザーの session を再生成する必要があります。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Http\RedirectResponse;
use Illuminate\Support\Facades\Auth;

class LoginController extends Controller
{
    /**
     * Handle an authentication attempt.
     */
    public function authenticate(Request $request): RedirectResponse
    {
        $credentials = $request->validate([
            'email' => ['required', 'email'],
            'password' => ['required'],
        ]);

        if (Auth::attempt($credentials)) {
            $request->session()->regenerate();

            return redirect()->intended('dashboard');
        }

        return back()->withErrors([
            'email' => 'The provided credentials do not match our records.',
        ])->onlyInput('email');
    }
}

attempt メソッドは、キーと値のペアの配列を最初の引数として受け入れます。配列内の値は、データベース テーブル内でユーザーを検索するために使用されます。したがって、上記の例では、ユーザーは email 列の値によって取得されます。ユーザーが見つかった場合、データベースに保存されているハッシュ化されたパスワードが、配列を介してメソッドに渡された password 値と比較されます。受信リクエストの password 値をハッシュしないでください。フレームワークは、値をデータベース内のハッシュされたパスワードと比較する前に自動的にハッシュするからです。 2 つのハッシュ化されたパスワードが一致する場合、ユーザーの認証されたセッションが開始されます。

Laravel の認証サービスは、認証ガードの「プロバイダ」設定に基づいてデータベースからユーザーを取得することに注意してください。デフォルトの config/auth.php 構成ファイルでは、Eloquent ユーザー プロバイダが指定されており、ユーザーを取得するときに App\Models\User モデルを使用するように指示されます。アプリケーションのニーズに基づいて、構成ファイル内でこれらの値を変更できます。

認証が成功した場合、attempt メソッドは true を返します。それ以外の場合は、false が返されます。

Laravel のリダイレクターによって提供される intended メソッドは、認証ミドルウェアによって傍受される前に、ユーザーがアクセスしようとしていた URL にユーザーをリダイレクトします。意図した宛先が利用できない場合に備えて、このメソッドにフォールバック URI を指定できます。

追加条件の指定

必要に応じて、ユーザーの電子メールとパスワードに加えて、追加のクエリ条件を認証クエリに追加することもできます。これを実現するには、attempt メソッドに渡される配列にクエリ条件を追加するだけです。たとえば、ユーザーが「アクティブ」としてマークされていることを確認できます。

if (Auth::attempt(['email' => $email, 'password' => $password, 'active' => 1])) {
    // Authentication was successful...
}

複雑なクエリ条件の場合は、資格情報の配列にクロージャを指定できます。このクロージャはクエリ インスタンスで呼び出され、アプリケーションのニーズに基づいてクエリをカスタマイズできます。

use Illuminate\Database\Eloquent\Builder;

if (Auth::attempt([
    'email' => $email,
    'password' => $password,
    fn (Builder $query) => $query->has('activeSubscription'),
])) {
    // Authentication was successful...
}

これらの例では、email は必須のオプションではなく、単に例として使用されています。データベーステーブルの「ユーザー名」に対応する列名を使用する必要があります。

2 番目の引数としてクロージャを受け取る attemptWhen メソッドは、実際にユーザーを認証する前に、潜在的なユーザーのより広範な検査を実行するために使用できます。クロージャーは潜在的なユーザーを受け取り、ユーザーが認証されているかどうかを示す true または false を返す必要があります。

if (Auth::attemptWhen([
    'email' => $email,
    'password' => $password,
], function (User $user) {
    return $user->isNotBanned();
})) {
    // Authentication was successful...
}

特定の Guard インスタンスへのアクセス

Auth ファサードの guard メソッドを使用して、ユーザーの認証時にどのガード インスタンスを使用するかを指定できます。これにより、完全に別個の認証可能なモデルまたはユーザー テーブルを使用して、アプリケーションの別個の部分の認証を管理できます。

guard メソッドに渡されるガード名は、auth.php 構成ファイルで構成されたガードの 1 つに対応する必要があります。

if (Auth::guard('admin')->attempt($credentials)) {
    // ...
}

ユーザーを記憶する

多くの Web アプリケーションには、ログイン フォームに「記憶する」チェックボックスが用意されています。アプリケーションに「記憶する」機能を提供したい場合は、attempt メソッドの 2 番目の引数としてブール値を渡すことができます。

この値が true の場合、Laravel はユーザーを無期限に、または手動でログアウトするまで認証し続けます。 users テーブルには、「remember me」トークンを保存するために使用される文字列 remember_token 列が含まれている必要があります。新しい Laravel アプリケーションに含まれる users テーブルの移行には、すでに次の列が含まれています。

use Illuminate\Support\Facades\Auth;

if (Auth::attempt(['email' => $email, 'password' => $password], $remember)) {
    // The user is being remembered...
}

アプリケーションが「remember me」機能を提供する場合、viaRemember メソッドを使用して、現在認証されているユーザーが「remember me」Cookie を使用して認証されたかどうかを判断できます。

use Illuminate\Support\Facades\Auth;

if (Auth::viaRemember()) {
    // ...
}

その他の認証方法

ユーザーインスタンスの認証

既存のユーザー インスタンスを現在認証されているユーザーとして設定する必要がある場合は、そのユーザー インスタンスを Auth ファサードの login メソッドに渡すことができます。指定されたユーザー インスタンスは、Illuminate\Contracts\Auth\Authenticatable contract の実装である必要があります。 Laravel に含まれる App\Models\User モデルはすでにこのインターフェイスを実装しています。この認証方法は、ユーザーがアプリケーションに登録した直後など、有効なユーザー インスタンスがすでにある場合に役立ちます。

use Illuminate\Support\Facades\Auth;

Auth::login($user);

login メソッドの 2 番目の引数としてブール値を渡すことができます。この値は、認証されたセッションに「記憶する」機能が必要かどうかを示します。これは、セッションが無期限に、またはユーザーがアプリケーションから手動でログアウトするまで認証されることを意味することに注意してください。

Auth::login($user, $remember = true);

必要に応じて、login メソッドを呼び出す前に認証ガードを指定できます。

Auth::guard('admin')->login($user);

IDによるユーザー認証

データベース レコードの主キーを使用してユーザーを認証するには、loginUsingId メソッドを使用できます。このメソッドは、認証するユーザーの主キーを受け入れます。

Auth::loginUsingId(1);

loginUsingId メソッドの remember 引数にブール値を渡すことができます。この値は、認証されたセッションに「記憶する」機能が必要かどうかを示します。これは、セッションが無期限に、またはユーザーがアプリケーションから手動でログアウトするまで認証されることを意味することに注意してください。

Auth::loginUsingId(1, remember: true);

ユーザーを一度認証する

once メソッドを使用して、単一のリクエストに対してアプリケーションでユーザーを認証できます。このメソッドを呼び出すときにセッションや Cookie は使用されず、Login イベントは送出されません。

if (Auth::once($credentials)) {
    // ...
}

HTTP基本認証 (HTTP Basic Authentication)

HTTP基本認証 は、専用の「ログイン」ページを設定せずに、アプリケーションのユーザーを認証する迅速な方法を提供します。まず、auth.basic middleware をルートにアタッチします。 auth.basic ミドルウェアは Laravel フレームワークに含まれているため、定義する必要はありません。

Route::get('/profile', function () {
    // Only authenticated users may access this route...
})->middleware('auth.basic');

ミドルウェアがルートにアタッチされると、ブラウザでルートにアクセスするときに自動的に資格情報の入力を求められます。デフォルトでは、auth.basic ミドルウェアは、users データベース テーブルの email 列がユーザーの「ユーザー名」であると想定します。

FastCGI に関する注意事項

PHP FastCGI と Apache を使用して Laravel アプリケーションを提供している場合、HTTP 基本認証が正しく機能しない可能性があります。これらの問題を修正するには、アプリケーションの .htaccess ファイルに次の行を追加します。

RewriteCond %{HTTP:Authorization} ^(.+)$
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

ステートレスHTTP基本認証

セッションにユーザー識別子 Cookie を設定せずに、HTTP 基本認証を使用することもできます。これは主に、アプリケーションの API へのリクエストを認証するために HTTP 認証を使用することを選択した場合に役立ちます。これを実現するには、onceBasic メソッドを呼び出す ミドルウェアを定義する 。 onceBasic メソッドから応答が返されない場合、リクエストはさらにアプリケーションに渡される可能性があります。

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Symfony\Component\HttpFoundation\Response;

class AuthenticateOnceWithBasicAuth
{
    /**
     * Handle an incoming request.
     *
     * @param  \Closure(\Illuminate\Http\Request): (\Symfony\Component\HttpFoundation\Response)  $next
     */
    public function handle(Request $request, Closure $next): Response
    {
        return Auth::onceBasic() ?: $next($request);
    }

}

次に、ミドルウェアをルートにアタッチします。

Route::get('/api/user', function () {
    // Only authenticated users may access this route...
})->middleware(AuthenticateOnceWithBasicAuth::class);

ログアウトする (Logging Out)

ユーザーをアプリケーションから手動でログアウトするには、Auth ファサードによって提供される logout メソッドを使用できます。これにより、ユーザーのセッションから認証情報が削除され、後続のリクエストは認証されなくなります。

logout メソッドの呼び出しに加えて、ユーザーのセッションを無効にして CSRFトークン を再生成することをお勧めします。ユーザーをログアウトした後、通常はユーザーをアプリケーションのルートにリダイレクトします。

use Illuminate\Http\Request;
use Illuminate\Http\RedirectResponse;
use Illuminate\Support\Facades\Auth;

/**
 * Log the user out of the application.
 */
public function logout(Request $request): RedirectResponse
{
    Auth::logout();

    $request->session()->invalidate();

    $request->session()->regenerateToken();

    return redirect('/');
}

他のデバイスのセッションを無効にする

Laravel は、現在のデバイスのセッションを無効にすることなく、他のデバイスでアクティブなユーザーのセッションを無効にして「ログアウト」するメカニズムも提供します。この機能は通常、ユーザーがパスワードを変更または更新するときに、現在のデバイスの認証を維持しながら他のデバイスのセッションを無効にする場合に使用されます。

開始する前に、セッション認証を受け取る必要があるルートに Illuminate\Session\Middleware\AuthenticateSession ミドルウェアが含まれていることを確認する必要があります。通常、このミドルウェアをルート グループ定義に配置して、アプリケーションのルートの大部分に適用できるようにする必要があります。デフォルトでは、AuthenticateSession ミドルウェアは、auth.session ミドルウェアのエイリアス を使用してルートに接続できます。

Route::middleware(['auth', 'auth.session'])->group(function () {
    Route::get('/', function () {
        // ...
    });
});

その後、Auth ファサードによって提供される logoutOtherDevices メソッドを使用できます。この方法では、ユーザーは現在のパスワードを確認する必要があり、アプリケーションは入力フォームを通じてこのパスワードを受け入れる必要があります。

use Illuminate\Support\Facades\Auth;

Auth::logoutOtherDevices($currentPassword);

logoutOtherDevices メソッドが呼び出されると、ユーザーの他のセッションは完全に無効になります。つまり、以前に認証されたすべてのガードから「ログアウト」されます。

パスワードの確認 (Password Confirmation)

アプリケーションの構築中に、アクションを実行する前、またはユーザーがアプリケーションの機密領域にリダイレクトされる前に、ユーザーにパスワードの確認を要求するアクションが発生する場合があります。 Laravel には、このプロセスを簡単にする組み込みのミドルウェアが含まれています。この機能を実装するには、2 つのルートを定義する必要があります。1 つはユーザーにパスワードの確認を求めるビューを表示するルート、もう 1 つはパスワードが有効であることを確認し、ユーザーを目的の宛先にリダイレクトするルートです。

次のドキュメントでは、Laravel のパスワード確認機能と直接統合する方法について説明します。ただし、より迅速に開始したい場合は、Laravelアプリケーションスターターキット にこの機能のサポートが含まれています。

構成

パスワードを確認した後、ユーザーは 3 時間はパスワードの再確認を求められません。ただし、アプリケーションの config/auth.php 構成ファイル内の password_timeout 構成値の値を変更することで、ユーザーにパスワードの再入力を求めるまでの時間を構成できます。

ルーティング

パスワード確認フォーム

まず、ユーザーにパスワードの確認を要求するビューを表示するルートを定義します。

Route::get('/confirm-password', function () {
    return view('auth.confirm-password');
})->middleware('auth')->name('password.confirm');

ご想像のとおり、このルートによって返されるビューには、password フィールドを含むフォームが含まれている必要があります。さらに、ユーザーがアプリケーションの保護された領域に入ろうとしているため、パスワードを確認する必要があることを説明するテキストをビュー内に自由に含めることができます。

パスワードを確認する

次に、「パスワードの確認」ビューからのフォームリクエストを処理するルートを定義します。このルートは、パスワードを検証し、ユーザーを目的の宛先にリダイレクトする役割を果たします。

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;

Route::post('/confirm-password', function (Request $request) {
    if (! Hash::check($request->password, $request->user()->password)) {
        return back()->withErrors([
            'password' => ['The provided password does not match our records.']
        ]);
    }

    $request->session()->passwordConfirmed();

    return redirect()->intended();
})->middleware(['auth', 'throttle:6,1']);

次に進む前に、このルートを詳しく調べてみましょう。まず、リクエストの password フィールドが、認証されたユーザーのパスワードと実際に一致するかどうかが判断されます。パスワードが有効な場合は、ユーザーがパスワードを確認したことをLaravelのセッションに通知する必要があります。 passwordConfirmed メソッドは、Laravel がユーザーが最後にパスワードを確認した日時を判断するために使用できるタイムスタンプをユーザーのセッションに設定します。最後に、ユーザーを目的の宛先にリダイレクトできます。

ルートを守る

最近のパスワードの確認を必要とするアクションを実行するルートには、password.confirm ミドルウェアが割り当てられていることを確認する必要があります。このミドルウェアは Laravel のデフォルトのインストールに含まれており、ユーザーがパスワードを確認した後にその場所にリダイレクトされるように、ユーザーの意図した宛先をセッションに自動的に保存します。ユーザーの意図した宛先をセッションに保存した後、ミドルウェアはユーザーを password.confirm 名前付きルート にリダイレクトします。

Route::get('/settings', function () {
    // ...
})->middleware(['password.confirm']);

Route::post('/settings', function () {
    // ...
})->middleware(['password.confirm']);

カスタムガードの追加 (Adding Custom Guards)

Auth ファサードで extend メソッドを使用して、独自の認証ガードを定義できます。 extend メソッドの呼び出しは サービスプロバイダ 内で行う必要があります。 Laravel にはすでに AppServiceProvider が同梱されているため、コードをそのプロバイダに配置できます。

<?php

namespace App\Providers;

use App\Services\Auth\JwtGuard;
use Illuminate\Contracts\Foundation\Application;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    // ...

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Auth::extend('jwt', function (Application $app, string $name, array $config) {
            // Return an instance of Illuminate\Contracts\Auth\Guard...

            return new JwtGuard(Auth::createUserProvider($config['provider']));
        });
    }
}

上の例でわかるように、extend メソッドに渡されるコールバックは、Illuminate\Contracts\Auth\Guard の実装を返す必要があります。このインターフェイスには、カスタム ガードを定義するために実装する必要があるメソッドがいくつか含まれています。カスタム ガードが定義されたら、auth.php 構成ファイルの guards 構成でガードを参照できます。

'guards' => [
    'api' => [
        'driver' => 'jwt',
        'provider' => 'users',
    ],
],

閉鎖リクエストガード

カスタムの HTTP リクエスト ベースの認証システムを実装する最も簡単な方法は、Auth::viaRequest メソッドを使用することです。このメソッドを使用すると、単一のクロージャを使用して認証プロセスを迅速に定義できます。

まず、アプリケーションの AppServiceProvider の boot メソッド内で Auth::viaRequest メソッドを呼び出します。 viaRequest メソッドは、最初の引数として認証ドライバ名を受け入れます。この名前には、カスタム ガードを説明する任意の文字列を指定できます。メソッドに渡される 2 番目の引数は、受信 HTTP リクエストを受け取り、ユーザー インスタンスを返すか、認証が失敗した場合は null を返すクロージャである必要があります。

use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;

/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Auth::viaRequest('custom-token', function (Request $request) {
        return User::where('token', (string) $request->token)->first();
    });
}

カスタム認証ドライバを定義したら、それを auth.php 構成ファイルの guards 構成内のドライバとして構成できます。

'guards' => [
    'api' => [
        'driver' => 'custom-token',
    ],
],

最後に、認証ミドルウェアをルートに割り当てるときにガードを参照できます。

Route::middleware('auth:api')->group(function () {
    // ...
});

カスタム ユーザー プロバイダの追加 (Adding Custom User Providers)

ユーザーの保存に従来のリレーショナル データベースを使用していない場合は、独自の認証ユーザー プロバイダを使用して Laravel を拡張する必要があります。 Auth ファサードで provider メソッドを使用して、カスタム ユーザー プロバイダを定義します。ユーザー プロバイダ リゾルバーは、Illuminate\Contracts\Auth\UserProvider の実装を返す必要があります。

<?php

namespace App\Providers;

use App\Extensions\MongoUserProvider;
use Illuminate\Contracts\Foundation\Application;
use Illuminate\Support\Facades\Auth;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    // ...

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        Auth::provider('mongo', function (Application $app, array $config) {
            // Return an instance of Illuminate\Contracts\Auth\UserProvider...

            return new MongoUserProvider($app->make('mongo.connection'));
        });
    }
}

provider メソッドを使用してプロバイダを登録した後、auth.php 構成ファイルで新しいユーザー プロバイダに切り替えることができます。まず、新しいドライバを使用する provider を定義します。

'providers' => [
    'users' => [
        'driver' => 'mongo',
    ],
],

最後に、guards 構成でこのプロバイダを参照できます。

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],
],

ユーザープロバイダ契約

Illuminate\Contracts\Auth\UserProvider 実装は、MySQL、MongoDB などの永続ストレージ システムから Illuminate\Contracts\Auth\Authenticatable 実装をフェッチする役割を果たします。これら 2 つのインターフェイスにより、ユーザー データがどのように保存されているか、または認証されたユーザーを表すためにどのような種類のクラスが使用されているかに関係なく、Laravel 認証メカニズムが機能し続けることができます。

Illuminate\Contracts\Auth\UserProvider コントラクトを見てみましょう。

<?php

namespace Illuminate\Contracts\Auth;

interface UserProvider
{
    public function retrieveById($identifier);
    public function retrieveByToken($identifier, $token);
    public function updateRememberToken(Authenticatable $user, $token);
    public function retrieveByCredentials(array $credentials);
    public function validateCredentials(Authenticatable $user, array $credentials);
    public function rehashPasswordIfRequired(Authenticatable $user, array $credentials, bool $force = false);
}

retrieveById 関数は通常、MySQL データベースからの自動インクリメント ID など、ユーザーを表すキーを受け取ります。 ID に一致する Authenticatable 実装がメソッドによって取得され、返される必要があります。

retrieveByToken 関数は、一意の $identifier および「remember me」$token によってユーザーを取得します。通常、remember_token などのデータベース列に保存されます。前のメソッドと同様に、一致するトークン値を持つ Authenticatable 実装がこのメソッドによって返される必要があります。

updateRememberToken メソッドは、$user インスタンスの remember_token を新しい $token で更新します。 「remember me」認証試行が成功したとき、またはユーザーがログアウトしたときに、新しいトークンがユーザーに割り当てられます。

retrieveByCredentials メソッドは、アプリケーションで認証を試行するときに、Auth::attempt メソッドに渡される資格情報の配列を受け取ります。次に、メソッドは、それらの資格情報と一致するユーザーについて、基礎となる永続ストレージを「クエリ」する必要があります。通常、このメソッドは、$credentials['username'] の値と一致する「ユーザー名」を持つユーザー レコードを検索する「where」条件を使用してクエリを実行します。このメソッドは、Authenticatable の実装を返す必要があります。 このメソッドでは、パスワードの検証や認証を試行しないでください。

validateCredentials メソッドは、指定された $user と $credentials を比較してユーザーを認証する必要があります。たとえば、このメソッドは通常、Hash::check メソッドを使用して、$user->getAuthPassword() の値を $credentials['password'] の値と比較します。このメソッドは、パスワードが有効かどうかを示す true または false を返す必要があります。

rehashPasswordIfRequired メソッドは、必要でサポートされている場合、指定された $user のパスワードを再ハッシュする必要があります。たとえば、このメソッドは通常、Hash::needsRehash メソッドを使用して、$credentials['password'] 値を再ハッシュする必要があるかどうかを判断します。パスワードを再ハッシュする必要がある場合、メソッドは Hash::make メソッドを使用してパスワードを再ハッシュし、基礎となる永続ストレージ内のユーザーのレコードを更新する必要があります。

認証可能な契約

UserProvider の各メソッドを調べたので、Authenticatable コントラクトを見てみましょう。ユーザープロバイダは、retrieveById、retrieveByToken、および retrieveByCredentials メソッドからこのインターフェイスの実装を返す必要があることに注意してください。

<?php

namespace Illuminate\Contracts\Auth;

interface Authenticatable
{
    public function getAuthIdentifierName();
    public function getAuthIdentifier();
    public function getAuthPasswordName();
    public function getAuthPassword();
    public function getRememberToken();
    public function setRememberToken($value);
    public function getRememberTokenName();
}

このインターフェースはシンプルです。 getAuthIdentifierName メソッドはユーザーの「主キー」列の名前を返し、getAuthIdentifier メソッドはユーザーの「主キー」を返す必要があります。 MySQL バックエンドを使用する場合、これはユーザー レコードに割り当てられる自動インクリメント主キーとなる可能性があります。 getAuthPasswordName メソッドは、ユーザーのパスワード列の名前を返す必要があります。 getAuthPassword メソッドは、ユーザーのハッシュされたパスワードを返す必要があります。

このインターフェイスにより、使用している ORM またはストレージ抽象化レイヤーに関係なく、認証システムが任意の「ユーザー」クラスで動作できるようになります。デフォルトでは、Laravel には、このインターフェイスを実装する App\Models\User クラスが app/Models ディレクトリに含まれています。

パスワードの自動再ハッシュ (Automatic Password Rehashing)

Laravel のデフォルトのパスワードハッシュアルゴリズムは bcrypt です。 bcrypt ハッシュの「作業係数」は、アプリケーションの config/hashing.php 構成ファイルまたは BCRYPT_ROUNDS 環境変数を介して調整できます。

通常、CPU / GPU の処理能力が増加するにつれて、bcrypt 作業係数は時間の経過とともに増加する必要があります。アプリケーションの bcrypt 作業係数を増やすと、ユーザーが Laravel のスターター キット経由でアプリケーションで認証するとき、または attempt メソッド経由で ユーザーを手動で認証する するときに、Laravel はユーザー パスワードを適切かつ自動的に再ハッシュします。

通常、パスワードの自動再ハッシュによってアプリケーションが中断されることはありません。ただし、hashing 構成ファイルを公開することで、この動作を無効にすることができます。

php artisan config:publish hashing

構成ファイルが公開されたら、rehash_on_login 構成値を false に設定できます。

'rehash_on_login' => false,

イベント (Events)

Laravel は、認証プロセス中にさまざまな events をディスパッチします。次のイベントのいずれかに対して events を行うことができます。

イベント名
Illuminate\Auth\Events\Registered
Illuminate\Auth\Events\Attempting
Illuminate\Auth\Events\Authenticated
Illuminate\Auth\Events\Login
Illuminate\Auth\Events\Failed
Illuminate\Auth\Events\Validated
Illuminate\Auth\Events\Verified
Illuminate\Auth\Events\Logout
Illuminate\Auth\Events\CurrentDeviceLogout
Illuminate\Auth\Events\OtherDeviceLogout
Illuminate\Auth\Events\Lockout
Illuminate\Auth\Events\PasswordReset
Illuminate\Auth\Events\PasswordResetLinkSent