メインコンテンツまでスキップ
バージョン: 8.x

Laravel Sanctum

Introduction​

Laravel Sanctum は、SPA (シングル ページ アプリケーション)、モバイル アプリケーション、およびシンプルなトークン ベースの API に非常に軽量な認証システムを提供します。 Sanctum を使用すると、アプリケーションの各ユーザーが自分のアカウント用に複数の API トークンを生成できます。これらのトークンには、トークンが実行できるアクションを指定する能力/スコープが付与される場合があります。

How It Works​

Laravel Sanctum は 2 つの別々の問題を解決するために存在します。ライブラリについて詳しく説明する前に、それぞれについて説明しましょう。

API Tokens​

まず、Sanctum は、複雑な OAuth を使用せずに、ユーザーに API トークンを発行するために使用できるシンプルなパッケージです。この機能は、GitHub や「個人アクセス トークン」を発行するその他のアプリケーションからインスピレーションを得ています。たとえば、アプリケーションの「アカウント設定」に、ユーザーが自分のアカウントの API トークンを生成できる画面があると想像してください。 Sanctum を使用してこれらのトークンを生成および管理できます。これらのトークンの有効期限は通常非常に長い (年単位) ですが、ユーザーがいつでも手動で取り消すことができます。

Laravel Sanctum は、ユーザー API トークンを単一のデータベース テーブルに保存し、有効な API トークンが含まれている必要がある Authorization ヘッダーを介して受信 HTTP リクエストを認証することにより、この機能を提供します。

SPA Authentication​

次に、Sanctum は、Laravel を利用した API と通信する必要があるシングル ページ アプリケーション (SPA) を認証する簡単な方法を提供するために存在します。これらの SPA は、Laravel アプリケーションと同じリポジトリに存在することも、Vue CLI や Next.js アプリケーションを使用して作成された SPA など、完全に別のリポジトリであることもあります。

この機能に関して、Sanctum はいかなる種類のトークンも使用しません。代わりに、Sanctum は Laravel の組み込み Cookie ベースのセッション認証サービスを使用します。通常、Sanctum はこれを実現するために Laravel の web 認証ガードを利用します。これにより、CSRF 保護、セッション認証の利点が得られるだけでなく、XSS を介した認証資格情報の漏洩からも保護されます。

Sanctum は、受信リクエストが独自の SPA フロントエンドから発信された場合にのみ、Cookie を使用して認証を試みます。 Sanctum が受信 HTTP リクエストを検査するときは、まず認証 Cookie を確認し、存在しない場合は、有効な API トークンの Authorization ヘッダーを検査します。

Sanctum を API トークン認証のみまたは SPA 認証のみに使用するのはまったく問題ありません。 Sanctum を使用しているからといって、Sanctum が提供する両方の機能を使用する必要があるというわけではありません。

Installation​

Laravel の最新バージョンには、すでに Laravel Sanctum が含まれています。ただし、アプリケーションの composer.json ファイルに laravel/sanctum が含まれていない場合は、以下のインストール手順に従ってください。

Composer パッケージマネージャーを介して Laravel Sanctum をインストールできます。

composer require laravel/sanctum

次に、vendor:publish Artisan コマンドを使用して、Sanctum 構成ファイルと移行ファイルを公開する必要があります。 sanctum 構成ファイルは、アプリケーションの config ディレクトリに配置されます。

php artisan vendor:publish --provider="Laravel\Sanctum\SanctumServiceProvider"

最後に、データベースの移行を実行する必要があります。 Sanctum は、API トークンを保存するデータベース テーブルを 1 つ作成します。

php artisan migrate

次に、Sanctum を使用して SPA を認証する予定の場合は、アプリケーションの app/Http/Kernel.php ファイル内の api ミドルウェア グループに Sanctum のミドルウェアを追加する必要があります。

'api' => [
\Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
'throttle:api',
\Illuminate\Routing\Middleware\SubstituteBindings::class,
],

Migration Customization​

Sanctum のデフォルトの移行を使用しない場合は、App\Providers\AppServiceProvider クラスの register メソッドで Sanctum::ignoreMigrations メソッドを呼び出す必要があります。次のコマンドを実行して、デフォルトの移行をエクスポートできます: php artisan vendor:publish --tag=sanctum-migrations

Configuration​

Overriding Default Models​

通常は必須ではありませんが、Sanctum によって内部的に使用される PersonalAccessToken モデルを自由に拡張できます。

use Laravel\Sanctum\PersonalAccessToken as SanctumPersonalAccessToken;

class PersonalAccessToken extends SanctumPersonalAccessToken
{
// ...
}

次に、Sanctum が提供する usePersonalAccessTokenModel メソッドを介してカスタム モデルを使用するように Sanctum に指示できます。通常、このメソッドは、アプリケーションのサービスプロバイダの 1 つの boot メソッドで呼び出す必要があります。

use App\Models\Sanctum\PersonalAccessToken;
use Laravel\Sanctum\Sanctum;

/**
* Bootstrap any application services.
*
* @return void
*/
public function boot()
{
Sanctum::usePersonalAccessTokenModel(PersonalAccessToken::class);
}

API Token Authentication​

独自のファーストパーティ SPA の認証に API トークンを使用しないでください。代わりに、Sanctum の組み込み SPA authentication features を使用してください。

Issuing API Tokens​

Sanctum を使用すると、アプリケーションへの API リクエストの認証に使用できる API トークン/個人アクセス トークンを発行できます。 API トークンを使用してリクエストを行う場合、トークンは Bearer トークンとして Authorization ヘッダーに含める必要があります。

ユーザーへのトークンの発行を開始するには、ユーザー モデルで Laravel\Sanctum\HasApiTokens トレイトを使用する必要があります。

use Laravel\Sanctum\HasApiTokens;

class User extends Authenticatable
{
use HasApiTokens, HasFactory, Notifiable;
}

トークンを発行するには、createToken メソッドを使用できます。 createToken メソッドは、Laravel\Sanctum\NewAccessToken インスタンスを返します。 API トークンはデータベースに保存される前に SHA-256 ハッシュを使用してハッシュされますが、NewAccessToken インスタンスの plainTextToken プロパティを使用してトークンのプレーンテキスト値にアクセスできます。トークンが作成された直後に、この値をユーザーに表示する必要があります。

use Illuminate\Http\Request;

Route::post('/tokens/create', function (Request $request) {
$token = $request->user()->createToken($request->token_name);

return ['token' => $token->plainTextToken];
});

HasApiTokens トレイトによって提供される tokens Eloquent 関係を使用して、ユーザーのすべてのトークンにアクセスできます。

foreach ($user->tokens as $token) {
//
}

Token Abilities​

Sanctumでは、トークンに「能力」を割り当てることができます。アビリティは、OAuth の「スコープ」と同様の目的を果たします。文字列能力の配列を 2 番目の引数として createToken メソッドに渡すことができます。

return $user->createToken('token-name', ['server:update'])->plainTextToken;

Sanctum によって認証された受信リクエストを処理するとき、tokenCan メソッドを使用して、トークンに特定の機能があるかどうかを判断できます。

if ($user->tokenCan('server:update')) {
//
}

Token Ability Middleware​

Sanctum には、受信リクエストが特定の機能が付与されたトークンで認証されていることを検証するために使用できる 2 つのミドルウェアも含まれています。まず、次のミドルウェアをアプリケーションの app/Http/Kernel.php ファイルの $routeMiddleware プロパティに追加します。

'abilities' => \Laravel\Sanctum\Http\Middleware\CheckAbilities::class,
'ability' => \Laravel\Sanctum\Http\Middleware\CheckForAnyAbility::class,

abilities ミドルウェアをルートに割り当てて、受信リクエストのトークンにリストされているすべての機能があることを確認できます。

Route::get('/orders', function () {
// Token has both "check-status" and "place-orders" abilities...
})->middleware(['auth:sanctum', 'abilities:check-status,place-orders']);

ability ミドルウェアをルートに割り当てて、受信リクエストのトークンに、リストされている機能の * 少なくとも 1 つ* があることを確認できます。

Route::get('/orders', function () {
// Token has the "check-status" or "place-orders" ability...
})->middleware(['auth:sanctum', 'ability:check-status,place-orders']);

First-Party UI Initiated Requests​

便宜上、受信した認証済みリクエストがファーストパーティ SPA からのものであり、Sanctum の組み込み SPA authentication を使用している場合、tokenCan メソッドは常に true を返します。

ただし、これは必ずしもアプリケーションがユーザーにアクションの実行を許可する必要があることを意味するわけではありません。通常、アプリケーションの authorization policies は、トークンに機能を実行する権限が付与されているかどうかを判断し、ユーザー インスタンス自体にアクションの実行を許可する必要があるかどうかを確認します。

たとえば、サーバーを管理するアプリケーションを想像すると、トークンがサーバーを更新する権限を持っているかどうか、および サーバーがユーザーに属していることを確認することを意味します。

return $request->user()->id === $server->user_id &&
$request->user()->tokenCan('server:update')

最初は、tokenCan メソッドの呼び出しを許可し、ファーストパーティ UI で開始されたリクエストに対して常に true を返すのは奇妙に思えるかもしれません。ただし、API トークンが利用可能であり、tokenCan メソッド経由で検査できると常に想定できると便利です。このアプローチを採用すると、リクエストがアプリケーションの UI からトリガーされたのか、API のサードパーティ コンシューマーのいずれかによって開始されたのかを気にすることなく、アプリケーションの承認ポリシー内でいつでも tokenCan メソッドを呼び出すことができます。

Protecting Routes​

すべての受信リクエストを認証する必要があるようにルートを保護するには、routes/web.php および routes/api.php ルート ファイル内の保護されたルートに sanctum 認証ガードをアタッチする必要があります。このガードは、受信リクエストがステートフルな Cookie 認証リクエストとして認証されるか、リクエストがサードパーティからのものである場合は有効な API トークン ヘッダーを含むことを保証します。

sanctum ガードを使用してアプリケーションの routes/web.php ファイル内のルートを認証することをなぜ推奨するのか疑問に思われるかもしれません。 Sanctum は最初に、Laravel の一般的なセッション認証 Cookie を使用して受信リクエストの認証を試みることに注意してください。その Cookie が存在しない場合、Sanctum はリクエストの Authorization ヘッダー内のトークンを使用してリクエストの認証を試みます。さらに、Sanctum を使用してすべてのリクエストを認証すると、現在認証されているユーザー インスタンスで常に tokenCan メソッドを呼び出すことができるようになります。

use Illuminate\Http\Request;

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
return $request->user();
});

Revoking Tokens​

Laravel\Sanctum\HasApiTokens トレイトによって提供される tokens 関係を使用してデータベースからトークンを削除することで、トークンを「取り消す」ことができます。

// Revoke all tokens...
$user->tokens()->delete();

// Revoke the token that was used to authenticate the current request...
$request->user()->currentAccessToken()->delete();

// Revoke a specific token...
$user->tokens()->where('id', $tokenId)->delete();

SPA Authentication​

Sanctum は、Laravel を利用した API と通信する必要があるシングル ページ アプリケーション (SPA) を認証する簡単な方法を提供するためにも存在します。これらの SPA は、Laravel アプリケーションと同じリポジトリに存在する場合もあれば、完全に別のリポジトリである場合もあります。

この機能に関して、Sanctum はいかなる種類のトークンも使用しません。代わりに、Sanctum は Laravel の組み込み Cookie ベースのセッション認証サービスを使用します。この認証アプローチでは、CSRF 保護、セッション認証の利点が得られるだけでなく、XSS を介した認証資格情報の漏洩からも保護されます。

認証するには、SPA と API が同じトップレベル ドメインを共有する必要があります。ただし、異なるサブドメインに配置される場合もあります。さらに、リクエストとともに Accept: application/json ヘッダーを送信するようにしてください。

Configuration​

Configuring Your First-Party Domains​

まず、SPA がどのドメインからリクエストを行うかを設定する必要があります。これらのドメインは、sanctum 構成ファイルの stateful 構成オプションを使用して構成できます。この構成設定は、API にリクエストを行うときに、Laravel セッション Cookie を使用して「ステートフル」認証を維持するドメインを決定します。

ポート (127.0.0.1:8000) を含む URL 経由でアプリケーションにアクセスしている場合は、ドメインにポート番号を必ず含める必要があります。

Sanctum Middleware​

次に、Sanctum のミドルウェアを、app/Http/Kernel.php ファイル内の api ミドルウェア グループに追加する必要があります。このミドルウェアは、SPA からの受信リクエストが Laravel のセッション Cookie を使用して認証できるようにすると同時に、サードパーティまたはモバイル アプリケーションからのリクエストが API トークンを使用して認証できるようにする役割を果たします。

'api' => [
\Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
'throttle:api',
\Illuminate\Routing\Middleware\SubstituteBindings::class,
],

CORS & Cookies​

別のサブドメインで実行される SPA からのアプリケーションの認証で問題が発生する場合は、CORS (Cross-Origin Resource Sharing) またはセッション Cookie の設定が間違っている可能性があります。

アプリケーションの CORS 構成が、値 True を持つ Access-Control-Allow-Credentials ヘッダーを返していることを確認する必要があります。これは、アプリケーションの config/cors.php 構成ファイル内の supports_credentials オプションを true に設定することで実現できます。

さらに、アプリケーションのグローバル axios インスタンスで withCredentials オプションを有効にする必要があります。通常、これは resources/js/bootstrap.js ファイルで実行する必要があります。 Axios を使用してフロントエンドから HTTP リクエストを作成していない場合は、独自の HTTP クライアントで同等の構成を実行する必要があります。

axios.defaults.withCredentials = true;

最後に、アプリケーションのセッション Cookie ドメイン構成がルート ドメインのサブドメインをサポートしていることを確認する必要があります。これを行うには、アプリケーションの config/session.php 構成ファイル内でドメインの先頭に . を付加します。

'domain' => '.domain.com',

Authenticating​

CSRF Protection​

SPA を認証するには、SPA の「ログイン」ページでまず /sanctum/csrf-cookie エンドポイントにリクエストを作成し、アプリケーションの CSRF 保護を初期化する必要があります。

axios.get('/sanctum/csrf-cookie').then(response => {
// Login...
});

このリクエスト中に、Laravel は現在の CSRF トークンを含む XSRF-TOKEN Cookie を設定します。このトークンは、後続のリクエストの X-XSRF-TOKEN ヘッダーで渡す必要があります。これは、Axios や Angular HttpClient などの一部の HTTP クライアント ライブラリが自動的に行います。 JavaScript HTTP ライブラリが値を設定しない場合は、このルートによって設定される XSRF-TOKEN Cookie の値と一致するように X-XSRF-TOKEN ヘッダーを手動で設定する必要があります。

Logging In​

CSRF保護が初期化されたら、Laravelアプリケーションの/loginルートに対してPOSTリクエストを行う必要があります。この /login ルートは、implemented manually であるか、Laravel Fortify のようなヘッドレス認証パッケージを使用している可能性があります。

ログインリクエストが成功すると認証され、アプリケーションのルートへの後続のリクエストは、Laravel アプリケーションがクライアントに発行したセッション Cookie を介して自動的に認証されます。さらに、アプリケーションはすでに /sanctum/csrf-cookie ルートにリクエストを行っているため、JavaScript HTTP クライアントが X-XSRF-TOKEN ヘッダーの XSRF-TOKEN Cookie の値を送信している限り、後続のリクエストは自動的に CSRF 保護を受ける必要があります。

もちろん、アクティビティがないためにユーザーのセッションが期限切れになった場合、Laravel アプリケーションへの後続のリクエストは 401 または 419 HTTP エラー応答を受け取る可能性があります。この場合、ユーザーを SPA のログイン ページにリダイレクトする必要があります。

独自の /login エンドポイントを自由に作成できます。ただし、標準の session based authentication services that Laravel provides を使用してユーザーを認証することを確認する必要があります。通常、これは、web 認証ガードを使用することを意味します。

Protecting Routes​

すべての受信リクエストを認証する必要があるようにルートを保護するには、routes/api.php ファイル内の API ルートに sanctum 認証ガードをアタッチする必要があります。このガードにより、受信リクエストが SPA からのステートフルな認証済みリクエストとして認証されるか、リクエストがサードパーティからのものである場合は有効な API トークン ヘッダーが含まれることが保証されます。

use Illuminate\Http\Request;

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
return $request->user();
});

Authorizing Private Broadcast Channels​

SPA が private / presence broadcast channels で認証する必要がある場合は、routes/api.php ファイル内に Broadcast::routes メソッド呼び出しを配置する必要があります。

Broadcast::routes(['middleware' => ['auth:sanctum']]);

次に、プッシャーの認可リクエストを成功させるには、Laravel Echo を初期化するときにカスタム プッシャー authorizer を指定する必要があります。これにより、アプリケーションで axios インスタンス (properly configured for cross-domain requests) を使用するようにプッシャーを構成できるようになります。

window.Echo = new Echo({
broadcaster: "pusher",
cluster: process.env.MIX_PUSHER_APP_CLUSTER,
encrypted: true,
key: process.env.MIX_PUSHER_APP_KEY,
authorizer: (channel, options) => {
return {
authorize: (socketId, callback) => {
axios.post('/api/broadcasting/auth', {
socket_id: socketId,
channel_name: channel.name
})
.then(response => {
callback(false, response.data);
})
.catch(error => {
callback(true, error);
});
}
};
},
})

Mobile Application Authentication​

Sanctum トークンを使用して、モバイル アプリケーションの API へのリクエストを認証することもできます。モバイル アプリケーション リクエストを認証するプロセスは、サードパーティ API リクエストを認証するプロセスと似ています。ただし、API トークンの発行方法には若干の違いがあります。

Issuing API Tokens​

まず、ユーザーの電子メール/ユーザー名、パスワード、デバイス名を受け入れるルートを作成し、それらの資格情報を新しい Sanctum トークンと交換します。このエンドポイントに与えられる「デバイス名」は情報提供を目的としており、任意の値を指定できます。一般に、デバイス名の値は、「Nuno's iPhone 12」など、ユーザーが認識できる名前にする必要があります。

通常、モバイル アプリケーションの「ログイン」画面からトークン エンドポイントにリクエストを送信します。エンドポイントはプレーンテキストの API トークンを返します。このトークンはモバイル デバイスに保存され、追加の API リクエストを行うために使用されます。

use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;

Route::post('/sanctum/token', function (Request $request) {
$request->validate([
'email' => 'required|email',
'password' => 'required',
'device_name' => 'required',
]);

$user = User::where('email', $request->email)->first();

if (! $user || ! Hash::check($request->password, $user->password)) {
throw ValidationException::withMessages([
'email' => ['The provided credentials are incorrect.'],
]);
}

return $user->createToken($request->device_name)->plainTextToken;
});

モバイル アプリケーションがトークンを使用してアプリケーションに API リクエストを行う場合、Authorization ヘッダー内のトークンを Bearer トークンとして渡す必要があります。

モバイル アプリケーションのトークンを発行する場合、token abilities を自由に指定することもできます。

Protecting Routes​

前に説明したように、sanctum 認証ガードをルートにアタッチすることで、すべての受信リクエストが認証される必要があるようにルートを保護できます。

Route::middleware('auth:sanctum')->get('/user', function (Request $request) {
return $request->user();
});

Revoking Tokens​

ユーザーがモバイル デバイスに発行された API トークンを取り消すことができるようにするには、Web アプリケーションの UI の「アカウント設定」部分内で、「取り消し」ボタンとともに名前でリストすることができます。ユーザーが「取り消し」ボタンをクリックすると、データベースからトークンを削除できます。 Laravel\Sanctum\HasApiTokens トレイトによって提供される tokens 関係を介してユーザーの API トークンにアクセスできることを覚えておいてください。

// Revoke all tokens...
$user->tokens()->delete();

// Revoke a specific token...
$user->tokens()->where('id', $tokenId)->delete();

Testing​

テスト中に、Sanctum::actingAs メソッドを使用してユーザーを認証し、トークンにどの能力を付与するかを指定できます。

use App\Models\User;
use Laravel\Sanctum\Sanctum;

public function test_task_list_can_be_retrieved()
{
Sanctum::actingAs(
User::factory()->create(),
['view-tasks']
);

$response = $this->get('/api/task');

$response->assertOk();
}

トークンにすべての能力を付与したい場合は、actingAs メソッドに提供される能力リストに * を含める必要があります。

Sanctum::actingAs(
User::factory()->create(),
['*']
);